Clarifications regarding SD-JWT in DIIP

[nanderstabel]

Hi all I have been doing some homework specifically regarding SD-JWTs + VCDM in DIIP/OID4VC since this is still a very confusing topic to me. Last year unfortunately I barely had the time to really dive in to this and therefore I also probably missed/misunderstood many of the discussions there have been regarding this (within DIIP and elsewhere).. After reading many github discussions/specs/meeting notes I'm still quite confused, but at least I learned I am not the only one 😅 I'm very interested in everyone's opinion here so any input is much appreciated. I'm mainly looking to validate whether I understand correctly what the key points of contention are (as well as confirming those things that are not contested). I also hope this can help others to get a better grasp of this topic.

DIIPv4/5 includes: "W3C VCDM 2.0 (20 March 2025) and SD-JWT VC (draft 13)" and "SD-JWT as specified in VC-JOSE-COSE (15 May 2025) and SD-JWT VC (draft 13)" with the corresponding vc+sd-jwt and dc+sd-jwt Credential Format Identifiers.

(I use enumeration in case anyone wants to respond to anything specific)

1. We know that both OID4VCI (Appendix A) and OID4VP (Appendix B) define these "Credential Format Profiles" which act as 'mini-specs withing the spec' that contain what's necessary to support several different Credential Formats in the Issuance and Verification flows by defining required behavior to 'fit' into several extension points.
2. One of these defined on the OID4VC specs themselves is dc+sd-jwt . This format is based on the IETF OAuth SD-JWT VC spec. This format is specifically well-suited for Credentials like PIDs and eduIDs.
   1. The (SD JWT VC) spec seems to apply that it has little to do with W3C VCDM:
      1. "Note: This specification does not utilize the W3C Verifiable Credentials Data Model v1.0, v1.1, or v2.0."
      2. "This specification defines validation and processing rules for verifiable credentials using JSON payloads and secured by SD-JWT [...]. Other specifications exist that define their own verifiable credential formats; for example, W3C Verifiable Credential Data Model (VCDM) 2.0 [...] defines a data model for verifiable credentials encoded as JSON-LD" (see https://datatracker.ietf.org/doc/html/draft-ietf-oauth-sd-jwt-vc-13#name-relationships-to-other-docu)
   2. Next to that there is this GH discussion in which also indeed is implied that W3C VC 2.0 that use SD-JWT is not to be confused with SD-JWT-VC ("Why would somebody confuse W3C VC 2.0 that use SD-JWT, with SD-JWT-VC?")
3. Given the points 2.i and 2.ii above it can be concluded that if one would want to issue/request W3C VCDMs as SD-JWTs that dc+sd-jwt is not the Credential Format Identifier to be used. However...:
   1. B.3.7 SD-JWT VCLD seems to contradict that..
      1. There appears to be significant architectural disagreement regarding the introduction of SD-JWT VCLD reading through this PR. Much of what's going on (behind the scenes?) goes over my head but this comment stands out for me: "Overall, I continue to think that the whole SD-JWT-* family of things is a bad idea that will complicate life for a lot of people and for existing implementations, contrary to the proclaimed "simple is a feature" philosophy. This here is something that's wanted for some intransparent political and business reasons and doesn't make much sense from a technology perspective."
      2. SD-JWT VCLD relates to 1.1, not 2.0
4. In general, OID4VC always only mentions VCDM1.1 (jwt_vc_json), never VCDM2.0
5. Since the the above options don't seem to be well-suited for W3C VCDM Credentials it make sense that DIIP includes the requirement: "Requirement: DIIP-compliant implementations MUST support W3C VCDM and more specifically Securing JSON-LD Verifiable Credentials with SD-JWT as specified in (VC-JOSE-COSE).". Indeed this makes sense since this is (one of two) recommended way for securing Verifiable Credentials. However, in combination with OID4VP/OID4VCI this comes with its own set of problems:
   1. OID4VP and OID4VCI do not define a Credential Format Profile for W3C VCDM(2.0) secured with specified in VC-JOSE-COSE.
   2. Their corresponding Appendices regarding Credential Format Profiles of course mention that "Other specifications or deployments can define their own Credential Format Profiles." and that: "It is RECOMMENDED that new Credential Format Profiles use the media type of the particular Credential Format for the Credential Format Identifier."
      1. Logically this then would indeed be vc+sd-jwt for credentials and vp+sd-jwt for presentations. Interestingly "The typ header parameter SHOULD be vc+sd-jwt " (see this) but this is not in line anymore with IETF OAuth Selective Disclosure JWT since version 14 when the typ value was changed to dc+sd-jwt 😅
   3. DIIP does not define nor references a Credential Format Specific Profile that defines required Parameters and Rules for how VCDM2.0 + VC-JOSE-COSE should fit OID4VC's extension points. The use of enveloped Credentials and Presentations (among other things) make it difficult/impossible to assume that Parameters and Rules that are defined for other Credential Formats (specifically jwt_vc_json and dc+sd-jwt) would also apply for vc+sd-jwt.
   4. @TimoGlastra brought up many of these issues back in August highlighting that these things are under-specified, however this does not seemed to end in any clear consensus (please correct me if I'm wrong).

Like I mentioned earlier, any addition/correction/opinion/validation/criticism is welcome.

[nklomp]

That is a proper "summary" of it indeed.

• VCDM2 with SD-JWT according to COSE-JOSE which is explicitly referenced from VCDM2 is not the IETF SD-JWT VC spec also in DIIP. They actually do have in common that both use/depend on IETF SD-JWT, which is the generic spec for selective dislocsure JWTs, minus the Verifiable Credential goodies on top. That automatically means that we actually require 2 credential formats in DIIP, one which has "native" json-ld capabilities and is VCDM compliant, the other is one of the 2 required formats in the ARF. And yes background is politics. To make matters worse, what is now dc+sd-jwt (so SD-JWT VC) was previously called vc+sd-jwt, which has since become VCDM2 + SD-JWT. Not to mention that a SD-JWT VCDM was proposed at one point :P

The whole reason why we wanted VCDM2 with SD-JWT in is the json-ld support, as semantics in business and DPP use cases are important. Also outside of the EU VCDM is quite heavily used. Then we wanted selective disclosure on top. Since we already all had SD-JWT VC in previous specs, and thus JWT and SD processing, it made the most sense to choose VCDM2 with SD-JWT.

• VCDM2 and COSE-JOSE spec are underspecified on things like keybindings with DIDs, subject ids, presentations. To me instead of using CNF it makes sense to be using the kid when using DIDs, but that does raise the question what to do when no DID is used, are we then using a CNF? Or do we support both always. But then it might make sense to just have the kid in the CNF. The way we verify generic CNFs, is (pic from documentation is easier):