Add client_id_scheme based on .well-known

[awoie]

It would be beneficial to introduce a client_id_scheme that

• enables the client to sign Request Objects using a key indirectly trusted via TLS/browser PKI.
• allows the client to provide its metadata via a .well-known endpoint rather than in the request itself without prior registration or federation.

Currently, the only method for implementing request signing leveraging browser PKI is by using client_id_scheme=x509_san_dns, which can be quite cumbersome to implement. Clients would need to acquire another certificate from a browser CA for request signing. Additionally, on some platforms, accessing the list of trusted browser CAs outside of a user agent might involve more friction. Acquiring an extra certificate would also takes extra monetary and operational costs. Furthermore, certificates acquired from existing browser CAs typically include X509 extensions optimized for TLS, not for request signing.

Compared to client_id_scheme=redirect_uri, a new scheme based on well-known would allow the signing of requests which redirect_uri does not allow.

A new client ID scheme based on .well-known that includes the jwks/jwks_uri client metadata offers a more straightforward option for implementing the verification of the Request Object's signature.

Proposal:

• Introduce a new Client ID scheme value: well-known, e.g., client_id_scheme=well-known.
• Define it as follows:
  • client_id MUST be an HTTPS URI controlled by the client.
  • The wallet MUST fetch the client metadata from <client_id>/.well-known/client-metadata.
  • Client metadata from the client_metadata parameter take precedence over metadata found at the .well-known location except for the signing keys of the request objects.
  • Authorization requests can be signed or unsigned. If signed, then the verification keys MUST be provided in the .well-known client metadata.

[cobward]

+1 to this.

I would also request that the restriction for the client_id to match the redirect_uri (or response_uri in the case of the direct_post response modes) is included here.

[awoie]

Perhaps it makes more sense to always sign the requests, then the verifier can choose the redirect_uri freely.

[jogu]

Perhaps it makes more sense to always sign the requests, then the verifier can choose the redirect_uri freely.

I'm not sure if that's a step too far in the case of an untrusted verifier. e.g. x509_san_dns says:

If the Wallet can establish trust in the Client Identifier authenticated through the certificate, e.g. because the Client Identifier is contained in a list of trusted Client Identifiers, it may allow the client to freely choose the redirect_uri value

I think a similar restriction as x509_san_dns makes sense - perhaps untrusted client may use redirect_uri where the FQDN matches the hostname the .well-known is on, trusted clients may choose freely.

[awoie]

Is this issue ready for PR @jogu @sakimura ?

[jogu]

Err. Perhaps. It'd probably be a good idea to raise it in a WG call first as there's probably folk who haven't looked at the proposal yet.

[awoie]

Perhaps, it would make more sense to define a general client metadata well-known location which could be beneficial to other client ID schemes as well. For example, a wallet might use well-known with the DNS name inside the client_id value with x509_san_dns to fetch the public verification keys in case the root CA is not trusted.

[babisRoutis]

What if verifier wants to use a response_mode related to JARM?

I have the impression that verifier communicates ephemeral keys via a jwks or jwks_uri inside the metadata included in the authorization request. On the other hand, well-known metadata may have a also different jwks.

Should the wallet try combine these two attributes?

[awoie]

What if verifier wants to use a response_mode related to JARM?

I have the impression that verifier communicates ephemeral keys via a jwks or jwks_uri inside the metadata included in the authorization request. On the other hand, well-known metadata may have a also different jwks.

Should the wallet try combine these two attributes?

I agree it is awkward but it is there for historical reasons. IMO, it will have to be combined somehow and if there are no clear rules yet how this should be done and what has precedence, we have to add some language.

[jogu]

JARM (signed only) is fine, only encryption causes an issue - https://github.com/openid/OpenID4VP/issues/117 already covers the issue with encryption keys I think.

[jogu]

This draft (which is on the agenda for IETF in ~2 weeks) overlaps with this suggestion:

https://datatracker.ietf.org/doc/draft-parecki-oauth-client-id-metadata-document/