UPDATE: I gave a petulant answer here. Any feedback is good feedback, and Em has an important topic I need to address in the document. I'm sorry, @thisismissem .
@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.
"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 "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.
@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.
UPDATE: Fair. I'll try to dig into figuring out how OIDC could apply to the ActivityPub API, and whether this profile could be streamlined or just omitted by adopting it.
@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.
I'm sure there's a way to create an instrument 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@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
@evan@timbray so OIDC Federation, or even Client Identifier Documents (as proposed by Solid OIDC) resolve that issue whilst maintaining unique client credentials
@thisismissem@timbray so, OIDC Federation seems really complicated; all the trust chains and what have you. Is the trust aspect necessary? Who would act as the root of trust? It gives me an uncomfortable feeling.
@evan@timbray tbh, the trust chains in OIDC Federation are complicated, but the overall notion of a client using an IRI as it's client_id when registering is really cool / powerful
@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.
Add comment