Supported RP/client metadata parameters

[rohe]

The metadata specification for OIDC RP (https://openid.net/specs/openid-connect-registration-1_0.html) and OAuth2 clients (https://www.rfc-editor.org/rfc/rfc7591.html) contains claims that specifies which of a set of values an RP/client prefers.

Take for instance token_endpoint_auth_method.
This claim specifies the requested authentication method for the token endpoint. There are no choices here.
The RP/client may support many but it has to choose one.

This works in a context where one OP/Client explicitly registers with one OP/AS.
It doesn't work so well in a federation context where the RP/client may be part of more then one federation (with different policies) or even if just a member of one federation and connected to more than one OP/AS using automatic registration.

In this context it would rather like to specifies which methods it supports rather than choosing one of them.

I would therefore propose that the claim client_registration_types which is the only metadata claim added for an RP by this specification should be changed to be client_registration_type (no -s) and furthermore to be accompanied by client_registration_types_supported.

The meaning should be that the RP supports all what is specified in client_registration_types_supported but would prefer to use what is in client_registration_type if possible.

This is just a first step.
After this I'd like to propose extensions to the OIDC RP and OAuth2 client metadata specifications to add _supported claims where appropriate but that should be handled elsewhere.

[selfissued]

We could do this in the Federation spec before it becomes final. Note that there are no current venues for extending OpenID Connect or OAuth 2 Client Metadata directly, so if we need this, OpenID Federation 1.0 is our ship vehicle.

[selfissued]

This is essentially a duplicate of https://bitbucket.org/openid/connect/issues/2158/metadata-parameter-value-arrays-for-rp .

[selfissued]

This was discussed on the 5-Aug-24 working group call. It's clear that we could do this and that it would be useful in contexts where a party other than the RP is making some of the choices.

It's an open question whether to do this in the Federation spec itself or as a separate extension to OpenID Connect Dynamic Client Registration metadata.

[Razumain]

Mike, thanks for pointing out that this discussion was here. I had this discussion earlier with Roland and he mentioned that he had brought it up here.

I like the "_supported" extension to single valued metadata parameters.

I agree with Roland that updates to metadata parameters should be handled outside of the Federation specification. The federation services process declared metadata in a fashion that is agnostic to what that metadata is. And I would hope that it stays that way. For this reason I think it is cleaner long term to fix metadata where metadata is defined.

But I support any solution, as long as it works.

[selfissued]

I am creating a new separate specification to achieve this, per the results of the discussion on the 8-Aug-24 OpenID Connect working group call.