OID4VCI format property

[David W Chadwick]

The W3C VC WG is defining how to encode a VC as a JWT in the document available at

https://w3c.github.io/vc-jwt/

This specifies two types for a JWT and an additional type for a CWT encoded VC, namely

vc+ld+jwt and vc+jwt and vc+ld+cwt

It also specifies the MIME media types for these namely

credential+ld+json and credential-claims-set+json and credential+ld+json respectively, but this alone is insufficient to determine the transfer format.

The W3C WG (will) also define the mapping rules for how these encoded transfer formats are converted into standard W3C credentials.

It is suggested that the format property values specified in Appendix E of OID4VCI use the same values as the transfer formats specified in the W3C (or other) specification. Then when additional transfer formats are defined e.g. for ACDC, that type can be used in the OID4VCI protocol without any additional text being needed. (Alternatively if a different format value is used (such as jwt_vc_json) then text should be added to state which VC transfer format it refers to. The disadvantage of this method is that mappings will be needed for all future transfer syntaxes.)

‌

[David W Chadwick]

Note that the current description in Appendix E does not refer to the correct W3C document - it refers to the VCDM rather than the JWT specification.

[David W Chadwick]

Note also that E.1.1 is entitled VC signed as a JWT, not using JSON-LD

whereas in fact the transfer format is for a JWT that can be converted into a standard W3C VC, but it is not a bi-directional mapping as it does not cater for any W3C credential being signed as a JWT.

[Kristina Yasuda]

I think this issue was raised before VCDM 2.0 decided to define only vc+ld+json media type, so if we use it, we won't be able to differentiate between a VCDM 2.0 credential signed using JWS and the one signed using data integrity.

[David W Chadwick]

I think we need to park this issue until the VCWG has finished its deliberations, since only yesterday (23 June) a whole call was devoted to the @context issue. I suspect the VCWG will determine how a wallet can differentiate between proof types, since there is no requirement for a wallet to support any particular proof type.

[David W Chadwick]

E.g. see for example https://github.com/w3c/vc-data-model/pull/1100

‌

[Kristina Yasuda]

with PR 88 in JWT-VC close to merging, we expect W3C VC WG to focus only on JSON-LD and vanilla JSON work moving to IETF. We also do not expect W3C VC WG defining identifiers for JSON-LD payload signed using JWS and signed using Data Integrity Proofs, because Data Integrity Proofs do not have the concept of using media types for typing the credential.

[Kristina Yasuda]

duplicate of #1960.

[Mark Haine]

Migrated to GitHub

https://github.com/openid/OpenID4VCI