busybee fluffy rambles

Recent spec change

There was a recent change to the specification which leads to some incompatibility around scopeless identity verification. This is a flow that’s used for simple sign-on to websites; for example it’s what Authl uses, as it’s not requesting permission to the user’s resources, but just associating the user with an identity. This is a pretty common use case for IndieAuth.

In the previous version of the spec, the scopeless identity verification used response_type=id and didn’t specify a scope; these two options were mutually-exclusive, and this led to a somewhat confusing spec. The latest spec update changes this flow to use response_type=code and to simply omit the scope. This is a much better protocol in general, but it has the problem of being fundamentally incompatible with older endpoints which do strict parameter checking.

Unfortunately, the current spec doesn’t document the legacy response_type=id as a backwards-compatibility path, so any newly-written endpoints will not support older clients. Newer clients will attempt to send a scopeless response_type=code request which will fail on older endpoints.

The nature of the IndieAuth protocol also means that there’s no way for the client to know which protocol version is in use or to get notified that there was a failure, so the end result will be a bad user experience (such as their login page returning an opaque error about “missing scope” or “invalid response type” or whatever).

So, some suggested mitigations:

• Endpoint authors: Accept response_type=id with no scope parameter, possibly displaying a deprecation warning to the user (asking that they reach out to the client website to update to the latest version of the specification)
• Client authors: Always send response_type=code and request a meaningful but non-invasive-sounding scope, such as me or profile or whatever. (This is what Authl will be doing as of the next release.)

The actual scope for clients to request is very much up for debate. Here’s a few different things I’ve seen proposed:

• me: The most straightforward, in keeping with IndieAuth nomenclature. Literally all you’re asking for is the me URL, which is already a basic part of the verification response. But this is kind of confusing to end users.
• profile: This seems user-friendly, but there’s the possibility that future IndieAuth endpoints might use this as a cue to send the profile directly rather than making it a separate retrieval of h-card data from the identity URL. There’s reasons to do this, so I’d much rather reserve this scope for when IndieAuth supports it natively. On the other hand, it’d also be nice to just automatically start receiving profile data when endpoints start supporting that.
• email: This implies that someone will be able to do something unspecified with the user’s email. It’s also not actually an email address that is being requested in the first place.
• read: This implies being able to read private data. Keep this scope for things like micropub!

So for me the decision is either me or profile but both have caveats. I’ll probably go with profile since it seems like the least-confusing thing (at least in the context of Authl), but per the IndieAuth spec you should be able to use any scope you want. But there effectively has to be a scope, at least until every endpoint on the Internet has been updated or at least a reasonable amount of time has passed that all endpoints “should” have been updated.

Identity verification gap

IndieAuth is designed under the assumption that everyone has their own domain name, which is an admirable goal but has a few problems for a lot of people, who don’t have the technical acumen necessary to register and/or host their own domain but do have access to shared-domain hosting (such as tilde.club or their university-provided academic homepage). However, there’s nothing in the spec that actually requires that someone own their domain, and it’s quite possible for someone to declare an endpoint on such a webpage, with no way for someone to verify that the webpage is authoritative for the entire domain (after all, it’s just a <link> tag or a response header).

Where this becomes a security concern is that since the IndieAuth spec doesn’t require proof of ownership of the domain, it considers any authentication against any page on a domain to be authoritative for the entire domain. As a proof of concept, you can use tilde.club/~fluffy/ as an identity URL that will let you verify as any identity on tilde.club, at least for things that follow the IndieAuth spec. (This is one place where Authl diverges from the specification, because I needed a better identity guarantee for my use case.)

There are two mitigations I have proposed for client authors:

1. Require that the final verified URL be more specific, path-wise, than the original identity request; for example, allow https://example.com/ to verify as https://example.com/~alice/, but don’t allow https://example.com/~alice/ to verify as https://example.com/~bob/

   This is what Authl does at present. Codifying this in spec-friendly language is difficult, however, and there’s a bunch of sharp edges you have to watch out for (such as not allowing https://example.com/~alice to verify as https://example.com/~alice_sucks or whatever; “path components” aren’t really that strong of a thing in HTTP per se).

2. Require that the final identity URL declares the same authorization_endpoint as the verified URL

   This approach seems preferable, as it is much easier to clearly and concisely explain. It also allows for more exotic situations where multiple shared-domain users might want to be able to authenticate as each other for whatever reason (for example, I can see people who identify as plural systems making use of this).

Both of these approaches have been discussed somewhat on this spec issue as well as on IndieWeb Chat, and the general feeling I’ve gotten is that approach 2 is greatly preferable to everyone. So in the future I will probably change Authl to use approach 2.

Update: Everyone else seems to have agreed to the proposed identity URL verification change, and hopefully the spec change will be accepted soon (pending some other discussion regarding redirection behavior). Meanwhile, Authl has been updated with this draft proposal. And gosh, I really need to get around to setting up the PlaidWeb blog, huh…