Add spec for creating an OAuth `client_id`

[benpate]

OAuth typically requires pre-registration of potential clients before connections can be made. This obviously doesn't work for our server-to-server authorization scenario. The spec MUST include guidance on this.

There are several ways we could accomplish this, with CIMD (recommended by @ThisIsMissEm) seeming like the simplest option. For reference, Mastodon uses RFC 7591 to register clients dynamically (EDITED: Mastodon DOES NOT use RFC 7591), and FEP-d8c2 provides a way to do this by embedding information in the server-wide Application actor.

I'll recommend saying requiring CIMD, while mentioning that RFC 7591 exists, and might be used by clients/servers in other situations. If there's consensus on this, I'm happy to write the PR.

[ThisIsMissEm]

Mastodon does not use RFC 7591, see: mastodon/mastodon#30154

[ThisIsMissEm]

FEP-d8c2 only includes a fraction of the information that actually exists about a client, and has no real relationship to the IANA OAuth Dynamic Client Registration Metadata registry.

Client ID Metadata Documents, or CIMDs, are just JSON documents containing the properties defined in that registry with a few restrictions (no symmetrical keys, client_id must equal document URI, etc)

[ThisIsMissEm]

Also, the language currently used in the draft implies that when using DPoP the client_id is optional, this is not the case. DPoP gives you a cryptographically bound token, so like, instead of doing Authorization: Bearer <token> in requests to resources, you do Authorization: DPoP <dpop token>. The rest of OAuth works just the same, but you may be required to supply a DPoP nonce when interacting with the authorization server.

[ThisIsMissEm]

DPoP is probably more important in untrusted contexts, so like, when the client is a public client and the token exists in the browser, you don't really want it to be captured by intermediaries and usable, so you use DPoP bound tokens to ensure only the client with the private key can make requests with the token

[benpate]

Mastodon does not use RFC 7591, see: mastodon/mastodon#30154

Apologies, @ThisIsMissEm, my mistake. I knew there was some kind of dynamic registration, and just read the heading (which is misleading) but not the text of the link I posted.

In any case, this makes a fourth alternative way of registering clients dynamically:

• CIMD
• FEP-d8c2
• RFC 7591
• Whatever Mastodon is doing

Gosh, I love open standards :)

In any case, I'd love for us to pick the best of these and write it into the Data Portability spec clearly, so that there's a single, golden way to get the job done.

[ThisIsMissEm]

@benpate Mastodon will eventually be moving to CIMD, it's just a really slow process because there's no funding to fully support that work. Like, I've already started work upstream in the Doorkeeper gem, and started implementing the other things that we'd need before safely rolling out CIMD (e.g., public clients, expiring access tokens, refresh tokens, etc).

[benpate]

DPoP is probably more important in untrusted contexts, so like, when the client is a public client and the token exists in the browser, you don't really want it to be captured by intermediaries and usable, so you use DPoP bound tokens to ensure only the client with the private key can make requests with the token

This is good to know. My hot take on DPoP is that it would be more work, and (for server-to-server) not much added security. So if it doesn't seem especially necessary, it would be great to trim this from the spec. There's already so much cryptography required to get this done as it is.