Clearly define VC format types when issuing

[woutslakhorst]

With all the work that is being done for ARFv1.2, VC data model 2.0 and data integrity, there'll be a multitude of VC formats that need to be supported. For our APIs we need a clear set of format and media types, etc.

[woutslakhorst]

From VC data model v1.1

• JSON‑LD+JWT: The current JWT type credential. (for newer stuff, revocation and discovery)
• JSON‑LD+LD‑Proofs: The default VC type on the network

From SD-JWT (https://www.ietf.org/archive/id/draft-ietf-oauth-selective-disclosure-jwt-07.html#name-media-type-registration):

• SD-JWT: application/sd-jwt default for compact JWT notation
• (application/sd-jwt+json and application/kb-jwt for json JWT notation and keybinding)

From VC data model v2.0

• application/vc+ld+json is the media type for a VC (no proof type)
• application/vp+ld+json is the media type for a VP (no proof type)

Nothing from data integrity model or specific proof formats.

From https://www.w3.org/TR/vc-jose-cose (omitted cose):

• application/vc+ld+json+jwt
• application/vp+ld+json+jwt
• application/vc+ld+json+sd-jwt
• application/vp+ld+json+sd-jwt

refs:

• https://www.w3.org/TR/vc-data-model-1.1
• https://www.w3.org/TR/vc-data-model-2.0
• https://www.w3.org/TR/vc-di-ecdsa/
• https://www.w3.org/TR/vc-di-eddsa/
• https://w3c.github.io/vc-data-integrity/vocab/security/vocabulary.html
• https://www.w3.org/TR/vc-data-integrity/
• https://www.w3.org/TR/vc-jose-cose/
• https://www.ietf.org/archive/id/draft-ietf-oauth-selective-disclosure-jwt-07.html

Given all of the above:

• raw content is always json-ld
• change issuance API, add param type and cryptosuite
• type is json-ld+jwt or json-ld+ld-proofs for v1.1 data model. Cryptosuites are hardcoded to es256 and JsonWebSignature2020
• type is ld+json+jwt, ld+json+sd-jwt or ld+json for v2.0 data model. Where the last type uses dataIntegrityProof (type is not listed anywhere). cryptosuites for the first 2 follow jwt definitions. The last follows: https://www.w3.org/TR/vc-di-ecdsa/ and https://www.w3.org/TR/vc-di-eddsa/

Support now:

• json-ld+ld-proofs with JsonWebSignature2020
• json-ld+jwt with es256

Support next (order of importance):

• ld+json+sd-jwt
• ld+json+jwt
• ld+json (prioritise json canonicalisation and ecdsa)

[reinkrul]

Change current format enum values to json-ld+jwt and json-ld+ld-proofs

[woutslakhorst]

Change current format enum values to json-ld+jwt and json-ld+ld-proofs

don't do this for any PEX related things. Only for the issuance API

[reinkrul]

go-did's VerifiableCredential.Format() should also return these values (instead of jwt_vc), right @woutslakhorst ?

[woutslakhorst]

go-did's VerifiableCredential.Format() should also return these values (instead of jwt_vc), right @woutslakhorst ?

Yes, which probably means you have to map the formats to PEX formats somehow....

[reinkrul]

From VC data model v1.1 JSON‑LD+JWT: The current JWT type credential. (for newer stuff, revocation and discovery) JSON‑LD+LD‑Proofs: The default VC type on the network

Where did you read this? I think the type/format designators are in flux currently. Can't we keep it as it currently is for the v6 release, and just add the new formats (e.g. SD), and maybe an alias for the JWT/JSON-LD VCs (and deprecate the current ones)?

[woutslakhorst]

for v1.1 they aren't defined. Also PEX formats/types are different from W3C.

[gerardsn]

Considering that each spec (group) currently seems to use its own convention it probably comes down to whom we want to be compatible with? I think most parties that implement the openid4vc specs use the PEX formats (and possibly the weird *_json types).

What is the argument to change this now? I agree that it would be nice to have one fixed convention for this, but I don't think there is any consensus on this yet?

[woutslakhorst]

maybe the now is: "in a few weeks/months"...

[woutslakhorst]

The "official" registry seems to be dead....

Propose to wait for v6.x to do this.