Support for RP authentication with X.509 certificates that do not contain a dns name

[martijnharing]

The specification currently does not support RP authentication with X.509 certificates that do not have a DNS name.

There can be multiple reasons why an RP may not have a DNS name in their certificates, examples include re-using an existing certificate that does not have a DNS name, an RP certificate issuer that does not want or cannot verify binding to a DNS name or using the same certificate for in-person as well as remote.

Two possible solutions are to add another client identifier scheme, or to not use a client_id when such a certificate is used.

[bc-pi]

What about the x509_san_uri Client Identifier Scheme?

[martijnharing]

x509_san_uri has the same issues as x509_san_dns since the same reasons why an RP certificate may not have a DNS name can also apply to a URI.

[Sakurann]

so, this requirement is important since it proves that the identifier of the client belongs to the entity producing the signature and is being authenticated.

My suggestion would be to define a behavior what to do when a client_id does not match a DNS name in the certificate - basically something like, "the wallet MAY accept a request with client_id_scheme x509_san_dns (or x509_san_uri FWIW) where client_id does not match DNS name in the cert, at its own risk, and only if the wallet has obtained out of band a list of a trusted combination of client_ids and root certs". Can do a PR if this is acceptable

[martijnharing]

I don't think that would address it. In the case of using an X.509 certificate to identify the Reader, as a wallet you care whether the RP is authenticated. The X.509 certificate tells you whether it's trusted. What trusted means in this context is likely ecosystem specific. The client_id doesn't necessarily come into play, since (depending on the ecosystem) the X.509 certificate can already tell you everything you need to know about the RP. For example as a wallet I could trust all RPs that have a certificate issued by root X, and there is an RP that signs the request with a certificate issued by root X with a subject that says "company Y". As a wallet I could show this to the user (what exactly to show to the user would be ecosystem/wallet specific), who can choose to proceed or not based on that information. The RP signs the jwks with the key in this certificate and I would encrypt the response to this key. For this particular flow it's not required to actually use the client_id or check it against something. So I don't think there is always a security benefit (at least not in this particular example) to requiring the wallet to have a list of client_ids vs RP certificates.

[Sakurann]

The client_id doesn't necessarily come into play, since (depending on the ecosystem) the X.509 certificate can already tell you everything you need to know about the RP.

client_id does come into play because it is a security mechanism: aud in KB JWT and W3C VPs must equal client_id and session transcript in mdocs includes client_id

[danielfett]

Yes, indeed. Just the encryption of the response is not enough. The aud value is important.

A solution might be something like x509_thumbprint.

[martijnharing]

The client_id doesn't necessarily come into play, since (depending on the ecosystem) the X.509 certificate can already tell you everything you need to know about the RP.

client_id does come into play because it is a security mechanism: aud in KB JWT and W3C VPs must equal client_id and session transcript in mdocs includes client_id

But in the context of the example given, I don't think the clientID mitigates against situations that aren't already mitigated by the presence of the origin in the session transcript. If that's indeed the case, then the requirement that the wallet has a list of client_ids vs root certs should not apply. While such a requirement has significant difficulties for scalability.

[c2bo]

Yes, indeed. Just the encryption of the response is not enough. The aud value is important.

A solution might be something like x509_thumbprint.

I agree, thumbprint sounds like a reasonable idea imho