I also have never been able to figure out what problem this FEP is supposed to solve. But if I assume that it does solve a problem, then I agree that defining a rigid subset of OAuth2 as a special case for activitypub is misguided.
And then if we assume that at some point C2S APIs implementing any sort of claim-encoding bearer token auth scheme became readily available, the set of claims proposed here doesn’t seem at all adequate. It’s hard to imagine wanting less than to be able to authorize specific activities.
Unfortunately, I don’t have enough time at the moment to familiarize myself with it. But I am absolutely in favor of using a standard server such as https://www.keycloak.org/ for authentication. So anything that conforms to the oauth2 specification and is feasible with keycloack should be ok!
It is NOT ok if an activityPub server takes over parts of the authentication or if auth requests should/must be routed via the activityPub server.
I think Aaron is actually talking about a subset of OAuth 2.0 specifically for ActivityPub, which in standards parlance is a “profile” of OAuth 2.0. Unrelated to actor profiles in ActivityPub.
ActivityPub (Jan 2018) predates RFC 8414 (Jun 2018) by 6 months. It was not “re-implementing part of another existing standard”.
This FEP is an OAuth 2.0 profile for the ActivityPub API. It uses ActivityPub-centric discovery and identification in order to be more useful for ActivityPub developers.
I’m happy to include additional scopes. I’ll try to add read:* scopes for the standard properties of actors (inbox, outbox, followers, following, …) and write:* scopes for the standard activity types defined in ActivityPub. I’ll add a read:all and write:all for the broader scope.
Finally, I’m happy to add a discovery process via RFC 8414, and a client registration mechanism via RFC 7591.
@jenniferplusplus the point is that you can write a client for one server implementing the ActivityPub API, and run it against another server implementing the ActivityPub API, and it just works. OAuth 2.0 has a pretty broad set of possible parameters, so the goal is to sufficiently constrain the parameters such that a client doesn’t need server-specific authentication code.
Whilst RFC 8414 was published by the IETF as a proposed standard in June 2018, the specification of it was in progress for a while before that, with work starting in 2015 on it, with several draft versions: RFC 8414 - OAuth 2.0 Authorization Server Metadata
So the properties were representing something well outside of the scope of ActivityPub, orthogonal to other standards processes.
But looking at these properties today, RFC 8414 would be the more preferable way, given that the properties alone do not allow you to complete authorization / authentication, given the other information that is required in order to complete an OAuth 2.0 flow successfully.
As we’re limiting this proposal to C2S APIs, which it sounds like that’s all this is to cover, then I think we should choose scopes that are much more specific to that purpose, as “read” or “write” is too general, and could mean anything from an OAuth 2.0 Authorization server.
Perhaps a specific prefix to the scopes is required? e.g., activitypub:c2s:read:actor, activitypub:c2s:read:activities, etc.
The other point I’d like to raise here is “how does this proposed standard profile conflict with other OAuth 2.0 usages within the fediverse?”
At present, it’d be difficult I think for Mastodon and Pixelfed to support this FEP, given they use standard OAuth Server libraries (doorkeeper gem and laravel passport respectively), and also the scopes and permissions may conflict.
I am sorry that you’re not happy with the decisions we made when we created ActivityPub, but they were made long ago. This FEP cannot change them.
Can you live with a compromise that recommends both the RFC 8414 discovery process and the ActivityPub properties? Clients and servers can support one or the other or both.
I like the idea of prefixed scopes. I’d say “activitypub:” is fine here. That should probably prevent any conflict.