busybee fluffy rambles

My understanding about what happened before I joined in is that a few folks did end up implementing an end-to-end version of AutoAuth flow, but they decided that there were still too many parts to deal with for the entire implementation and wanted to separate out parts of the protocol to capture what we actually want out of this mechanism, which is absolutely fair.

What I liked about the idea of AutoAuth was that people could subscribe to any arbitrary feed in their social reader and opt into (securely) sharing their identity with the publisher, and then the publisher could opt into (securely) adding their private posts into the feed. But the protocol behind that is rather complex and not necessarily what’s needed for the flow, and we eventually reached a consensus that the subscription part could be designed and implemented separately from the access grant.

Aaron had a sketch of a protocol up on his screen, but I didn’t quite understand the flow based on the text notes and his verbal explanation, and I’m hoping that he’ll be able to document it on the wiki at some point, but in the meantime, my takeaway of how things could possibly work:

1. A feed with a privacy upgrade available can respond with a WWW-Authenticate: header (per AutoAuth)
2. The reader UX indicates that authentication might be an option
3. Somehow the following relationship is established between the reader and the publisher, and the publisher provides a bearer token to the reader
4. The reader makes future requests with the appropriate Authorization: Bearer xxxxx header

For what it’s worth, Publ already supports steps 1 and 4, and so I want to propose a mechanism for step 3 (which would be fairly easy for me to implement into Publ and possibly into Feed On Feeds): If a user is logged in to a site, the site will provide the bearer token. Specifically, it would do so in one or more of the following ways:

• A response header, e.g. Access-Token: Bearer xxxxx
• An HTML header, e.g. <meta http-equiv="Access-Token" content="Bearer xxxxx">
• Displayed UX, such as a display to the end user with reasonable messaging regarding the value of the Authorization: Bearer xxxxx header to add to their reader manually

The first two could work alongside a future AutoAuth-type flow in the reader, or a user extension for the browser to show some flow for adding the access token to their compatible reader or whatever. The third one would cover a manual flow.

This does lead to some questions, like how do we handle things like token expiration (both from timeouts and from revocation). I think that this can still be covered by a simple flow; first, we’d suggest that any token expiration be fairly long-lived (like, on the order of months, if not permanent). Next, if a token has expired, then the retrieval of the resource should raise a 401 Unauthorized header, which would indicate to the reader that the token needs to be updated.²

I’m tempted to try hacking this into Feed On Feeds, but I think what I really want to do going forward is to use this as an excuse to finally start writing Subl, as just a very basic social reader that provides subscription and manual-flow authentication UX. Automation-flow can come later.

Anyway, I’m hoping that the following folks will have feedback on this proposal: Aaron, Tantek, Sven, and Jackie.

Update: Another thing that occurs to me is that there can be a link in the feed like <link rel="authorization" href="https://example.com/authorization"> which provides a human-readable page with information about how to login and get the bearer token or something? So if that’s present, the feed reader can provide that informational link as part of the UX. (Or maybe it should be a rel="alternate" but that’s really annoyingly overloaded at this point…)

Update 2: Okay so what Aaron had in mind is pretty orthogonal to this; his proposal is for how two IndieWeb users provide the bearer token to one another, which makes for some very nice UX ideas when it comes to people who are in a fully-IndieWeb experience, but doesn’t really work so well for other user stories (for example, using a “legacy” reader like Feed On Feeds/feedly/etc., or using authentication other than IndieAuth), and it also means there needs to be some coupling between the reader’s ticket server and their MicroSub reader, or some other approach for the reader to get the token from the ticket server for injection into the feed reader. These two approaches can both live in the wild and coexist, and I’d hope that anyone who implements one will implement the other as appropriate.

I’ll probably work on implementing my general proposal (starting with the token grant UX from Publ, followed by either adding tokens to Feed On Feeds or building the skeleton of Subl with bearer token UX from the get-go — the latter feels way more feasible, TBH), and when someone else has implemented the ticket grant thing it’ll be pretty easy for me to add that to Publ. I’m thinking that when someone signs in with a method that supports a ticket endpoint, Publ just goes ahead and sends them a ticket. (This will tie in to me finally getting around to adding profile support to Authl.)

Anyway! This is the most excited I’ve been about reader authentication in a while. Let’s build this thing! (Yay IndieWeb!)