- edited description
OID4VCI format property
The W3C VC WG is defining how to encode a VC as a JWT in the document available at
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.)
Comments (9)
-
reporter -
reporter 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.
-
reporter 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.
-
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. -
reporter 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. -
reporter E.g. see for example https://github.com/w3c/vc-data-model/pull/1100
-
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.
-
duplicate of
#1960. -
- changed status to resolved
Migrated to GitHub
- Log in to comment