[needs PR] Defining a credential type in OpenID4VCI

[Tobias Looker]

As raised in PR 128, an appropriate definition for credential type needs to be added to the draft that can be carried throughout. In the course of defining this term we should consider some of the following:

• What conceptually should be communicated by a credential type (e.g just a group of claims or more, like the valid formats of the credential and what holder binding methods can be used)
• What should the bounds on this type value be with in the context of our specification, just a string or something stricter like a URI?
• How will types be managed, via a registry or less formally?

‌

[David W Chadwick]

I think whatever solution we choose it should support open working rather than closed working. By this, I mean that rather than using a registry to publish types (which is closed), the issuer should be able to publish its type in its meta-data. This allows any issuer to issue any type of credential without restriction or requirements to add to a registry, and wallets can determine this by reading the issuer’s meta-data.

If we decide to use the issuer’s meta-data to publish the types of credentials it can issue, then this gives the issuer the flexibility to either specify types as globally unique URIs, or, in the case of VCs, to use @context to specify the URIs along with short form alias strings. In the latter case the wallet can refer to the short form alias string(s) when requesting the type(s) that it wants.

[Kristina Yasuda]

few thoughts:

• for type values, I think we should allow both - a string and a URI

• for what should be communicated: did you mean in the request or in the metadata?

  • In the metadata, all details should be communicated - I think credential_manifest is a good start ,but we need to agree on concrete parameters.
  • In the request, I expect there to be two variants similar to how we agreed on presentation_definition by value and by reference in OIDC4VP. meaning, if by reference, passing only a URI is sufficient; if by value, probably need more discussion, but I would expect at least credential format to be communicated..?

• for how to manage, I think we should allow multiple options - using OP metadata to discover + allow using out-of-band mechanisms, which can include scanning a QR code with a URI or registries, which would be out of scope of the spec itself.

‌

[Kristina Yasuda]

2022-Mar-17 SIOP call, agreed on the importance of the issue. Need a concrete proposal in a PR to move forward.

[David W Chadwick]

Could we agree on the design first, in this issue, and then write the PR afterwards? I think it would be quicker. Here are issues to be agreed upon

i) the syntax for a type value (define it as a string which could be a URI or any string, or be more specific)

ii) the contents of the issuer’s meta-data. Should it be credential manifest or something simpler such as the credential schema (leaving the wallet to determine how to display the attributes to its user)

iii) how the issuer notifies the user(wallet) about the location of its meta data. Should it be a well-known URL based on its DNS name or something more complex requiring a protocol message.

iv) how the user (wallet) transfers its requirements to the OP, noting that this will be a subset of the published meta-data.

v) anything else?

[Tobias Looker]

Here are my thoughts on the issues raised

i) This should be defined as a string, which therefore allows for URI but does not make this mandatory

ii) Given that I would push for this metadata to be published primarily at the providers openid metadata endpoint, its structure can be whatever we like, I would vote for something optimized for this protocol rather than trying to use some complex like credential manifest.

iii) If it is published as a part of their openid metadata then this becomes known by the wallet during openid discovery.

iv) This is what the request is for

[Kristina Yasuda]

will close this on the basis of PR #145 unless there are objections.

[Kristina Yasuda]

re-reading the issue, I think we only answered the third bulletpoint in the original issue text. we might want to add a little more guidance for the parties using scope value:

• recommend to define credential format and proof formats of that credential type

• can be expressed using either string or URI - no restrictions

I would also add language like Parties using this claim will need to agree upon the meanings of the values used, which may be context-specific.

If this sounds ok, happy to do a PR.

[David W Chadwick]

Similarly, re-reading this issue, and given that credential types are already defined to be globally unique by W3C VCDM and ISO mDL, therefore if an issuer prefers to refer to the credential type via a locally defined string, then its metadata must point to the globally unique type so that there can be no ambiguity by the wallet (that may be interacting with multiple issuers that each define their own local strings).

@Kristina I dont think your text is sufficient because a wallet is not in a position to agree on the meanings of the issuer. A wallet has to accept whatever the issuer publishes. Thus the issuer’s published metadata must be globally unambiguous so that any wallet is able to accept it as published, without any confusion on behalf of the wallet.

Thus refering to PR #240, the issuers metadata can either use a local string or a globally unique URI to refer to the credential type, which will subsequently be used in all the protocol exchanges, and then in the former case the credential type metadata definition must say what the globally unique type is.

[David W Chadwick]

@Tobias Looker re iv) I am glad you said this, as one requirement is that the credential request should be able to ask for a subset of the subject claims that the issuer is able to make (as listed in its metadata either directly or indirectly by pointing to the credential schema)

[David W Chadwick]

Wrt to the four points mentioned above, then

i) PR#240 is addressing this point I believe

ii) and iii) PR#241 is addressing these points I believe

iv) is related to issue #1541 and no PR exists to resolve this point yet

[Kristina Yasuda]

PR #240

[David W Chadwick]

As I pointed out above, PR #240 only partially addresses this issue, and PR #241 and issue #1541 also need to be finalised.