[has-PR] Add credential type to OP Metadata

[David W Chadwick]

Currently each credential in the credentials_supported set does not specify the type of credential that it applies to. This has a number of disadvantages:

• wallets do not have a globally unambiguous identifier for the credential (which the type is)
• to counteract the above, the credential key is recommended to be collision resistant. Adding the type to the definition will mean that the key only needs to be locally unique, as it simply becomes the name of the JSON object in the metadata definition.
• the way that the metadata for ISO mdl credentials and W3C verifiable credentials is specified is not uniform. (e.g. there is a namespace parameter that is only applicable to mDL metadata, which can be removed once the type is added)
• wallets that want to display the type of credential to the user do not have a way of being informed how to display this

By introducting the type parameter as the first parameter of each credential in the credentias_supported object, and making this the unique URL for each specific type of credential, we can clearly state at the start of the metadata which type of credential this metadata applies to. So for example, for mdl the type could be http://standards.iso.org/18013-5.2019, for a W3C Verifiable Credential (of any type) it would be https://www.w3.org/2018/credentials#VerifiableCredential.

Because a credential can be of multiple types then the type parameter will be a set of values.

The display qualifier will indicate to the wallet how this (type of) credential should be displayed to the user.

(PR #240)

[Oliver Terbu]

IMO, this is covered by the types parameter under the formats metadata. I’d agree that those types values SHOULD be collision-free Strings or URIs. In that case, we would need to just update the language of the types values slightly.

types: REQUIRED. Array of strings representing a format specific type of a Credential. This value corresponds to type in W3C [VC_DATA] and a doctype in ISO/IEC 18013-5 (mobile Driving License).

should become …

types: REQUIRED. Array of strings representing a format specific type of a Credential. This value corresponds to type in W3C [VC_DATA] and a doctype in ISO/IEC 18013-5 (mobile Driving License). Each value SHOULD be a collision-free String or URI.

Any thoughts?

[David W Chadwick]

The types parameter is currently in the wrong place. The type of a credential is not dependent upon its format. Both jwt-vc and ldp-vc are different proof formats of the same type of VC. Consequently the types parameter needs removing from the formats object and bringing near to the top of each supported credential. This is what the first version of the associated PR attempted to do.

There are two related issues:

1. How is the type of VC being issued to be referred to in the OIDC4VCI protocol? Is it by a globally unique string/URI or a local defined string (that can have collisions)
2. How is the type referred to above to be mapped into the actual internationally recognised type(s) that will be contained within the issued VC.

My proposal is to use 2. in the protocol for 1. (i.e. null mapping). This works for ISO mDL and W3C VCs that only have 2 types (the mandatory VerifiableCredentials type that must be present for all VCs, and the second VC specific type that also must be present). Where this fails is if a VC has 3 or more types in its W3C VC types property. Do these VCs occur in the wild? Do we want to cater for them? If so, which one should be used in the OIDC4VCI protocol to refer to it?

‌

[Kristina Yasuda]

discussed in Aug-25-2022 SIOP call.

Need to clarify - how format specific type is expressed (ie @context with ldp_vc) - what is the wallet using to look up the issuer metadata - abstract identifier? type?

and decide if we want to keep an abstract identifier..

[Kristina Yasuda]

Several comments were made that we need globally unique identifier for type - we have discussed previously that there is no global registry for that purpose and without it, it is super hard to ensure global uniqueness.

‌

[David W Chadwick]

“there is no global registry for that purpose and without it, it is super hard to ensure global uniqueness.” There is a global registry - the DNS. Its not difficult to create globally unique IDs based on your DNS name(s). Admins do this all the time. But even without the DNS, DIDs are based on global uniqueness without a registry. So if it is super hard to ensure global uniqueness, then DIDs will have a big big problem. So if we say that the type must be a URI (which implies global uniqueness), maybe with some notes in the Implementation Guidelines, then I think this should be sufficient.

[Kristina Yasuda]

PR merged