I realized that I dislike the OAuth Client ID Metadata document that's supposed to supersede the Dynamic OAuth Client Registration mechanism:
-
I realized that I dislike the OAuth Client ID Metadata document that's supposed to supersede the Dynamic OAuth Client Registration mechanism:
OAuth Client ID Metadata Document
OAuth Client ID Metadata Document
IETF Datatracker (datatracker.ietf.org)
The first complain is that it seems to address only online clients - ie, to be able to determine an attempt at OAuth authorization has a valid client, its ID needs to be a document that's addressable on the web and returns valid metadata.
So offline clients are left to invent some static web metadata storage for themselves, which frankly is not feasible.
1/2
-
I realized that I dislike the OAuth Client ID Metadata document that's supposed to supersede the Dynamic OAuth Client Registration mechanism:
OAuth Client ID Metadata Document
OAuth Client ID Metadata Document
IETF Datatracker (datatracker.ietf.org)
The first complain is that it seems to address only online clients - ie, to be able to determine an attempt at OAuth authorization has a valid client, its ID needs to be a document that's addressable on the web and returns valid metadata.
So offline clients are left to invent some static web metadata storage for themselves, which frankly is not feasible.
1/2
Second problem is related to how my implementations of #GoActivityPub handle OAuth clients presences already, by using fully compatible ActivityPub actors which exist at the URL which forms the Client ID.
So now I have a conflict where the same ID needs to be at the same time an ActivityPub Actor and a OAuth Metadata document.
This should be trivially solvable with different content types for the two documents but there are the following problems: one, the specification doesn't tell us which content-type the OAuth metadata should use, and two, how many servers would actually use it?
2/2
-
Second problem is related to how my implementations of #GoActivityPub handle OAuth clients presences already, by using fully compatible ActivityPub actors which exist at the URL which forms the Client ID.
So now I have a conflict where the same ID needs to be at the same time an ActivityPub Actor and a OAuth Metadata document.
This should be trivially solvable with different content types for the two documents but there are the following problems: one, the specification doesn't tell us which content-type the OAuth metadata should use, and two, how many servers would actually use it?
2/2
@thisismissem since the document has you as an author, and forgive me for using this method of contact, is it possible that the content-type is specified clearly in the spec? Preferably more finely defined than just "application/json" that RFC7591 uses.
Or if that's unfeasible, a request header of some sort, to allow services to identify that the request *is* a OAuth2 Client ID Metadata request, and not something else.
-
@thisismissem since the document has you as an author, and forgive me for using this method of contact, is it possible that the content-type is specified clearly in the spec? Preferably more finely defined than just "application/json" that RFC7591 uses.
Or if that's unfeasible, a request header of some sort, to allow services to identify that the request *is* a OAuth2 Client ID Metadata request, and not something else.
@mariusor it is just a JSON document though. You may want to open an issue to explain your concerns (it's linked from the document)
-
@mariusor it is just a JSON document though. You may want to open an issue to explain your concerns (it's linked from the document)
@mariusor if you're for some reason using the same URI for ActivityPub actors and CIMDs, which I don't know why you'd do since they're very different resources, but in that case, yes you'd encounter issues.
If you want to link a CIMD and an Actor, you could add an additional metadata field & actor property.
But this is an easily solvable problem without adding extra headers or content-types
-
@mariusor if you're for some reason using the same URI for ActivityPub actors and CIMDs, which I don't know why you'd do since they're very different resources, but in that case, yes you'd encounter issues.
If you want to link a CIMD and an Actor, you could add an additional metadata field & actor property.
But this is an easily solvable problem without adding extra headers or content-types
@mariusor and yes, CIMDs require the metadata document to be publicly accessible so the authorisation servers can request it. You could deploy DCR and CIMDs in one AS if you really wanted to. As for desktop apps, they usually have a website somewhere, so use that to host the json file for the CIMD.
-
@mariusor if you're for some reason using the same URI for ActivityPub actors and CIMDs, which I don't know why you'd do since they're very different resources, but in that case, yes you'd encounter issues.
If you want to link a CIMD and an Actor, you could add an additional metadata field & actor property.
But this is an easily solvable problem without adding extra headers or content-types
> 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.
-
> 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 it is just a JSON document though. You may want to open an issue to explain your concerns (it's linked from the document)
@thisismissem@hachyderm.io @mariusor@metalhead.club we should go back to explain in schools what a presentation layer is? -
@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!
