58°F

Aaron Parecki

  • Articles
  • Notes
  • Projects

#indieauth

  • WebSub and IndieAuth Published on w3.org!

    Aaron Parecki
    Tue, Jan 23, 2018 6:28pm -08:00

    Today, we published the last of the two W3C specs I am editing! WebSub was published as a W3C Recommendation, and IndieAuth was published as a Working Group Note.

    WebSub

    WebSub is a standardized way for publishers to notify subscribers when new content is available. It was formerly known as PubSubHubbub, which was hard to say, so I'm glad we renamed it. 

    https://www.w3.org/TR/websub/

    One of our goals with WebSub was to ensure that existing PubSubHubbub implementations would still be compliant, so there are already lots of implementations in the wild! If you're publishing content online, want to receive realtime updates when feeds are updated, or are building a tool to facilitate either of these, WebSub is a great fit! You can use the tool at websub.rocks while building your implementation to get immediate feedback!

    Thanks to everyone who contributed to the spec, and especially my co-editor Julien!

    IndieAuth

    IndieAuth is an identity layer on top of OAuth 2.0, and used by Micropub clients. Micropub was published as a W3C Recommendation in May of last year. Today, IndieAuth was published as a W3C Working Group Note. 

    https://www.w3.org/TR/indieauth/

    The Social Web Working Group did not set out with the goal to standardize any sort of authentication mechanism, but since almost all of the Micropub implementations already supported the same mechanism, we decided to publish a "Note" to that effect. (The Micropub implementations that don't use IndieAuth use hard-coded tokens as a shortcut.) Notes are quite different from Recommendations in the eyes of the W3C, as described by this sentence: "The publication of a NOTE by the Consortium implies no endorsement of any kind." The goal of publishing this Note was to capture the current state of interoperable implementations.

    One of the things I like most about the W3C standardization process is that specs are published after they describe things that are working, rather than published as an aspirational blueprint. We kind of pushed that definition to an extreme with IndieAuth, since there have been live interoperable IndieAuth implementations for several years now. Previously, I had written up several guides for how to implement the various roles in the IndieAuth flow, but never written it down as its own spec. The guides were certainly useful, as was clearly demonstrated by the fact that people were following them to build out various parts of the ecosystem. But there is also a need for a spec to lay things out and remove any ambiguities along the way.

    Thanks to everyone who helped iron out the details of the language in the spec! We made a lot of good progress over the last few months!

    What's Next?

    So with these two specs published today, we've taken quite a lot of the IndieWeb building blocks through the W3C process!

    • Webmention - enables direct site-to-site commenting and other interactions
    • Post Type Discovery - once you receive a Webmention, this algorithm helps your site know what to do with the contents
    • Micropub - enables apps to create content on a website
    • WebSub - enables real-time subscriptions to web pages and feeds
    • IndieAuth - a way to log in to sites with your domain name, and allow Micropub apps to post to your site
    • jf2 - a post serialization format used by some Webmention services and other tools

    So here's a few specs and tools that I'm working in the immediate future:

    IndieAuth test suite - Like webmention.rocks, micropub.rocks and websub.rocks, I plan to make a tool that will help test your IndieAuth implementation. It will do things like throw tricky situations at your client to ensure you're handling the edge cases properly.

    Finally finish renaming indieauth.com - I never should have called it that, since it's doing two completely separate things. You can read about the details here.

    Microsub - Microsub is currently an early draft spec. The goal of Microsub is to do for reader interfaces what Micropub did for publishing interfaces. A Microsub server provides a standardized API that reader clients can use to show content. This will help make developing IndieWeb readers a lot easier, and also allows you to keep your subscription list in a server that you control rather than letting the reader own the list.

    Monocle - Monocle is my Microsub implementation. It subscribes to feeds and presents a them as a Microsub server so that I can use any Microsub client to view everything. There's still a lot of work ahead for me here, but it's my goal to finally stop using IRC as a reader by getting Monocle to the point of being functional enough to cover all my use cases.

    As always, you can help me and the rest of the IndieWeb out by adding support for any of these specs on your own website! We are always excited to welcome new people to the IndieWeb chat if you have any questions!

    Portland, Oregon • 47°F
    22 likes 23 reposts 1 bookmark 7 replies 5 mentions
    #websub #indieauth #w3c #standards
    Tue, Jan 23, 2018 6:28pm -08:00
  • Zegnat https://github.com/Zegnat   •   Jan 3

    #12 Specify RelMeAuth as fallback.

    Aaron Parecki

    This spec intentionally doesn't specify how users authenticate themselves to their server, it only deals with how third-party clients can authenticate users where their domain name is their identity.

    The analogous version of this in RelMeAuth, with Google as an example, is such: as far as the RelMeAuth client is concerned, it sends the user over to Google, and expects Google to handle authenticating the user. This might involve entering their password, optionally followed by a 2fa mechanism like a Yubikey or TOTP code. That is all invisible to the site they're logging in to.

    Similarly, IndieAuth clients do not know how users authenticate to their own server, the client just expects to send them off to the authorization endpoint and get back a response later that can be verified.

    It is not a good idea for a spec to require any sort of authentication mechanism between the user and their own authorization server, which is something that the OAuth 2.0 spec has also made clear.

    Now, the rest of this conversation is essentially continuing the naming debate of indieauth.com vs IndieAuth the spec vs other options we've considered.

    I agree with many of @tantek's points, like

    ... should be it "just works" even if you only setup rel=me

    However, that is describing RelMeAuth, not this spec. And as @Zegnat pointed out, even just adding rel=me isn't necessarily going to guarantee that you can sign in to an arbitrary site that supports RelMeAuth, since you need to add a rel=me link to a service that the site you're signing in to supports, which requires that site to register an OAuth application and deal with that service's API.

    I'm in the middle of renaming indieauth.com, the goal is that the wiki will redirect users to indielogin.com to authenticate them using the existing mechanisms: RelMeAuth, email, PGP, and IndieAuth. Nowhere in that flow will users see the term "IndieAuth" unless they include a rel=authorization_endpoint link on their website to an IndieAuth server of their choosing.

    I definitely agree that signing in to the wiki needs to be as simple as possible. That's the reason I added so many OAuth providers as well as alternate methods to indieauth.com (soon indielogin.com) in the first place. We've even had some people who want to sign in to the wiki but don't have a Twitter or GitHub account and don't want one, which is why I added things like email and PGP authentication options, which were not described by RelMeAuth.

    This is all to say that it's not the goal of this spec to include RelMeAuth. This spec is intended to be just the URL-based extension to OAuth 2.0. If "IndieAuth" is not the right name for this spec, that's a different issue.

    San Jose, California, USA • 52°F
    #indieauth
    Wed, Jan 3, 2018 9:16am -08:00
  • Announcing the IndieAuth Spec!

    Aaron Parecki
    Tue, Dec 5, 2017 12:30pm -08:00

    It's been a long time coming, but I've finally published a proper IndieAuth spec!

    IndieAuth has been around for years, and is even referenced by the Micropub spec. But until now, there wasn't a canonical version of the spec all in one place. Previously it existed as a series of how-to guides on the IndieWeb wiki. Arguably it's actually more useful that way, since the whole point of specs is to communicate a consistent way of implementing something. But it did make it awkward to refer to it formally.

    So I'm happy to say that there is finally a spec for IndieAuth, at https://indieauth.net/spec/

    This document captures the current state of what has been implemented, and incorporates much of the feedback we've gathered over the years. Most of the document is split up into authentication and authorization sections, for when you are trying to just identify users for sign-in in vs when a Micropub client is trying to get an access token to post to the user's site. Formally it's an extension to OAuth 2.0, and makes several decisions that were left un-specified in the OAuth 2.0 core spec.

    If you've implemented any part of this spec, or are thinking about it, I'd appreciate any feedback! Feel free to comment on this post, file an issue on GitHub, or drop a note in the IndieWeb chat!

    Portland, Oregon
    2 likes 1 reply 2 mentions
    #indieweb #indiewebchallenge #indieauth #oauth2 #oauth
    Tue, Dec 5, 2017 12:30pm -08:00
  • William Narmontas https://www.scalawilliam.com/   •   Jul 8
    Number of sign-ins per month since 2012. If that info is not available, then just monthly number of hits on the site until now would suffice
    Aaron Parecki
    @scalawilliam That'll work!
    Portland, Oregon, USA
    2 likes
    #indieauth
    Fri, Jul 7, 2017 9:04pm -07:00
  • William Narmontas http://www.scalawilliam.com
    #IndieAuth is SO MUCH easier than OAuth! https://indieauth.com/developers
    No secret keys, etc, etc. Works against localhost!
    Portland, Oregon
    #IndieAuth
    Sun, Jun 11, 2017 12:34am +00:00 (liked on Sat, Jun 10, 2017 8:43pm -07:00)
  • Aaron Parecki
    Getting a head start on IndieWebCamp Nürnberg on the train with @sebsel, editing wiki pages about IndieAuth and indieauth.com
    Heigenbrücken, Bayern, DEU
    3 likes
    #indieauth #indiewebcamp
    Wed, May 17, 2017 1:06pm +02:00
  • Greg McVerry http://jgregorymcverry.com/   •   Mar 23
    we were looking at indieauth to include in thimble but passportjs warns folks not to use: http://bit.ly/2ns1xSV still true? #indieweb
    Aaron Parecki
    @jgmac1106 I don't know the state of that plugin, but you could just do it manually: https://indieauth.com/developers or https://indieweb.org/indieauth-for-login
    Portland, Oregon, USA
    #indieauth
    Thu, Mar 23, 2017 10:13am -07:00
  • Day 86: Updating IndieAuth Docs #100DaysOfIndieWeb

    Aaron Parecki
    Thu, Mar 16, 2017 5:22pm -07:00

    Beginning a slow project of updating the docs about the IndieAuth spec, today I started by updating a few pages on the wiki. Right now, most of the docs about IndieAuth (the spec), and how to use it, live across a variety of pages on the wiki, grouped together at https://indieweb.org/Category:IndieAuth.

    My goal with the spec IndieAuth is to make it an extension of the OAuth 2.0 spec. It has always been based off of the OAuth 2.0 spec, but I've never written it up properly as an extension. It's always been just a series of how-to guides. Additionally, I had originally started by specifying all of the responses being form-encoded responses, whereas the OAuth 2.0 spec says all responses must be JSON format. I've been slowly converting my various apps that use IndieAuth to support both, based on the HTTP Accept header, although I haven't publicized this much yet.

    Today's project was updating the existing IndieAuth documentation on the wiki to explicitly include the JSON versions as a valid response format.

    Eventually I hope to write up IndieAuth as a formal extension to OAuth 2.0, in the same format that something like the Device Flow is an extension.

    Portland, Oregon
    1 like 1 reply 2 mentions
    #100daysofindieweb #micropub #indieauth #oauth2
    Thu, Mar 16, 2017 5:22pm -07:00
  • Day 81: Removing SMS and Clef from IndieAuth.com #100DaysOfIndieWeb

    Aaron Parecki
    Sat, Mar 11, 2017 10:18pm -08:00

    Sadly, Clef is shutting down in a couple months. If you haven't heard of it, it was a clever way to use your email and a mobile app to sign in to websites. I had integrated Clef logins to indieauth.com as one way to authenticate your email address. Since they are shutting down in June, I am proactively removing it from the website right now.

    The other method for authenticating your email address is is to receive a verification code sent to your address, which I will of course continue to support.

    While I was in the code, I figured it was about time to retire SMS authentication as well. While conceptually receiving a code via SMS or email are equivalent, in practice this is not true. SMS is actually a pretty insecure protocol, and it's possible (and not that expensive) to intercept SMS messages to all phones in a nearby area if you have the right hardware. 

    So as of today, SMS authentication is no longer an option for indieauth.com, and you will have to receive verification codes sent to your email instead of using the Clef app. I may bring back SMS support in indieauth.com as a second factor authentication in the future.

    Here is my list of providers I use now.

    Portland, Oregon
    2 mentions
    #100daysofindieweb #indieauth #sms #clef
    Sat, Mar 11, 2017 10:18pm -08:00
  • Day 73: Updated Documentation for indieauth.com #100DaysOfIndieWeb

    Aaron Parecki
    Fri, Mar 3, 2017 8:38pm -08:00

    Today I updated the documentation for indieauth.com to include a setup guide for using indieauth.com as your OpenID provider, and added more prominent links to the OpenID and PGP instructions in various places on the site.

    The header bar and footer now include direct links to PGP and OpenID setup instructions. The main setup page also now links to the PGP setup page and includes an example of linking to your PGP key along with the other example providers.

    I wrote a setup guide for configuring indieauth.com as an OpenID provider.

    At this point, OpenID 1 is almost completely gone. There are only a few sites that still consume it, and most of the former major providers have all shut down. Quite a lot of people have migrated to using indieauth.com as their provider since it's one of the few remaining services online. Hopefully this new setup guide will make it even easier to find for people looking to migrate.

    Portland, Oregon
    2 mentions
    #100daysofindieweb #indieauth #openid
    Fri, Mar 3, 2017 8:38pm -08:00
  • Joel Purra https://joelpurra.com   •   Jan 9
    Almost none, but still some; might selfhost =) Like the distributed concept, would like to see more usage! https://lwn.net/Articles/708151/
    Aaron Parecki
    @joelpurra I like the concept too! My goal with #indieauth is to use domains as identities (like OpenID) but using OAuth 2.0 techniques.
    Portland, Oregon, USA
    1 like
    #indieauth
    Mon, Jan 9, 2017 11:26am -08:00
  • Joel Purra https://joelpurra.com   •   Jan 9
    Will consider #indieauth, but negatively angled "why not #openid" info had (has) me thinking otherwise https://indieweb.org/OpenID
    Aaron Parecki
    @joelpurra There also seem to be almost no OpenID providers left except indieauth.com, since myopenid shut down.
    Portland, Oregon, USA
    1 like 1 reply
    #indieauth #openid
    Mon, Jan 9, 2017 11:09am -08:00
  • Joel Purra https://joelpurra.com   •   Jan 9
    Will consider #indieauth, but negatively angled "why not #openid" info had (has) me thinking otherwise https://indieweb.org/OpenID
    Aaron Parecki
    @joelpurra Well I would never suggest anyone use OpenID 1 for anything new, but I can see how that's confusing. Will see if I can rephrase.
    Portland, Oregon, USA
    #indieauth #openid
    Mon, Jan 9, 2017 11:08am -08:00
  • https://twitter.com/joelpurra/status/818530491175411715
    Aaron Parecki
    @joelpurra @oplife indieauth.com should still be running an OpenID provider. I just used it to sign in to StackOverflow yesterday!
    Portland, Oregon, USA
    5 replies
    #indieauth #openid
    Mon, Jan 9, 2017 10:54am -08:00
  • Aaron Parecki
    Gave an unprepared live demo of IndieAuth.com at @w3c #tpac2016 and nothing broke 😮
    Lisboa, Lisboa, PRT
    8 likes 3 replies
    #tpac2016 #indieauth #w3c
    Wed, Sep 21, 2016 10:53am +01:00
  • Standardizing the Social Web
    Jun
    22
    June 22, 2016 at 11:00am UTC-7
    Portland, Oregon, USA
    Open Source Bridge
    View Slides
    1 mention
    #indieweb #indieauth #micropub #osbridge #activitystreams #w3c #socialwg
    permalink
  • https://github.com/aaronpk/IndieAuth.com/issues/120#issuecomment-224739992
    Aaron Parecki
    Not that it's your fault, but I think you're starting to confuse the two roles of indieauth.com.

    Role 1) indieauth.com is a service that developers can use to handle all the hard work of doing rel-me-auth with specific providers directly. In this case, the application developer has a trust relationship with indieauth.com and users should not be concerned that they're using indieauth.com, from their POV they are just signing in to the website. This is how the indiewebcamp.com wiki uses indieauth.com

    Role 2) indieauth.com is a service that users can delegate their domain to. To use indieauth.com this way, the user links to indieauth.com as their `authorization_endpoint` on their domain. In this case, the user has a trust relationship with indieauth.com, and an application discovers the user's auth endpoint by following the rel link on their website. Micropub apps like Quill work this way, where you will only ever see indieauth.com if you have delegated to it yourself.

    Does this help clear things up? In situation 2, you'll only ever see indieauth.com if you explicitly set it as your authorization endpoint. You could use indiecert.net or use your own auth server instead. In situation 1, where a developer has chosen to use indieauth.com instead of implementing authentication themselves, you're limited to the options that indieauth.com has implemented. However the idea is that indieauth.com implements a good number of options and in a secure way, making it a better option for developers than implementing PGP/SMS/GitHub/etc themselves.

    With that in mind, could you rephrase your request in that context?
    Portland, Oregon, USA
    #indieauth
    Wed, Jun 8, 2016 3:08pm -07:00
  • https://github.com/aaronpk/IndieAuth.com/issues/120
    Aaron Parecki
    Hm, would you want to delegate to the `pgp` one to prevent any other login mechanisms from being used? One of the nice things about indieauth.com showing multiple options is that depending on the device you're logging in on, you might want to choose a different option. For example I usually use GitHub or GPG login when I'm on my main computer, but use Twitter from my phone.

    I can definitely see value in wanting to limit the options provided by indieauth.com to a subset of the rel-me links on your site. (Maybe I want Twitter listed on my site, but never want to use it for login.)

    What about using the query string to indicate the supported providers?

    `https://indieauth.com/auth?providers=github.com,pgp,sms` etc. In that case, indieauth.com could even present them to you in the order given.

    Similar to https://github.com/aaronpk/IndieAuth.com/issues/112, if only one is set then it could redirect immediately instead of making you click the button, which would be a better user experience.
    Portland, Oregon, USA
    #indieauth
    Wed, Jun 8, 2016 2:42pm -07:00
  • New integrated authorization server for p3k

    Aaron Parecki
    Wed, Apr 13, 2016 3:21pm +02:00

    I just launched an update to p3k which adds an integrated authorization server. This means that now when I sign in to Micropub apps like Quill, it will redirect me to my own server where I can have more fine-grained control over the access I am granting the application.

    My new authorization endpoint displays the scopes the application is requesting, and lets me modify the scope when granting the request. This means if an application I don't yet trust requests the ability to update or delete my posts, I can un-check those boxes but still allow it to create posts.

    I also have the ability to have all posts from an application be added to a specific channel, rather than showing up in my main feed. I use the concept of "channels" to create different lists of posts depending on what kind of content the post has. For example, /photos contains all of my photo posts, and /travel contains travel plans, plane flight and train logs, and events that occur outside of Portland. 

    Now that I have a built-in authorization endpoint, I'm looking forward to adding more features to it, such as setting the default privacy of posts so I can allow an application to create posts that are only visible to me (or a specific audience) unless I make them public.

    Nürnberg, Bayern
    3 likes 1 mention
    #indieweb #p3k #indieauth
    Wed, Apr 13, 2016 3:21pm +02:00
  • https://twitter.com/Sneakyness/status/707676786604306433
    Aaron Parecki
    @Sneakyness sounds like you're trying to use the OpenID service? Use openid.indieauth.com as your server and it should work
    Derry Twp, Pennsylvania, USA
    #indieauth
    Wed, Mar 9, 2016 1:18pm -08:00
next

Hi, I'm Aaron Parecki, co-founder of IndieWebCamp. I maintain oauth.net, write and consult about OAuth, and am the editor of several W3C specfications. I record videos for local conferences and help run a podcast studio in Portland.

I wrote 100 songs in 100 days! I've been tracking my location since 2008, and write down everything I eat and drink. I've spoken at conferences around the world about owning your data, OAuth, quantified self, and explained why R is a vowel. Read more.

Follow
  • Okta Developer Advocate
  • IndieWebCamp Founder
  • W3C Editor
  • Stream PDX Co-Founder
  • backpedal.tv

  • W7APK
  • ⭐️ Life Stack
  • All
  • Articles
  • Bookmarks
  • Notes
  • Photos
  • Replies
  • Reviews
  • Sleep
  • Travel
  • Contact
© 1999-2019 by Aaron Parecki. Powered by p3k. This site supports Webmention.
Except where otherwise noted, text content on this site is licensed under a Creative Commons Attribution 3.0 License.
IndieWebCamp Microformats Webmention W3C HTML5 Creative Commons