I realized that I dislike the OAuth Client ID Metadata document that's supposed to supersede the Dynamic OAuth Client Registration mechanism:
-
@thisismissem@hachyderm.io @mariusor@metalhead.club we should go back to explain in schools what a presentation layer is?
@uriel please engage with argumentation and in good faith or keep your dismissive hot takes to yourself.
-
> 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.
