- From: Manu Sporny <msporny@digitalbazaar.com>
- Date: Wed, 30 Aug 2023 09:39:10 -0400
- To: Sebastian Elfors <sebastian.elfors@idnow.de>
- Cc: Brent Zundel <Brent.Zundel@gendigital.com>, "public-vc-wg@w3.org" <public-vc-wg@w3.org>, Altmann Peter <peter.altmann@digg.se>
On Wed, Aug 30, 2023 at 5:54 AM Sebastian Elfors <sebastian.elfors@idnow.de> wrote: > Hopefully, this clarifies the principles of unlinkability as described in ETSI TR 119 476. Hi Sebastian and Peter, thank you for the paper and all the effort that went into it. I have skimmed it and found a number of areas of concern. I'll just mention three of them in this email, as I haven't been able to read it in depth. The first issue is that it doesn't include a variety of other selective disclosure schemes that are under active development... namely, ACDC, Gordian Envelopes, the Singapore governments work, and ecdsa-sd. The latter one is a part of a deliverable for the VCWG: https://w3c.github.io/vc-di-ecdsa/#ecdsa-sd-2023 presentation about it is here: https://docs.google.com/presentation/d/1d-04kIWhPuNscsAyUuRH3pduqrNerhigCWahKe6SNos/edit# The second issue is that some of the conclusions reached in the analysis don't seem to align w/ with the specification text in the VCDM specification. Most notably, the claim that SD-JWTs are incompatible w/ the VCDM. I'll try to find more time to read through the material with my VCDM Editor hat on, but given the length of the paper (and the VCWG's current workload), it might take a while to get back to you on this. The third issue has to do w/ Brent's read on the paper... I was confused in the same way that he was wrt. how the term unlinkability is used in the paper. > Issue a batch of SD-JWTs to the Holder to enable the Holder to use a unique SD-JWT per Verifier. This only helps with Verifier/Verifier unlinkability.” Oof, no, that's a dangerous thing to suggest. > Hopefully, this clarifies the principles of unlinkability as described in ETSI TR 119 476. It helps, and it aligns more closely with what I thought the definition of "unlikability" was... but it highlights more concerns as a result. I'll be bold and say that it would be a stretch to say that the current trajectory supports unlinkability at any real depth. In fact, it proposes that unlikability is possible, but using an approach that has been demonstrated to fail in the past, which is effectively a variation on stateful signatures. The problem w/ stateful signatures over the many years that they've existed is that implementers usually get the "state tracking" part of the implementation wrong in a variety of ways. In fact, we had considered it for ecdsa-sd and decided that it would create two untenable issues: * a misimplementation at a wallet would result in a privacy failure (accidentally sending a previously used signature/hash). * it would require coordination among multiple devices if the wallet was multi-device capable (which we expect a number of wallets to be multi-device capable). So, instead of stating that "it is possible for ecdsa-sd to be unlinkable", we chose to say: "No, we shouldn't even promise that because it's so easy for an implementation to mess it up and create a privacy failure." That is why we believe that if unlinkability is desired, you will need to use a scheme that actually supports it at the cryptographic layer -- something like BBS+, which the VCWG is also working on. More as some of us read through more of the paper... thank you again for the analysis, you've got the attention of at least some of the people in the WG. :) -- manu -- Manu Sporny - https://www.linkedin.com/in/manusporny/ Founder/CEO - Digital Bazaar, Inc. https://www.digitalbazaar.com/
Received on Wednesday, 30 August 2023 13:39:54 UTC