How does a credential issuer trust the wallet attestation issuer's public key?

[joelposti]

Section 4.3.1. Wallet Attestation Schema defines that the wallet attestation issuer's (a.k.a. wallet provider's) public key is distributed using a mechanism defined in SD-JWT VC section 5. JWT VC Issuer Metadata. The mechanism is essentially:

1. Download a JSON document from an HTTPS URL.
2. Get a JWK key
   a. either by finding the key from the document's jwks.keys array
   b. or by downloading another JSON document from a JWKS endpoint referenced in the original document's jwks_uri field and finding the key from jwks.keys array in the second JSON document.

Presumably this key resolution is done by the credential issuer during the credential issuance process. What is lacking here is a trust model. How does the credential issuer trust the key presented in the first or the second JSON document? How does the credential issuer know that the wallet attestation is signed by a legitimate wallet provider?

An ISO/IEC 23220-3 draft defines a similar wallet attestation schema and presents a certificate chain-based trust model in one of its wallet attestation examples. In the example the wallet provider's public key is distributed along with the wallet attestation by inserting a certificate with the public key to the wallet attestation's x5c header. I suppose the idea there is that the credential issuer has a CA certificate in its trust store and can thus establish trust to the wallet provider's certificate and public key via the CA certificate.

[paulbastian]

HAIP does not define the trust mechanism in general, and so the wallet attestation trust is not an exception to this. As you have written, JWT VC Issuer Metadata is a mechanism to retrieve a public key, not a trust mechanism. But so is x5c header as well in the ISO example?

Ultimatly, you need some form of trust mechanism (ETSI Trust list, OpenID Federation or EBSI?) to determine that a key is actually privileged to mean something in the ecosystems that we are building. Right now, as these things are not defined yet(!), the trust is implicit, meaning there must be an out-of-band/pre-registered trust connection between two parties.

I think in the very near future, we will see these trust mechanisms competing for the eIDAS throne.

[joelposti]

Thank you for response!

As you wrote in your comment a trust model and a trust mechanism needs to be built on top HAIP. How easy that is depends partly on the foundations that HAIP and other underlying specfications lay out. The underlying specifications do have opinions regarding the trust mechanisms, at least indirectly. For example, let's consider the OAuth 2.0 Attestation-Based Client Authentication specification. It goes into quite a lot of detail in describing how trust in the wallet's public key is established. There are not that many ways one can build a trust mechanism on top of that specification. I think it's OK for the underlying specifications to have opinions regarding trust mechanisms. However, the specification should consider how easy or feasible it is to build a trust mechanism on top of the specification's foundations.

As you have written, JWT VC Issuer Metadata is a mechanism to retrieve a public key, not a trust mechanism. But so is x5c header as well in the ISO example?

X5c header can indeed be considered a key delivery mechanism but it also provides a framework for a trust mechanism. In other words, it's easy to imagine and design a trust mechanism on top of a wallet attestation that has an x5c header. I think it's less easy to work out a trust mechanism on top of a key delivery mechanism that is based on downloading unsigned JSON documents. That is the problem I am facing as a HAIP implementer. I want to follow the specification but I do not know how to solve the trust issue in an interoperable way with the building blocks the spec gives me.

[peppelinux]

According to the last ARF version, both OpenID Federation and X.509 based PKI can be used for the satisfaction of the functional requirements of the infrastructure of trust

therefore, having an issued Wallet Instance Attestation, we have the following elements:

• An Issuer unique identifier (eg: HTTPs URL)
• Optionally, a trust chain (eg: X.509 certificate chain or OpenID Federation Trust Chain)

the benefit of using openid federation is that its trust chain carries also the metadata, the policies and the trust marks.
See: https://italia.github.io/eudi-wallet-it-docs/versione-corrente/en/wallet-attestation.html#table-wallet-attestation-claim

[Sakurann]

yes, a trust model and a trust mechanism needs to be built on top HAIP. the HAIP intends to be silent on this exact question: "How does a credential issuer trust the wallet attestation issuer's public key?" maybe you have a PKI, or maybe you have obtained a root CA out of band, etc.

HAIP currently only allows x.509 or web-based key resolution. whether openid federation needs to be allowed is a separate issue.

Are there any specific suggestions how to make this clearer in the text? modify out of scope section? otherwise, would close as resolved.

[joelposti]

yes, a trust model and a trust mechanism needs to be built on top HAIP. the HAIP intends to be silent on this exact question: "How does a credential issuer trust the wallet attestation issuer's public key?" maybe you have a PKI, or maybe you have obtained a root CA out of band, etc.

All right. I understand. If HAIP is to remain silent on the matter of trust models and mechanisms, would it be possible to reconsider the requirements in the section about the credential issuer key resolution mechanisms? It is interesting and seemingly inconsistent that the credential issuer can make use of either the web-based or the X.509-certficate-based mechanism while at the same time the wallet attestation issuer is limited to just the web-based one.

Also, maybe I am splitting hairs here, but the following rather specific requirements regarding the credential issuer's X.509-certificate-based mechanism seem to wander into the territory of trust mechanisms. The requirements go beyond the scope of key resolution and credential signature validation. The requirements do not seem to be in line with the idea that HAIP should remain silent about trust mechanisms.

https://openid.net/specs/openid4vc-high-assurance-interoperability-profile-sd-jwt-vc-1_0-00.html#section-7.1-2.2
x.509 certificates: the SD-JWT VC contains the issuer's certificate along with a trust chain in the x5c JOSE header. In this case, the iss value MUST be an URL with a FQDN matching a dNSName Subject Alternative Name (SAN) [RFC5280] entry in the leaf certificate.

[Sakurann]

I think there is a nuance in "silent on the matter of trust models and mechanisms". Meaning that for interoperability, I believe, HAIP needs to specify the key resolution mechanisms, but how to establish trust in those keys (i.e., how to obtain a root cert for x.509 or know that https url can be trusted) is out of scope.

Currently, HAIP lists x509 and https based key resolutions, but I think we need to discuss if we want to keep them. from my observation, feels like x509 should be mandated for all as a baseline and we should probably remove https based key resolution for now and re-add one more mechanism once it is clearer what implementers prefer.

can you please explain how the section you quoted "goes beyond the scope of key resolution"?

[joelposti]

can you please explain how the section you quoted "goes beyond the scope of key resolution"?

Of course. I think it goes beyond the scope of key resolution by demanding that the X.509 certificate needs to have a SAN entry matching with the iss value. Just for key resolution purposes that check is unnecessary. For key resolution it is enough to take the leaf certificate in the x5c header and try validation of the signature with the certificate's public key. Strictly for key resolution it does not really matter if the SAN entry matches or what the other information the certificate contains as long as it has a public key.

I see the SAN entry check to be about establishing trust in the iss value and the certificate. Similarly, the notion that the x5c header contains the issuer's certificate along with a trust chain is about establishing trust in the certificate. Establishing trust is, in my opinion, in the realm of trust models and mechanisms.

[Sakurann]

also please see #156

[jogu]

https://openid.github.io/oid4vc-haip/openid4vc-high-assurance-interoperability-profile-wg-draft.html#section-4.4.1 says:

The public key certificate, and optionally a trust certificate chain, used to validate the signature on the Wallet Attestation MUST be included in the x5c JOSE header of the Client Attestation JWT.

and https://openid.github.io/oid4vc-haip/openid4vc-high-assurance-interoperability-profile-wg-draft.html#section-3.4 says:

Although X.509 PKI is extensively utilized in this profile, the methods for establishing trust or obtaining root certificates are out of the scope of this specification.

I think the primary question of "How does a credential issuer trust the wallet attestation issuer's public key?" is hence answer - via the x5c header, but how it gets/trusts the root cert is out of scope.

I'm hence going to mark this as 'pending close' - @joelposti if you disagree please shout - and it seems like you may have raised some issues unrelated to wallet attestations. One issue you mentioned, around:

In this case, the iss value MUST be an URL with a FQDN matching a dNSName Subject Alternative Name (SAN) [RFC5280] entry in the leaf certificate.

is solved in https://github.com/openid/oid4vc-haip/pull/178/files by removed that sentence. If there's any other issues unresolved could you open a new GitHub issue for each topic please?