IACA Metadata for Credential Issuers

[selfissued]

This issue proposes an extension to OpenID4VCI Credential Issuer Metadata to publish Issuing Authority Certificate Authority (IACA) certificates. These certificates are defined in ISO 18013-5 (mDL).

A key decision is whether to provide the certificates by value in the Credential Issuer Metadata itself or whether to provide it by reference at a different URI. I propose to provide it by reference so that the timing of updates can be controlled by normal Web Cache-Control directives. (This is the same reason that jwks_uri is used in OpenID Connect OP metadata to provide keys by reference.)

I propose that IANA certificates be provided using this Credential Issuer Metadata element:

mdoc_iacas_uri: OPTIONAL. URL of the Credential Issuer’s IACA set document. This document contains the IACA certificates [ISO 18013-5] the used to validate signatures for issued mDOCs.

The referenced document has this structure:

{"iacas": [ {"certificate": "base64-encoded DER representation of IACA certificate"}, … ] }

The top-level structure is intentionally parallel to a JWK Set – which uses a keys element whose value is an array of JWKs. The array elements are structures with a required certificate element, allowing other certificate metadata to be added to the structures, such as expiration time, as needed.

[Sakurann]

why is this needed? In ISO mDL, IACA certs are used to sign the credentials and are discovered by the verifier from the x5c parameter in the credential itself during presentation. this should not be confused with the credential issuer metadata discovered by the wallet during issuance.

[tplooker]

A wallet obtaining a mobile credential in OpenID4VCI is unable to verify the mobile credential without the IACA which is not present in an issued mDoc.

Verifiers like wallets cannot "discover" the IACA using the x5c parameter, the document signer certificate embedded in the COSE header references the IACA in the issuer information, but if the verifier or wallet doesn't already have the IACA (obtained out of band) then it cannot verify the chain and thus verify the mobile credential back to its issuer. This proposal tackles precisely this issue.

Finally the IACA is the issuers root certificate and thus makes perfect sense to surface through the issuers metadata because it represents critical metadata when issuing an mDoc.

[tlodderstedt]

Is that an mdoc specific issue? Is it relevant for readers, too?

If so, then I suggest to solve it in an mdoc specific way. This is because the reader does not know how the mdoc was issued, so why should it reach out to an OID4VCI based credential issuer?

I suggested the jwt-issuer for exactly the same reason having observed that the verifier of a VC does not know how it was issued. well-known locations support that very well. Just append another credential forma specific destination and obtain whatever is needed.

Question: what data does the reader have about the issuer?

[peppelinux]

If I would have to implement this I would say that the issuer must publish the x5c in the form of a json array containing its certificate and the one issued by the trust anchor (ca) and any of its intermediate, forming the X.509 certificate chain.

x5c would be published in the credential issuer metadata, within jwk.keys and also in each signed JWT/Cose Sign1 Doc, in the protected/unprotected headers (ISO 18013-5 wants it unprotected).

the "trust evaluator" would only check that the top level of the chain is the trust chain certificate of that known organization (subjectDN, CN, OU ...) and that this top level certificate verify with success the entire chain

[tlodderstedt]

We (@danielfett and myself) just had a discussion with Tobias. The goal is to establish trust in a mdoc issuer through a URL and then map that URL to the root certificate (which is really the self signed cert of that issuer not a 3rd party cert). We suggested to put it into a new well-know location under the same URL (identifier).

[selfissued]

I talked about this with Tobias some more. Adding another .well-known endpoint would introduce an extra round trip to retrieve this metadata versus communicating it in the normal metadata response. Plus, having the extra .well-known location would mean that the metadata doesn't tell implementations whether this information is available or not. You'd have to do another GET to find out (which might fail), rather than just looking at the metadata field.

[jogu]

As asked on today's working group call, I assume that ecosystems have a list of issuers that are trusted by wallets and verifiers. Should the root certificate be part of that list of trusted issuers rather than hosted on the issuer website?

[tlodderstedt]

@selfissued that argument would lead to a single multi purpose well-known, essentially contradicting the idea of well-known locations. It's like did:web. well-known allows for a modular way to manage metadata. I would like to use the concept as intended. Moreover, the data is relevant for verifiers. Would you assume the verifier knows the mdoc was issued through oid4vci and that it should lookup the openid-credential-issuer metadata.

[David-Chadwick]

We need a generic mechanism for the issuer to publish the trust framework(s) that it is a member of so that verifiers (and wallets) can determine the trustworthiness of any issuer on the open Internet. The mechanism being proposed here is just one instance of such a mechanism and so the mechanisms should be generalised first before a PR is written.

[awoie]

I think this is needed for mdoc issuers. ISO/IEC 18013-5:2021 requires it and ISO/IEC 23220-4 will also require it. The X.509 profiles and the root cert itself are very specific to the doctype. So it makes to put it in the Credential Issuer Metadata for mdoc_mso. Based on @selfissued I created this proposal https://github.com/openid/OpenID4VCI/pull/161.

[alenhorvat]

Anyone who receives a credential must be able to verify the signature and the chain of certificates. It is a role of a signature profile to define the rules of resolving the public keys and (root) certificates.

If the issuer URL is not in the VC, the Verifier will not know where/how to resolve the issuer metadata.

The only benefit(?) might be for the wallet to check that the VC is signed with a public key published by the issuer.

Note: for performance and privacy purposes, it is advisable to attach the signing keys to the signature (e.g., via jwk, kid+public key in the unsigned header, x5c/x5u+x5t, ...).

Note that this does not solve the problem of distributing the root keys/certificates. Those need to be a) delivered out of band (e.g., TLS root directory) b) fetched via a trusted resource (e.g., EUTL, OIDC/OAuth, ...) where trusted resources (URLs) are delivered out of band

Namely, root keys/certificates are self-published/self-signed hence additional external security mechanism must be put in place.

[Sakurann]

putting 1.1 since this is an extension that can be added in a backward compatible manner to final 1.0