msporny
commented
1 week ago @peacekeeper wrote:
Unlike ISO mDL and SD-JWT (VC), the W3C VC Data Model 2.0 in conjunction with Data Integrity has been designed for this. No matter if you secure the credential with classic signatures, and/or if you use salted hashes, or BBS or CL signatures, or no signatures at all, the core credential format and data model does not change. This seems much more future-proof and makes it possible to switch out different securing mechanisms, with minimal impact on the rest of an architecture and implementation.
Yes, strong +1 to this. The case for what @peacekeeper is saying above is made clearly in the recent expert cryptographic review that found that SD-JWT was not a viable path forward. As has been repeatedly stated over the years, SD-JWT does not provide unlinkability (nor was it designed to), and the mechanism where we issue 100s of SD-JWT VCs for a single credential in an attempt to get it to support unlinkability is not a viable general strategy (it requires non-trivial, highly available infrastructure).
In other words, if the EUDI work had shipped SD-JWT, we'd be in a position of having to change the fundamental format all over again because it didn't support unlinkability in a scalable way. That is to say, when you mix the cryptographic layer with the data model layer, bad things happen and this is being demonstrated in the current discussion around SD-JWT.
The VC Data Model and VC Data Integrity were designed to take a more layered approach that is not susceptible to the sorts of design flaws that SD-JWT is experiencing. That is, no matter what Data Integrity securing mechanism is used, the core data model does not change. It provides seamless cryptographic agility, upgradability, and layering. A single verifiable credential can be protected by a full disclosure securing mechanism (ecdsa-rdfc-2019 or eddsa-rdfc-2022), a selective disclosure securing mechanism (ecdsa-sd-2023), or an unlinkable and selective disclosure securing mechanism (bbs-2023), or any and all combinations thereof, with all of them attached to a single payload.
SD-JWT-VC nor JWP provide that sort of cryptographic agility, layering, or Developer Experience. These things matter if the EU wants to provide the best technical capabilities to protect their citizens and their privacy when these new technologies are broadly deployed.
Do not tightly couple the credential format with the securing mechanism, as SD-JWT and JWP do; it's a recipe for an ossified and brittle ecosystem.
OR13
As others have already pointed out in issues in this repo, both ISO mDL and the SD-JWT (VC) family of specifications define credential formats that are "locked in" to certain securing and selective disclosure mechanisms, such as salted hashes.
Now as other approaches are being considered (including zero-knowledge proofs, or even no signatures at all via secure channels), it seems wise to pick a credential format that is flexible and extensible with regard to how a credential is secured.
Unlike ISO mDL and SD-JWT (VC), the W3C VC Data Model 2.0 in conjunction with Data Integrity has been designed for this. No matter if you secure the credential with classic signatures, and/or if you use salted hashes, or BBS or CL signatures, or no signatures at all, the core credential format and data model does not change. This seems much more future-proof and makes it possible to switch out different securing mechanisms, with minimal impact on the rest of an architecture and implementation.
See here examples of what a W3C VC can look like that uses different types of securing mechanisms:
(Created using the VC playground - https://vcplayground.org/)