OpenID4VCI: relation between the metadata's credential_issuer and the issuer of an issued verifiable credential

[Pedro Felix]

According to OpenID4VCI draft 10, credential_issuer needs to be an URL and there is a discovery process dependent on that fact. However, the issuer on a concrete verifiable credential (VC) may not be an URL. 
For instance, the W3C VC data model allows the `issuer` field to be any URI, namely a DID based URI. Due to this, the credential_issuermetadata field may not match the issuer field on a W3C VC issued by that issuer, which seems strange. Seems similar to having an ID token with an iss that doesn't match the metadata issuer.
Note that some VC profiles may mandate the VC issuer to be a DID with a specific method (e.g. EBSI), so the issuer may not have the freedom to use a URL instead.
This also relates to the aud to use on a JWT proof token, sent on a credential request, which I presume should match the metadata credential_issuer but may not match the issued VC issuer.

Is it OK to have a mismatch between the metadata `credential_issuer` and the issued VC issuer field?

If not, the email thread at https://lists.openid.net/pipermail/openid-specs-ab/2023-January/009618.html identified some options…

Option A: Add extra information to the W3C VC issuer field

The W3C VC issuer field can be an URI or an object. The later case allows for adding more information to the issuer
Example

"issuer": {
    "id": "did:example:76e12ec712ebc6f1c221ebfeb1f", // not an URL
    "name": "Example University",
    "url": "https://credential-issuer.example.com"   // matches the VCI metadata.credential_issuer value
}

In this option, the OpenID4VCI spec would define the issuer property that a wallet should check to ensure it matches the issuer OpenID4VCI metadata.

Note: Even if the W3C VC data model allows the issuer to be an URI or an object, isn’t there the risk of a specific profile requesting it to be an URI (e.g. https://ec.europa.eu/digital-building-blocks/wikis/display/EBSIDOC/Verifiable+Attestation)

Option B: Add extra information to the OpenID4VCI metadata.

Add an alternate_issuer_ids (or similar) property to the OpenID4VCI metadata.

Example

// metadata located at https://credential-issuer.example.com/.well-known/openid-credential-issuer
{
    "credential_issuer": "https://credential-issuer.example.com",
    "alternate_issuer_ids": ["did:example:76e12ec712ebc6f1c221ebfeb1f"], //
    ...
}
// Issued W3C VC
{
   "issuer": "did:example:76e12ec712ebc6f1c221ebfeb1f"
   ...
}

This would allow a wallet to validate the issued VC as being issued by the resolved issuer, i.e., the issuer for which the metadata was obtained.

Probably "alternate_issuer_ids" needs some proof of possession, so that an issuer cannot claim to have alternate IDs that belong to other issues (see Option C below and “Well known DID Configuration” to see how that can be done).

Option C: Use the “Well known DID Configuration” spec

The “Well known DID Configuration” allows the connection between URLs and DID by using a .well-known path. This would allow a wallet to determine the DIDs an entity owns, given its URL

Example

// metadata located at https://credential-issuer.example.com/.well-known/openid-credential-issuer
{
    "credential_issuer": "https://credential-issuer.example.com",
    ...
}
// resource at https://credential-issuer.example.com/.well-known/did-configuration
{
    "entries": [
        {
            "did": "did:example:76e12ec712ebc6f1c221ebfeb1f",
            "jwt": "..."
        }  
    ]
}

// Issued W3C VC
{
   "issuer": "did:example:76e12ec712ebc6f1c221ebfeb1f"
   ...
}

The /.well-known/did-configuration allows a wallet to obtain alternate IDs for an issuer, given its OpenID4VCI issuer URL.

Depending on the selected option, the OpenID4VCI spec may need to include just some implementation recommendations or add new metadata properties. We may also conclude that the wallet does not need to match the issued VC with the resolved issuer metadata properties, so no additions are need to the VCI spec.
I presume the verifier is independent of the issuance protocol and never needs to access the OpenID4VCI metadata.

‌

[Kristina Yasuda]

SIOP call, add implementation considerations section that

• Issuer identifier does not have to match iss in an issued VC
• if it does not match, wallet may check the binding using option A or C in this issue.

‌

[Kristina Yasuda]

PR #418

questions when doing a PR to discuss:

• do we need to add a Credential Issuer metadata that indicates that the credential issuer included a binding to an identifier in the issued credential?

  • don’t think it’s needed - wallet can check for binding and apply it policy if it can/cannot find such binding.

• do we need to add a Client metadata so that Wallet can indicate that it wants the issuer to provide such binding

  • don’t think so, since the ultimate decision to provide this binding is up to the issuer and verifier would care more than the wallet

‌

[Kristina Yasuda]

I also realized that in ISO mDL, issuer identifier in the issued credential would be a binary value in a `Subject` component of an mDL document signer certificate but don’t think we need to provide guidance how to bidn it to a credential issuer identifier?

[Kristina Yasuda]

PR merged.

just few questions that came to my mind when doing a PR to discuss: - do we need to add a Credential Issuer metadata that indicates that the credential issuer included a binding to an identifier in the issued credential? (don’t think it’s needed - wallet can check for binding and apply it policy if it can/cannot find such binding.) - do we need to add a Client metadata so that Wallet can indicate that it wants the issuer to provide such binding. (don’t think so, since the ultimate decision to provide this binding is up to the issuer and verifier would care more than the wallet)