`client_id_scheme` security considerations

[danielfett]

When client_id_scheme is used, there can be multiple client_ids in the same ecosystem that belong to different clients. One of those clients could be malicious, compromised or the client_id scheme could allow for spoofing/impersonating client ids. One such insecure/spoofable client must not endanger the security of other clients in the same ecosystem.

In the protocol, since the client_id_scheme parameter namespaces the client_id, it should appear everywhere where client_id appears, including in aud values and in the sub value of the Verifier Attestation JWT.

In the credentials, the client_id_scheme should be included besides the client_id as the audience; e.g., in an SD-JWT KB-JWT, there should be a separate claim besides aud.

In Section 12.1, the following sentences need to be adapted as well:

The Wallet MUST link every Verifiable Presentation returned to the Verifier in the VP Token to the client_id and the nonce values of the respective Authentication Request.

The Verifier MUST validate every individual Verifiable Presentation in an Authorization Response and ensure that it is linked to the values of the client_id and the nonce parameter it had used for the respective Authorization Request.

The client_id is used to detect the presentation of Verifiable Credentials to a party other than the one intended.

In the security considerations there should be considerations about confusing two client IDs with different client ID schemes.

Everywhere where a party checks a client id (especially the AS and the client), it must check the tuple (client_id, client_id_scheme) instead. This also applies if client_id_scheme is not used by one of the parties (in which case client_id_scheme must be replaced by, e.g., null).

Edit 2023-05-17: Fixed a mistake in the third paragraph.

[Sakurann]

sorry, I am probably missing something, if client_id belongs to a compromised or malicious client that is part of the ecosystem using the same client_id_scheme, how does including client_id_scheme help detect that.

[jogu]

sorry, I am probably missing something, if client_id belongs to a compromised or malicious client that is part of the ecosystem using the same client_id_scheme, how does including client_id_scheme help detect that.

It's the equivalent of suggesting instead of "aud": "https://www.example.com" in a JWT for a client we instead have "aud": "redirect_uri:https://www.example.com" if the client_id uses the redirect_uri client_id_scheme (but instead of having a structured aud value Daniel is suggesting having a separate claim that recipients of the JWT will need to check).

I'm not sure if there is actually a practical issue unless a client_id_scheme that allows the attacker to select a completely arbitrary client_id is supported (which I don't think any of the currently defined client_id_schemes do, I think they pretty much all require a url or hostname or an AS-assigned client_id).

It does feel like there might be an issue when client_id_schemes result in what is nominally the same client having the same client_id but with different security levels. So for exactly where a client intends to have client_id_scheme=entity_id&client_id=https://www.example.com but the attacker instead uses client_id_scheme=redirect_uri&client_id=https://www.example.com and is then able to obtain a VC with an aud of https://www.example.com that it can attempt to inject into a flow for the legitimate client.

[awoie]

In the credentials, the client_id should be included as the audience; e.g., in an SD-JWT KB-JWT, there should be a separate claim besides aud.

Each credential format has to define how to use client_id and client_id_scheme in the response.

W3C VCDM with Data Integrity:

• domain parameter has to include the fully qualified client_id (FQCID), i.e., <client_id_scheme>:<client_id>

SD-JWT VC:

• KB-JWT could have an additional claim, client_id_scheme, or use the FQCID as well for the aud value.

W3C VCDM with JWT:

• aud parameter that contains the FQCID, or use the same mechanism as SD-JWT VC.

ISO mdoc:

• OID4VPHandover structure has to include the FQCID if other client ID schemes than x509_san_dns are used (x509_san_dns is the default since ISO 18013-7 only allows this). ISO 23220-4 could potentially allow other client ID schemes.

[awoie]

This also applies if client_id_scheme is not used by one of the parties (in which case client_id_scheme must be replaced by, e.g., null).

IMO, if client_id_scheme is not present, it is pre-registered (default value if omitted).

[danielfett]

I'm not sure if there is actually a practical issue unless a client_id_scheme that allows the attacker to select a completely arbitrary client_id is supported (which I don't think any of the currently defined client_id_schemes do, I think they pretty much all require a url or hostname or an AS-assigned client_id).

The problem is that this security is accidental and neither guaranteed in all deployments nor for any future extensions that define new client id schemes.

[jogu]

@danielfett yes, exactly. For clarity whilst I can't identify a practical attack with the current client id schemes I do agree there's a real issue here we need to look at fixing.

[Sakurann]

in-person WG:

• no clear direction...
• @tplooker volunteered to try provide a text/mechanism that does not use client_id_scheme parameter but achieves what the spec enables now (flexibility of verifier authentication mechanisms)
• if removing client id schemes is not an option, namespacing client id sounded like the best option

[peppelinux]

I've come to believe that the security concerns discussed in this thread primarily pertain to the redirect_uri client_id_scheme. If other client id schemes do not share this vulnerability, my recommendation - even if it might sound very unpopular - is to discontinue support for the redirect_uri scheme and remove it from the specifications. Personally, I have always perceived the redirect_uri scheme as a security risk and have been critical of its implementation.

Regarding the potential security issues with new client id schemes mentioned by @danielfett and @jogu, I believe such concerns should be addressed by those future extensions that have not yet identified their security weaknesses. Something that seems pretty out of scope for openid4vci.

I agree with @awoie with the approach that if the parameter is absent, the Wallet MUST follow the behavior outlined in RFC6749.

In the context of OpenID Federation, the client id by itself is sufficient to initiate trust discovery, unless it is an HTTPS URL. While the client id scheme serves as a useful indicator for determining the pattern of client id evaluation.

It's important to note that even with namespaced client ids, an attacker could potentially replace the entire client_id value, redirecting to any values.

Therefore, I suggest that our focus should be more on addressing the root of the problem—the redirect_uri—rather than the representation of the client identifier itself.

[jogu]

I've come to believe that the security concerns discussed in this thread primarily pertain to the redirect_uri client_id_scheme. If other client id schemes do not share this vulnerability

There is a similar ambiguity between entity_id and x509_san_uri

It's important to note that even with namespaced client ids, an attacker could potentially replace the entire client_id value, redirecting to any values.

That would result in client authentication failing as far as I can see.

Therefore, I suggest that our focus should be more on addressing the root of the problem—the redirect_uri—rather than the representation of the client identifier itself.

The root cause of the problem is the introduction of client_id_scheme in the VCI spec, hence I believe the issue needs to be addressed in the VCI spec.

[peppelinux]

@jogu formally you are completely right, as usual. At the same time, from my perspective, a trust discovery using federation or x509 can be achieved by using the client_id alone.

I don't have any expectations about not taking this in the scope of openid4vci, therefore I hope that my comment won't block the conversation about the solution we may have to improve the current specs.