Proposal to remove W3C VCDM v2 from DIIP (v5)

[TimoGlastra]

One of our experiences implementing DIIP v4 is that it was underspecified. Especially the parts about W3C VCDM v2 with SD-JWT. Parts of this is because of the missing definitions for OID4VC, which is something we can define (i think we've come to somewhat of an agreement in #67). However part of this is also due to the overly complex and vague W3C VCDM V2 specification, which leaves a lot open to interpretation, and is also not consistent between the DataIntegrity and JOSE-COSE definitions.

One of the benefits of W3C VCs is that you have a data model that is consistent, and you then have different signing methods to secure the VC (like SD-JWT/JWT/DataIntegrity). However in e.g. VC-JOSE-COSE they recommend using cnf for key binding, but there's no mention anywhere how this related to credentialSubject.id. It does mention credentialSubject.id must match with the sub claim. However in the VCDMv2 or VC DataIntegrity specs there's no mention at all of how this key binding works, so you'll have to assume you need to use credentialSubject.id to do the binding. This results in a very weird incosistency, which is not clearly described how to deal with it. What should happen if:

• you have a JWT W3C v2 VC with credentialSubject.id, but without cnf?
• you have a JWT W3C v2 VC with credentialSubject.id that is a did, and cnf that is jwk?
• you have a JWT W3C v2 VC with credentialSubject.id that is a did, and cnf that is jwk but the keys don't match?
• you have a JWT W3C v2 VC with credentialSubject.id that is a did, and cnf that is did but the dids don't match?

We don't really see the value this extra credential format provides over SD-JWT VC, and although I wasn't really a fan of SD-JWT VCLD before, I now see the value of it more, because it builds on the consistent foundation of SD-JWT and SD-JWT-VC enabling support for JSON-LD.

In the current state we're not sure how we can properly integrate W3C VCDM v2 (besides experimental implementation) that doesn't compromise on interoperability, consistency and security.

I feel we can better focus on a single credential format, especially with the pace new DIIP versions are being released it's hard to keep up and achieve interoperability. For every new feature in DIIP, we'll have to make sure it works correctly with all the credential formats. For example also OpenID Federation will require specific integration with all the supported credential formats. We need to ensure the security properties of the different credential formats match. It'd be unfortunate if DIIP became a kitchen-sink specification.

For those reasons we'd be a proponent of removing W3C VCDM v2 from DIIP, and optionally adopting SD-JWT VCLD to enable JSON-LD support.

[ubamrein]

+1 as we also struggled implementing this. Especially as there are multiple different ways of enveloping and securing various parts of the parts in the data model, I feel like having real interoperability would be hell of a struggle (as can be seen by the discussion #67).

[nklomp]

Moved my response over to the main thread instead of a reply here

[nklomp]

Very strong -1

The whole reason it was included was 2-fold. First to have a W3C VCDM compatible implementation that support selective disclosure. Second and more important to have proper JSONLD processing and thus semantic interop as that is much needed in the scope of organizational exchanges and for instance digital product passports or dataspaces.

I am assuming you mean SD-JWT VCDM instead of VCLD. If not happy to be pointed to the correct spec. However these specs are nowhere near official, have not been updated for over a year and live in someone's personal Github repo. To me it is unclear how actual proper jsonld processing with multiple types would work based on a single vct value and if you carefully look at vct metadata I think the way the inheritance with multiple different vcts, branding and schema's works is a minefield and my gut feeling is that it also is easily exploitable for this reason from a security perspective.

IMO the approach should be as always to raise issues with upstream about questions and inconsistencies.

I am not in favor of favoring any unproven spec in a personal repo over wat are official W3C recommended specs.

Also from an interop perspective with other jurisdictions than the EU tne W3C VCDM 2 route IMO makes the most sense. Also the ARF till date also still mentions VCDM2 as the 3rd option next to the mandatory mdocs and sd-jwts

[ubamrein]

If it is needed, we need a clear specification dealing with it, as the openid4vp/vci specification currently only really talk about vcdm1.1.

If it is defined in the openid4vc space, I would also be in favour of choosing one specific way of doing it:

The current specification allows for at least 6 different ways of handling a presentation, which for sure leads to interop issues:

Also, I don't really see the advantage of selective disclosures for the enveloped presentations. Looking at example 6 in the worst case there are three nested sd-jwts. This is a interop/implementation nightmare in my opinion.

[TimoGlastra]

I was talking about SD-JWT VCLD, as defined in OpenID4VP 1.0: https://openid.net/specs/openid-4-verifiable-presentations-1_0.html#name-sd-jwt-vcld

In short it:

SD-JWT VCLD (SD-JWT Verifiable Credentials with JSON-LD) extends the IETF SD-JWT VC [I-D.ietf-oauth-sd-jwt-vc] Credential format and allows to incorporate existing data models that use Linked Data, e.g., W3C VCDM [VC_DATA], while enabling a consistent and uncomplicated approach to selective disclosure.

Information contained in SD-JWT VCLD Credentials can be processed using a JSON-LD [JSON-LD] processor after the SD-JWT VC processing.

I'm not saying SD-JWT VCLD is the way to go, as I have no implementation experience with it. I just wanted to point out a possible alternative. My main concern is with the speed at which DIIP is pushing new versions and specs, and it being required and pushed in more and more projects (which is a great thing), but it definitely not being ready for actually interoperability due to requirements being unclear. W3C VCDM v2 with SD-JWT is not enough (at least for us) to implement W3C VCDM v2 with SD-JWT, since the specs are very unclear / open to interpretation in our case.

Due to amount of signature suites that also existed for VCDM v1.1, and also the two encoding/signing formats (JSON-LD and JWT) it was really hard to achieve interop with it. Add to that that the processing rules in v1.1 were also unclear (esp for JWT), it lead to even more compatibility issues (esp the matching of JWT payload values vs VCDM values). And initially I'd have thought VCDM v2 would solve these issues, but IMO they got worse. There's now 4 total signing methods (COSE, JOSE, SD-JWT and DataIntegrity), and then even multiple ways to do selective disclosure (SD-JWT but also a DataIntegrity way of doing it) and as I pointed out in my initial discussion, they are not even consistent in how for example key/holder binding works