I realized that I dislike the OAuth Client ID Metadata document that's supposed to supersede the Dynamic OAuth Client Registration mechanism:
-
> I don't know why you'd do since they're very different resources
@thisismissem I feel like we had this discussion before.
As long as I reconstitute both, the ActivityPub Actor and the OAuth2 Client Metadata, from the same underlying data they are the same to me and I want them under the same URL.
So, as a developer, I would expect that any ontology that we make use of for building this thing we call "the Fediverse", and which need to ultimately be based on HTTP, has to respect its basic tenets: URLs represent resources and, in order to get distinct representations you use Content-Types. Spec'ing something that violates this is questionable to me.
@mariusor but they're not the same data, they will never be the same data. One is an OAuth Client the other is an ActivityPub Actor, they've both very specific properties.
Following Evan's draft FEP will get you into a lot of mess like this.
A CIMD can come from anywhere on the internet, so you're not guaranteed to be able to request an actor from a CIMD URI, if you want something linking a CIMD and an AP Actor, you should add a property to the CIMD to link to the Actor and a property to the Actor to backlink to the CIMD. But such a link would be strictly optional.
Trying to treat these two very different entities as the same is not going to lead to a good outcome, and the issues you're having are coming from that incorrect assertion that they are the same thing.
-
@evan @mariusor Evan, politely, keeping this draft FEP up is doing the community a great miss-service with how it completely butchers client registration and the security issues it has. It really should be withdrawn and revised down to just declaring that we use standard OAuth 2 discovery mechanisms, don't do the Actor mess and instead use CIMDs which are in the OAuth WG standards track (they're adopted by the OAuth WG and will likely become an RFC)
-
@evan @mariusor Evan, politely, keeping this draft FEP up is doing the community a great miss-service with how it completely butchers client registration and the security issues it has. It really should be withdrawn and revised down to just declaring that we use standard OAuth 2 discovery mechanisms, don't do the Actor mess and instead use CIMDs which are in the OAuth WG standards track (they're adopted by the OAuth WG and will likely become an RFC)
@thisismissem @mariusor thanks for the note! I'm going to revise it to just document the ActivityPub-native client ID structure. Working out how to negotiate discovery, cimd, dynamic client registration, and client registration properties of the actor will go to an OAuth Profile report for the ActivityPub API task force.
-
@thisismissem @mariusor thanks for the note! I'm going to revise it to just document the ActivityPub-native client ID structure. Working out how to negotiate discovery, cimd, dynamic client registration, and client registration properties of the actor will go to an OAuth Profile report for the ActivityPub API task force.
@thisismissem @mariusor please feel free to file a bug on the FEP or an issue on activitypub-api.
-
@thisismissem @mariusor thanks for the note! I'm going to revise it to just document the ActivityPub-native client ID structure. Working out how to negotiate discovery, cimd, dynamic client registration, and client registration properties of the actor will go to an OAuth Profile report for the ActivityPub API task force.
@evan @mariusor just revise it down to the scopes you want, use standard and upcoming standards instead of trying to define a new standard; If anything, define a property to link a Actor with a CIMD and a new client metadata property for like actor_uri to be registered with IANA: https://www.iana.org/assignments/oauth-parameters/oauth-parameters.xhtml#client-metadata
-
@evan @mariusor just revise it down to the scopes you want, use standard and upcoming standards instead of trying to define a new standard; If anything, define a property to link a Actor with a CIMD and a new client metadata property for like actor_uri to be registered with IANA: https://www.iana.org/assignments/oauth-parameters/oauth-parameters.xhtml#client-metadata
@thisismissem @mariusor I'm just going to document the current structure for backwards compatibility, recommend CIMD and dynamic registration in the TF report, and put the rest of my effort into scopes for the ActivityPub API.
Are you going to FOSDEM?
-
@thisismissem @mariusor I'm just going to document the current structure for backwards compatibility, recommend CIMD and dynamic registration in the TF report, and put the rest of my effort into scopes for the ActivityPub API.
Are you going to FOSDEM?
-
@thisismissem @mariusor I'm just going to document the current structure for backwards compatibility, recommend CIMD and dynamic registration in the TF report, and put the rest of my effort into scopes for the ActivityPub API.
Are you going to FOSDEM?
@evan @mariusor on dynamic client registration (DCR), you'd not go wrong to note that this does have a drawback of potential explosion of registrations for what is effectively the same client, and that this can become a maintenance / operations problem. That's why we introduced CIMDs, to tackle that issue.
-
@thisismissem @mariusor that's too bad. I hope you feel better.
-
@evan @mariusor on dynamic client registration (DCR), you'd not go wrong to note that this does have a drawback of potential explosion of registrations for what is effectively the same client, and that this can become a maintenance / operations problem. That's why we introduced CIMDs, to tackle that issue.
@thisismissem @mariusor I think it also makes it harder, but not impossible, to have distributed reputation systems for clients. I think it's a lot easier with CIMD!
-
@thisismissem @mariusor that's too bad. I hope you feel better.
-
@thisismissem @mariusor I think it also makes it harder, but not impossible, to have distributed reputation systems for clients. I think it's a lot easier with CIMD!
@evan @mariusor yeah, CIMDs provide a lot of benefits in authentication for decentralized systems. Sure, DCR lets you have a clientSecret which is "easy" for getting a confidential client, but really you probably want a CIMD with Client Attestations: https://www.ietf.org/archive/id/draft-ietf-oauth-attestation-based-client-auth-07.html
Bluesky have a similar draft here: https://github.com/bluesky-social/proposals/tree/main/0010-client-assertion-backend (it's slightly different)
Basically this allows you to use the OS provider device attestation features to ensure that the application authenticating with your CIMD is really your application, which allows you to do confidential clients for like mobile and desktop apps.
-
@thisismissem @mariusor thanks for telling me.
-
@mariusor but they're not the same data, they will never be the same data. One is an OAuth Client the other is an ActivityPub Actor, they've both very specific properties.
Following Evan's draft FEP will get you into a lot of mess like this.
A CIMD can come from anywhere on the internet, so you're not guaranteed to be able to request an actor from a CIMD URI, if you want something linking a CIMD and an AP Actor, you should add a property to the CIMD to link to the Actor and a property to the Actor to backlink to the CIMD. But such a link would be strictly optional.
Trying to treat these two very different entities as the same is not going to lead to a good outcome, and the issues you're having are coming from that incorrect assertion that they are the same thing.
@thisismissem I think it's very telling that you think the protocol designer is the one that gets to decide what the resources that the software that others develop should be. I'm telling it to you as a fact: for my application both the Actor and the OAuth client metadata are built from the same source and I want to have them under the same URL. I'm not assuming anything about external clients that can host their metadata how they want without any guarantees. I'm talking about mine.
This is about my application and my expectations from the spec, but since I see you're adverse to other points of view, I'll drop from this dialogue.
-
@thisismissem I think it's very telling that you think the protocol designer is the one that gets to decide what the resources that the software that others develop should be. I'm telling it to you as a fact: for my application both the Actor and the OAuth client metadata are built from the same source and I want to have them under the same URL. I'm not assuming anything about external clients that can host their metadata how they want without any guarantees. I'm talking about mine.
This is about my application and my expectations from the spec, but since I see you're adverse to other points of view, I'll drop from this dialogue.
@mariusor well you can't content negotiate two pieces of content with effectively the same content type.
That's a downside of content negotiation. We've written the draft to accept any JSON content type, whether application/json, or something more explicit like application/ld+json (this is for backwards compatibility with Solid OIDC)
There's really limited value in introducing a application/cimd+json content type, and requiring such would require all hosts of CIMDs to server them with a non-default content-type.
At the end of the day we'll accept any JSON content type.
My recommendation is to server the CIMD at a different path since both documents you want to serve can both be validly requested as application/json in the Accept header. Sure, AP does have application/activity+json and application/ld+json; profile=... but it also will very commonly accept any JSON content type.
-
@mariusor well you can't content negotiate two pieces of content with effectively the same content type.
That's a downside of content negotiation. We've written the draft to accept any JSON content type, whether application/json, or something more explicit like application/ld+json (this is for backwards compatibility with Solid OIDC)
There's really limited value in introducing a application/cimd+json content type, and requiring such would require all hosts of CIMDs to server them with a non-default content-type.
At the end of the day we'll accept any JSON content type.
My recommendation is to server the CIMD at a different path since both documents you want to serve can both be validly requested as application/json in the Accept header. Sure, AP does have application/activity+json and application/ld+json; profile=... but it also will very commonly accept any JSON content type.
@thisismissem i know i'm a month late on this but
> requiring such would require all hosts of CIMDs to server them with a non-default content-type
it doesn't. http servers can serve less specific media types any time for any reason. having a cimd+json type lets you negotiate for that explicitly
> two very different entities [...] incorrect assertion that they are the same thing
why should i have to identify a client as client.example/cimd.json instead of client.example?
-
@thisismissem i know i'm a month late on this but
> requiring such would require all hosts of CIMDs to server them with a non-default content-type
it doesn't. http servers can serve less specific media types any time for any reason. having a cimd+json type lets you negotiate for that explicitly
> two very different entities [...] incorrect assertion that they are the same thing
why should i have to identify a client as client.example/cimd.json instead of client.example?
@thisismissem i can (and probably will) file issues about this but i wanted to note that i find the argument that "client metadata" and "client metadata" are somehow different things is unconvincing
-
@thisismissem i can (and probably will) file issues about this but i wanted to note that i find the argument that "client metadata" and "client metadata" are somehow different things is unconvincing
@thisismissem actually wait, per 4.1 "The client metadata document MAY define additional properties in the response" and also per 4.1 "The client metadata document MAY also be served with more specific content types as long as the response is JSON and conforms to application/<AS-defined>+json"
so... there shouldn't be any problem? requesting cimd+json or similar lets the server know what your intended processing model is though. it's "i want a cimd specifically" instead of "i want any old json"
-
@thisismissem i know i'm a month late on this but
> requiring such would require all hosts of CIMDs to server them with a non-default content-type
it doesn't. http servers can serve less specific media types any time for any reason. having a cimd+json type lets you negotiate for that explicitly
> two very different entities [...] incorrect assertion that they are the same thing
why should i have to identify a client as client.example/cimd.json instead of client.example?
@trwnh on #2, because we require a file path. That's been in the draft from rather early on
For #1, even if we did register a application/cimd+json, all requests would still need to be aent as accepting: application/cimd+json, application/json
Why? Because some places you might serve a CIMD from may not be able to serve cimd+json and return an error response (iirc, github pages + github raw APIs come to mind)
That makes implementation for all CIMD processing a little bit more bug prone.
Also CIMDs MUST return 200 Ok, no other status code is accepted.
But still, a CIMD is not the same as an ActivityPub Actor: they have almost no overlap between them.
-
@trwnh on #2, because we require a file path. That's been in the draft from rather early on
For #1, even if we did register a application/cimd+json, all requests would still need to be aent as accepting: application/cimd+json, application/json
Why? Because some places you might serve a CIMD from may not be able to serve cimd+json and return an error response (iirc, github pages + github raw APIs come to mind)
That makes implementation for all CIMD processing a little bit more bug prone.
Also CIMDs MUST return 200 Ok, no other status code is accepted.
But still, a CIMD is not the same as an ActivityPub Actor: they have almost no overlap between them.
@trwnh we also MUST support application/json for CIMD documents for backwards compatibility with Solid-OIDC
