DIIPv5 proposal and feedback

[nklomp]

During the DIIP meetup today October 30th we decided a proposal for DIIPv5.

The timeline will be mid January 2026 as discussed in #70. Given this is a short timeline we want to keep the requirements manageable for implementers.

The things we want to add/change in DIIPv5 are:

• OID4VP and OID4VCI 1.0 final instead of current draft version in V4
• Clarifications around VCMD2/SD-JWT
• Clarifications around statuslists
• Optional inclusion of OpenID Federation for trust establishment.

The last item allows vendors, that do not have the resources to spend on OIDFed, to still be DIIPv5 compliant. Be aware though that it is very likely that DIIPv6 (sept/oct 2026) is likely to include OpenID Federation as mandatory though! The proposal for the optionality in V5 can be found/discussed in #71

Happy to hear any objections or comments on the above proposed list for V5

[muisit]

Given the discussions around VCDM 2 presentations and given that the latest OID4VCI/OID4VP specs still refer to VCDM 1.1 type credentials, I would suggest adding support for the somewhat simpler VCDM 1.1 spec, perhaps in preference over the VCDM 2 spec (MUST implement VCDM 1.1, MAY implement VCMD 2). Because VCDM 2 is largely a superset of VCDM 1.1, I do not expect supporting both should be much of an issue, but I may be mistaken.

In the very least we should add a definitive type-to-specification list like:

• jwt_vc_json refers to VCDM 1.1 credentials
• ldp_vc refer to VCMD 1.1 credentials with linked data proof
• vc+jwt refer to VCDM 2 credentials
• vc+sd-jwt refers to VCDM 2 credentials encoded as SD-JWT using the JOSE/COSE securing spec refered to in DIIPv4, without a vct type
• dc+sd-jwt refers to SD-JWT credentials containing a vct claim with a type specification

[samuelmr]

I would suggest adding support for the somewhat simpler VCDM 1.1 spec, perhaps in preference over the VCDM 2 spec (MUST implement VCDM 1.1, MAY implement VCMD 2).

I had similar thoughts some months ago. The community didn't seem willing to require support for an "outdated" format.

• jwt_vc_json refers to VCDM 1.1 credentials
• ldp_vc refer to VCMD 1.1 credentials with linked data proof
• vc+jwt refer to VCDM 2 credentials
• vc+sd-jwt refers to VCDM 2 credentials encoded as SD-JWT using the JOSE/COSE securing spec refered to in DIIPv4, without a vct type
• dc+sd-jwt refers to SD-JWT credentials containing a vct claim with a type specification

If these types are already defined in the respective specifications, would reiterating them in the DIIP spec be implementation guidance rather than setting interoperability requirements?

[muisit]

They're not defined explicitely per se.They are definitely not all defined in the OID4VCI spec.

You could interpret jwt_vc_json as any VCDM 1.1 or VCDM 2.0 credential. The VCDM 1.1 spec does not mention jwt_vc_json as an OID4VCI type, of course. VCDM 2.0 mentions vc+jwt, but again, that is not mentioned in OID4VCI by itself.

vc+sd-jwt is in invalid type officially, because it was a predecessor of dc+sd-jwt and both would refer to SD-JWT type credentials. I think the latest OID4VCI spec only refers to dc+sd-jwt. By specifying that the older type is used in our implementations to signal the VCDM-as-SD-JWT version, you make it clear for implementators what to expect.

[nklomp]

vc+sd-jwt really does mean the new VDM2 type. Allignement between sd-jwt and W3C has been sought very late in the OID4VC specs, resulting in the vc+sd-jwt mess, which was previously used for SD-JWT VC and thus later replaced by dc+sd-jwt for SD-JWT VC, because it clashed with the already used term by W3C for W3C VCs and SD-JWT (non VC). We should use the W3C identifiers/mediatype for VCDM2 in OID4VC, which according to the COSE-JOSE specs means vc+jwt and vc+sd-jwt for the VCDM2 Jose and SD-Jwt creds.

The fact OID4VC does not list all types does not mean much, it simply doesn't list all credential formats out there. W3C VCDM is well addopted accross the world, and one of the good things about version 2, is that it is very explicit about the type names vs the encoding.

The profiles are not part of the normative statements in the OID4VC specs at all, the spec even litterally lists this in the profiles sections:

This section defines Credential Format Profiles for a few of the commonly used Credential Formats. Other specifications or deployments can define their own Credential Format Profiles. It is RECOMMENDED that new Credential Format Profiles use the media type of the particular Credential Format for the Credential Format Identifier.

Except for the legacy naming mess, there should be no confusion about it whatsoever and we should follow the above recommendation and ideally create a PR to extend the profiles section