search

openid / OpenID4VCI

64 stars 18 forks source link

OID4VCI format property #24

Closed OIDF-automation closed 6 months ago

OIDF-automation commented 1 year ago

Imported from AB/Connect bitbucket: https://bitbucket.org/openid/connect/issues/1877

Original Reporter: dwc8

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.)

‌

OIDF-automation commented 1 year ago

Imported from AB/Connect bitbucket - Original Commenter: dwc8

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.

OIDF-automation commented 1 year ago

Imported from AB/Connect bitbucket - Original Commenter: dwc8

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.

OIDF-automation commented 1 year ago

Imported from AB/Connect bitbucket - Original Commenter: KristinaYasuda

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.

OIDF-automation commented 1 year ago

Imported from AB/Connect bitbucket - Original Commenter: dwc8

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.

OIDF-automation commented 1 year ago

Imported from AB/Connect bitbucket - Original Commenter: dwc8

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

‌

OIDF-automation commented 1 year ago

Imported from AB/Connect bitbucket - Original Commenter: KristinaYasuda

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.

OIDF-automation commented 1 year ago

Imported from AB/Connect bitbucket - Original Commenter: KristinaYasuda

duplicate of #41 .

jogu commented 6 months ago

closing as we have a duplicate ticket https://github.com/openid/OpenID4VCI/issues/41 - if anything isn't covered by that ticket please feel free to add a comment there.