Client_id requirements and clarifications

[martijnharing]

With the recent changes to the client_id and the multi-rp PR merged, there are some clarifications necessary for the client_id definition and processing.

Some of this could also be handled by #465 but I'm not sure whether it's clearer to split these comments or not.

Some of the ambiguity comes from the definition. The client_id is currently defined through a reference to RFC 6749. However RFC 6749 defines the client_id as being issued by the authorization server as part of a registration process. client_ids aren't always part of a registration process (e.g. they can be derived from other information like a certificate) and they aren't always issued by the authorization server.
Can we change the reference, or add language that these requirements from RFC 6749 do not apply?

For some of the requirements we have to state more explicitly who has to verify those:

• For x509_san_dns: "The Wallet MUST validate the signature and the trust chain of the X.509 certificate." Other schemes have similar requirements.
  Can we add a general statement along the lines of "Parsing and verification requirements for client identifiers are only applicable to the Wallet when the Wallet uses the information from that client identifier."

• For x509_hash: "When the Client Identifier Scheme is x509_hash, the Client Identifier MUST be a hash and match the hash of the leaf certificate passed with the request." Other schemes have similar requirements.
  Is it required, recommended or optional for the Wallet to verify this? For example when using the x509_hash and the DC api, the client_id is not included in the response, and all the information used to verify the signature is in the certificate itself. Therefore the hash is effectively duplicating information of the certificate. Since both are signed over, I don't think there is a security benefit from actually matching the x509_hash against the certificate itself.
  To make sure that there is agreement on verification requirements, we have to state explicitly whether and when these checks must be done or not by the Wallet.

[mickrau]

I have also a client_id clarification question, that is somehow connected:
When implementing on the wallet side DC API with x509_san_dns, I also was wondering whether I have to check that the origin matches a SAN DNS or not. In the spec, this check is only mentioned when using redirect_uri, so I did not implement this check for DC API.

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. If not, the FQDN of the redirect_uri value MUST match the Client Identifier without the prefix x509_san_dns

After second thought, i think having no fixed binding (compared to flexible expected_origins) between client_id and origin could cause some issues.

1. When an attacker compromises the private key of any client_id_bound certificate (e.g. client-id: x509_san_dns:bank.org). He could create valid-looking signed Authorization Requests for any origin (e.g. bänk.org or whatever).
2. It's not clear which client information should be displayed to the user if the origin does not match client-id. The technical origin is more relevant for security (that's the place the data is given to), but human-readable data is more likely to be associated with the client-id (certificate or trusted registry).

For example
origin: bänk.org
client-id: x509_san_dns:bank.org
client-id information: Bank AG, 10010 Berlin, Germany (trusted ✅)

To limit the potential damage after key compromise or by a bad actor, i think

• the origin should match a SAN in client certificate or
• the origin should be bound to specific client-id in a list of trusted client identifiers

[Sakurann]

However RFC 6749 defines the client_id as being issued by the authorization server as part of a registration process.

Yes, we raised this with OAuth WG and this led to the changes on client identifier in this section in OAuth 2.1 draft. Specifically,

While the Authorization Server typically issues the client identifier itself, it may also serve clients whose client identifier was created by a party other than the Authorization Server.

and we also already say in client identifier prefix section in openid4vp that

The Client Identifier Prefix enables deployments of this specification to use different mechanisms to obtain and validate metadata of the Verifier beyond the scope of [RFC6749].

having said htat, @aaronpk does it make sense to point to OAuth 2.1, instead of OAuth 2.0 throughout OpenID4VP?

[Sakurann]

Can we add a general statement along the lines of "Parsing and verification requirements for client identifiers are only applicable to the Wallet when the Wallet uses the information from that client identifier."

I think we already intend to say that in the introduction of client identifier prefix section: A certain Client Identifier Prefix may require the Verifier to sign the Authorization Request as means of authentication and/or pass additional parameters and require the Wallet to process them

we could improve it to something like "A certain Client Identifier Prefix sets the requirements whether the Verifier needs to sign the Authorization Request as means of authentication and/or pass additional parameters and require the Wallet to process them"

[Sakurann]

For x509_hash: "When the Client Identifier Scheme is x509_hash, the Client Identifier MUST be a hash and match the hash of the leaf certificate passed with the request." Other schemes have similar requirements.

I think we intend to clarify that in the introduction of client identifier prefix section:
This specification defines the concept of a Client Identifier Prefix that indicates how the Wallet is supposed to interpret the Client Identifier and associated data in the process of Client identification, authentication, and authorization.

here too, we can clarify "This specification defines the concept of a Client Identifier Prefix that dictates how the Wallet needs to interpret the Client Identifier and associated data in the process of Client identification, authentication, and authorization."

Is it required, recommended or optional for the Wallet to verify this?

so in short, all processing rules for client identifier prefixes are mandatory for the wallet.

[Sakurann]

client identifier not being assigned by AS (#484 (comment)) is i believe being clarified in #465