tplooker
commented
1 year ago I agree and support the intent of this issue and in general there appears to be significant overlap in scope between this draft and the automatic registration mechanism described in the OpenID Federation draft, however there does also appear to be some differences that I think are important to highlight.
Similarities
- Both drafts define a way for a client to set the client_id in an authorization request to a URL (or encoded URL value) alongside an additional request parameter, called
client_discoveryin this draft andautomatic_registrationin federation draft which is used as a signal to indicate to the AS/OP that the client is identifying itself in this manner as opposed to the more conventional approach with OAuth2 that involves using a pre-assigned client_id supplied by the AS. - In both drafts the client is expected to expose its metadata at a well-known endpoint,
/.well-known/oauth-clientin this draft and/.well-known/openid-federationin openid federation.
Differences
Automatic registration as defined by openid federation is more specifically defined to address the usecases around openid federation. Whereas OAuth client discovery is designed to be generally useful within OAuth2, that is any OAuth2 flow should be able to make use of this "client discovery" feature, for example:
- OpenID federation defines a parameter for use in the authorization request but not the token request, meaning OAuth flows that involve the client interacting at the token endpoint or perhaps starting here is somewhat undefined (again this is probably because federation does not have such usecases for these flows)
- OpenID federation sets the expectation around the usage and validation of entity attestations and requires the usage of the signed request object for client authentication in the authorization request. Whereas OAuth client discovery is only focused on how a client makes its metadata available at a well-known endpoint for consumption by an AS/OP and how the client indicates this capability in an authorization and or token request towards the AS/OP.
There's a long history of cooperation between the OAuth working group and the OpenID Connect working group to keep equivalent features in both sets of standards compatible with one other, by design. This has served the industry well.
Typically such features are invented by the OpenID Connect working group and then subsetted to back-port them to OAuth 2.0. Here's some examples:
We have another opportunity with this spec to bring another existing feature invented by the OpenID Connect working group to OAuth in a compatible way - in this case, Automatic Client Registration. This already-deployed feature accomplishes the goals of this proposed specification. (I'll also note that the inventors of the feature designed it explicitly to be usable by pure OAuth deployments - not just OpenID Connect Federation deployments.) As I see it, there would need to be a very compelling reason to invent and standardize a different and incompatible OAuth Automatic Client Registration mechanism.
Therefore, please update the spec to do what we've always done before: Create an Internet Draft that retains the subset of the existing functionality that's relevant to the OAuth 2.0 ecosystem in a compatible way. I'd be glad to help you do that. Thanks!