I realized that I dislike the OAuth Client ID Metadata document that's supposed to supersede the Dynamic OAuth Client Registration mechanism:
-
@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.
