I started a FEP to define an #OAuth 2.0 profile for the #ActivityPub API (“c2s”):

https://codeberg.org/fediverse/fep/pulls/162

I’d appreciate any feedback or support. I’ve begun implementing this profile, and I think it’s testing out pretty well.

Probably the two things that are novel about this profile:

1. It uses ActivityPub IDs as the client ID in the OAuth authorization flow.
2. It includes a scope for only writing to a particular server.

@evan why not just OIDC? It's already well defined..

@thisismissem

Has there ever been a helpful technical comment that started with "Why not"?

@evan no, I mean, I don't see why it'd make sense to define a custom profile of OAuth 2.0 when OIDC exists and we could just use it?

What does defining a custom profile really give us? Our authentication needs can't be that unique, can they?

@thisismissem I guess you're not going to actually get specific, so now I get to go into the part of the "why not" question where I have to figure out what part of the document you didn't read you think OIDC applies to.

I'll start at the beginning: are you thinking about the OpenID Connect dynamic client registration feature?

https://openid.net/specs/openid-connect-registration-1_0.html

@evan so currently all the different fediverse services that implement OAuth implement different bits of specs & don't support discovery of authorization server metadata; additionally, they rarely support PKCE. Dynamic Client Registration is supported, but OIDC Federation would likely be better.

The scopes you define look like they could conflict with existing implementations, and are also not discoverable by the client.

@thisismissem

I'll take this a step at a time.

"so currently all the different fediverse services that implement OAuth implement different bits of specs & don't support discovery of authorization server metadata"

Right, that's why an OAuth 2.0 profile is necessary. Very few of them implement the ActivityPub API, either.

@thisismissem "additionally, they rarely support PKCE." right.

@thisismissem "but OIDC Federation would likely be better."

Why? OIDC only has a few scopes related to profile data. Why would this be appropriate for the ActivityPub API?

@thisismissem "The scopes you define look like they could conflict with existing implementations"

This seems low risk. I would be really surprised if there are implementations with "read" and "write" scopes that don't mean about what this spec defines.

"and are also not discoverable by the client."

That's what the FEP is for.

@evan @thisismissem
I don't think you should blow the question off, though. There is good library support for OIDC everywhere. Also, the OIDC development process showed that creating OAuth 2 profiles can be brutally long and complex.

@timbray @thisismissem

I'm not blowing off the question. I just hate the framing. Not to worry, I realise I'm going to have to do this work anyway.

@timbray @thisismissem I can say that one nice part about using an ActivityPub ID for the client ID is that it is global; the same app using two different servers will have the same ID.

This lets us do things like use shared app blocklists, reputation systems, and other security mechanisms.

Dynamic registration introduces a new ID for every server, so you can't compare across servers.

Also, an ActivityPub ID can double as the `instrument` part of generated `Activity` objects automatically.

@timbray @thisismissem I'm sure there's a way to fake it with dynamic registration, but I think it would end up having different ActivityPub IDs for each server. Maybe there's a way to get around it with dynamic registration, though.

@timbray @thisismissem Oh, and with dynamic client registration, the client app needs to keep track of the generated ID for each server it uses. Using an ActivityPub ID, it just has to keep one hard-coded string. Easy-peasy.

@evan correct

@evan @timbray that's actually not necessarily a good thing in terms of dynamic client registration, where unique authorization servers should give unique client credentials

@evan @timbray that is, DCR giving different credentials across authorization contexts is an important feature. I'm not sure how this could harm sharing blocklists or similar

@thisismissem @timbray right, whereas using the ActivityPub ID means you have the same credentials across different servers.

Credential management on the client side, and not being able to compare clients on the server side, seem like disadvantages, not advantages.

Am I missing something?

@thisismissem @timbray another thing I forgot to mention is that the ActivityPub ID can be an an actor ID, with an `inbox` and `outbox`. So, it's possible to follow the app, send feedback, or whatever other kind of live interactions are needed.

@evan @timbray I think that'd be achievable via OIDC Federation or Client Identifier Documents too!

@evan line 26 having => have
line 29 for client developers had => remove had

@thisismissem there is no "just use" OIDC, it would still require defining a profile. Plus I don't think most ActivityPub implementations benefit from most of the features OIDC brings.

I see the proposal has just been merged and now links out to a socialhub link? Where is the best place to continue discussing this? I have ... a lot of feedback as you might imagine.

https://socialhub.activitypub.rocks/t/fep-d8c2-oauth-2-0-profile-for-the-activitypub-api/3575

@aaronpk that's perhaps fair, though I think OIDC smooths out a lot of OAuth 2.0's rough edges

@thisismissem If you want to see a profile that really smoothes out the rough edges, check out the OpenID FAPI profile. The whole goal of that is high security and interoperability. OpenID core is still pretty loose.

@aaronpk I've seen that, but haven't yet fully looked at it.. it always looked so... financial related?

@thisismissem Yeah that is an artifact of its origins, but they took "Financial" out of the name and now it's just "FAPI". Think of it as just a high-security profile, one which would likely be useful for financial related industries and others with similar concerns.

@aaronpk I can indeed imagine! I think the best place is the Social hub thread.

@aaronpk one big question is that it refers to oauth2simplified almost normatively, and I wonder if that's sufficient or if it needs to be tightened up.

@aaronpk aah, okay!

@aaronpk another is that I need more examples of profiles that use a client-supplied https:// URL as the client ID.

@thisismissem mentioned that Solid uses the same pattern. I'd like to collect some other examples.

@evan @aaronpk note: Solid is looking at moving to OIDC Federation, as far as I know, it's certainly been discussed back around the start of the year.

But URIs/IRIs as client_id's are really really cool in decentralised systems.

@thisismissem @aaronpk I think the two methods are compatible, aren't they? A server could support either or both.