[Openid-specs-ab] Issue #1778: OpenID4VCI: relation between the metadata's credential_issuer and the issuer of an issued verifiable credential (openid/connect)

[Pedro Felix]

New issue 1778: OpenID4VCI: relation between the metadata's credential_issuer and the issuer of an issued verifiable credential
https://bitbucket.org/openid/connect/issues/1778/openid4vci-relation-between-the-metadatas

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_issuer`metadata 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](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](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”](https://identity.foundation/specs/did-configuration/)  to see how that can be done\).

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

The [“Well known DID Configuration”](https://identity.foundation/specs/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.

‌