Add a Discovery Use Case for establishing trust between the issuer and the verifier

[samuelmr]

The current Wallet Architectures draft lists the following Trust Discovery Use Cases:

8. Federation Trust Discovery Use Cases

8.1. Establishing Trust with a Credential Verifier Instance

8.2. Wallet Checking the Non-Revocation of its Wallet Provider

8.3. Wallet Discovering Credentials Issuers

8.4. Credential Issuers Establishing Trust in the Wallet Provider

8.5. Credential Issuers Establishing Trust in the Wallet

8.6. Wallet Establishing Trust in the Credential Verifier

One crucial Trust Discovery Use Case is missing: how does the verifier of a digital credential establish trust with the issuer? The verifier should be able to verify that...

• the key used to sign the digital credential is (or was, at the time of issuance) in the possession of the issuer
• the issuer is the entity it claims to be
• the issuer is entitled to issue the credential

OpenID Federation provides a way to verify those points, but the method for discovering the issuer's entity configuration is currently unspecified.

[samuelmr]

One way would be to require the issuer's ID to be a plain https:// URI and instruct verifiers to fetch the issuer's OpenID Federation Entity Configuration from the corresponding .well-known address.

(The issuer's ID can be the iss field in a JWT or the value of the issuer or issuer.id in a W3C DM credential.)

This approach prohibits using DIDs as issuer identifiers.

[samuelmr]

Another way would be to standardize the use of termsOfUse in a similar way that was proposed in OID4VP until the draft 21: https://openid.net/specs/openid-4-verifiable-presentations-1_0-21.html#name-support-for-federations-tru

{
  "termsOfUse": [
    {
      "type": "<uri that identifies this type of terms of use>",
      "federations": [
        "<list of federations/trust schemes the Credential Issuer asserts it is a member of>"
      ]
    }
  ]
}

The Wallet Architectures spec would be the right place to define this.

The value of an item in the federations array could be

• a https:// URI pointing to the issuer's Entity Configuration
• the issuer's Entity Configuration JWT
• the whole trust chain as a JWT

[samuelmr]

Yet another way would be to use a DID method that defines how the verifier can find the issuer's OpenID Federation Entity Configuration.

A proposal for such a DID method can be found here: https://findyfi.github.io/did-oidf/

[peppelinux]

this reminds me this old proposal: oauth-wg/oauth-sd-jwt-vc#41 (comment)

@samuelmr do you believe to propose also a static trust chain did resolution as well?

[samuelmr]

@samuelmr do you believe to propose also a static trust chain did resolution as well?

I'm not planning to do that.

[TimoGlastra]

I think we would need to define how to resolve the federation for each credential format, taking into account the specific security considerations of each format.

If we look at OpenID4VCI and OpenID4VP I think the following formats make sense to at least cover:

• ISO mDOC/mDL (SAN_URI could be used, see openid haip x509_san_uri can be resolved as any other federation entity id #45)
• SD-JWT VC
• W3C Verifiable Credentials (v1/v2)

@peppelinux you mentioned for mDOCs that it is out of scope of this draft to define how to link it to mDOCs. Is there any specific reason for excluding this?

ISO mDOC/mDL

Since mDOCs need to issued with an X509 certificate, it will probably have to be something in the X509 certificate that links to the federation.

Since the root certificate is not included within the mDOC, the Federation should allow resolving the root certificate in some way, as well as be able to establish trust in the signing certificate used in the mDOC

SD-JWT VC

A simple solution would be to use the federation identifier as the iss field. with a kid pointing to a key in the federation metadata. However we've had discussions in the DIIP WG that you may want an iss value that is not your federation url (since the federation url might be a technical component url, and you may want to be host multiple entity configurations, as different federations can have clashing policies).

A new discovery mechanism might work (like there's x5c), but I've read in #51 (comment) that new discovery mechanism should be avoided (not sure why though). I think DIDs using iss and kid is not a great design, and implementations would be a lot simpler if there were a custom did header. I think similar for federations I'd be nice to include federation metadata directly within the credential (payload or header). Whether there should be any link between the iss and the federation entity i'm not sure

W3C VC

As mentioned above my @samuelmr, we could rely on the termsOfUse for the trust resolving? However we would have to think about all the different signing methods available for W3C VC. Mainly JWT-based signing and DataIntegrity based signing.

For DataIntegrity signing, we will have to define the format of the verificationMethod identifier. This could be the federation URL, but then the termsOfUse might not be needed anymore for establishing trust in the issuer? It could still be used for intended usage of the credential. Similar for JWT-based signing we could rely on the same method as for SD-JWT VC.