Re: [w3ctag/design-reviews] BBS Cryptosuite v2023 Securing Verifiable Credentials with Selective Disclosure using BBS Signatures (Issue #922)

> Hi all, Thanks for sending this our way. 

Thank you for the review, we really appreciate it!

> We are explicitly not reviewing the BBS Digital Signature Algorithm itself (for avoidance of doubt)

Understood and expected, the [BBS digital signature algorithm](https://datatracker.ietf.org/doc/draft-irtf-cfrg-bbs-signatures/) itself (the low level primitives we're using in the W3C vc-di-bbs specification) is currently [undergoing cryptographic review at the IETF](https://mailarchive.ietf.org/arch/msg/crypto-panel/kLkG_1q6ZejtnXd0HNMWqBDzh5I/). 

> but your cryptosuite using it seems fine to us.

Ok, good to know. 

> We note that verifiable credentials signed with BBS aren't likely to be interoperable with those signed with other algorithms. (We recognise this is probably unavoidable, given the architecture you're using.)

Hmm, there is nuance here that's important. The W3C Data Integrity specification, which the TAG has already reviewed, enables a single data payload to be [secured using multiple cryptography suites](https://w3c.github.io/vc-data-integrity/#proof-sets) in [parallel](https://w3c.github.io/vc-data-integrity/#agility-and-layering). I believe that TAG is already aware of this, but this statement makes me wonder if we should write more about this in the specification, perhaps with a few diagrams demonstrating this particular aspect of W3C Data Integrity.

This does allow a BBS signature to "sit beside" an ECDSA signature and an EdDSA signature (you can have all three, in parallel, on a single verifiable credential. Clearly, this requires the issuer to issue the credential with each signature type for this to work. It also requires the verifier to support multiple different types of cryptosuites. This enables the holder of that verifiable credential to choose which mechanism to use when interacting with a verifier, which we believe enhances privacy and unlinkability for the individual. Why send all the information in a government-issued ID over when all you're trying to do is provide a registered mailing address? 

So, the nuance around "aren't likely to be interoperable with those signed with other algorithms" is a bit off and I wanted to clarify the above.

More specifically, it would be useful for the TAG to comment on the desirability of such a feature set. At present, there are national governments that are suggesting that they settle on digital signature mechanisms that create tracking dangers. Most digital signature schemes today do not generate unlinkable signatures (like BBS does) and act like a super tracking cookie (the digital signature itself is globally unique so the individual can be correlated across all interactions that they have in person and on the web if parties collude). This is, clearly, not an ideal state of affairs and the WG is endeavoring to provide a feature that can combat this sort of pervasive tracking. That does not mean there aren't legitimate uses for more traditional signature schemes... if the data being sent over has personally identifiable information in it, then no amount of unlinkability when it comes to the digital signature will help.

To put it another way, for digital credentials, does the TAG find it acceptable for a software ecosystem to NOT provide an unlinkable digital signature solution at all? I admit that this is a bit of a loaded question as the EU seems to be on track to NOT providing such a solution in their digital wallet reference framework. Would the TAG be willing to weigh in on this, and if so, would a meeting about it with the VCWG be appropriate?

> Let us know if you have any specific questions or issues for us. Otherwise, we are happy to close it.

The only specific issue that would be good for TAG to have a position on is the above. Are we at a point where providing unlinkable digital signatures SHOULD/MUST be supported in future-facing digital credential solutions, or are we not there yet?

-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3ctag/design-reviews/issues/922#issuecomment-1893900687
You are receiving this because you are subscribed to this thread.

Message ID: <w3ctag/design-reviews/issues/922/1893900687@github.com>