Including the `client_discovery` parameter or not

[tplooker]

During IIW, a good point was raised about whether the specification should require a new parameter client_discovery for the client to indicate to the AS that its client_id is a URL.

Here is a brief summary of comments for and against this

For

• The request(s) prepared by the client are simpler.
• There would be no need to defined the client_discovery parameter against all the existing OAuth grant types so this feature can be used
• Passing a parameter who's only possible value is true feels awkward (unfortunately RFC 6749 rules out parameters without a value)

Against

• An AS/OP supporting the client discovery feature has to try and figure out whether the client is intending to use the client discovery feature. Which may involve first looking the client ID up in the AS/OP DB for a match and if not try to parse the client id as a URL. This implicit behaviour means an AS/OP supporting this feature and also traditionally registered clients will likely have to do a URL parse on every client ID it does not find a record for because there is no explicit parameter from the client that allows the AS/OP to seperate this case. Conversely when the client ID is a url the AS/OP will likely be forced to lookup the value in their DB of registered clients before evaluating it is a URL, making the DB call redundant.

[tplooker]

Another possible proposal is to transform this parameters value into a enum which members control where the metadata is resolved from allowing for interoperable support between oauth and openid-federation, for example

When the clients metadata is available at /.well-known/oauth-client the client discovery parameter value would be client_discovery=oauth. When the clients metadata is available at /.well-known/openid-federation the client discovery parameter value would be client_discovery=openid-federation.

[tplooker]

Shifted the approach towards client id schemes instead which is aligned to OpenID4VCI