Breaking up FEP d8c2 (OAuth 2.0 profile for the ActivityPub API)
Technical Discussion
2
Beiträge
2
Kommentatoren
0
Aufrufe
-
Hey, all. So, almost two years ago I wrote this FEP:
It defines a profile for using OAuth 2.0 with the ActivityPub API, with a few components:
- Using the bog-standard OAuth authorization code flow as described at https://oauth.com/, including PKCE
- Using the
endpoints,oauthAuthorizationEndpointandoauthTokenEndpointproperties of an actor for discovery of endpoints - Using a small set of scopes (defined in the FEP as 'read', 'write' and 'sameorigin', but with a much longer more detailed list here
- A registrationless client ID mechanism that depends on having an Application ActivityPub object live on the Web.
Of these 4 points, I think the first two are defined pretty well elsewhere. It is probably a good idea to just let those be defined elsewhere. I think the possibility of an OAuth TF for the SocialCG suggests that those options can be worked out there.
That leaves the two novel parts of the FEP: the registration-less client IDs, and the scopes. I think I'd like to slim down the current FEP to just the registration-less client IDs, and start another FEP for the scopes.
-
Hey, all. So, almost two years ago I wrote this FEP:
It defines a profile for using OAuth 2.0 with the ActivityPub API, with a few components:
- Using the bog-standard OAuth authorization code flow as described at https://oauth.com/, including PKCE
- Using the
endpoints,oauthAuthorizationEndpointandoauthTokenEndpointproperties of an actor for discovery of endpoints - Using a small set of scopes (defined in the FEP as 'read', 'write' and 'sameorigin', but with a much longer more detailed list here
- A registrationless client ID mechanism that depends on having an Application ActivityPub object live on the Web.
Of these 4 points, I think the first two are defined pretty well elsewhere. It is probably a good idea to just let those be defined elsewhere. I think the possibility of an OAuth TF for the SocialCG suggests that those options can be worked out there.
That leaves the two novel parts of the FEP: the registration-less client IDs, and the scopes. I think I'd like to slim down the current FEP to just the registration-less client IDs, and start another FEP for the scopes.
Hey evan@activitypub.space, I am all-in on more, simpler FEPs over monolithic impenetrable FEPs.
I take it that points 1 and 2 are due to concerns raised by thisismissem@hachyderm.io about how OAuth2 properties are already advertised in a standardized manner (I believe per OIDC or similar?) — no objections there.
On the topic of scopes, I know benpate@mastodon.social's 3b86 (Activity Intents) had some ideas on defining intents that have some parallels to scopes. I don't agree with hardcoding them all into the FEP itself, but I'm interested in exploring how we structure scopes so that they're more straightforward as not quite as fine-grained — a single scope for every ActivityStreams activity type might be a bit of overkill.
