- From: Manu Sporny <msporny@digitalbazaar.com>
- Date: Tue, 30 Jan 2024 09:59:06 -0500
- To: W3C Credentials CG <public-credentials@w3.org>
On Mon, Jan 29, 2024 at 5:27 PM John, Anil <anil.john@hq.dhs.gov> wrote: > This is excellent to finally see this working in practice! Congratulations! Thanks, and I'm sure it goes without saying, but some of the US, Canadian, and EU government positions wrt. enhancing citizen privacy drove a lot of the development in this area over the years. Trying to find a technology solution that ticked the "government approved cryptography" checkbox while ALSO enabling some of the newer privacy preserving cryptography in the field was an explicit design goal. Now that the Data Integrity technology is nearing completion at W3C, it should enable faster innovation/experimentation in the field without risking safety. With these sorts of VCs, you always have the government approved cryptographic algorithms backing the VC. In addition, for those, like commercial enterprises and civil society, that want some more future facing features (that are not yet government approved), they can use the more future facing technologies (such as BBS). > Manu – Three questions: > Does this approach allow for the support of quantum safe signature schemes as another option down the line when those become more specified? Yes, you would just add a quantum-safe signature scheme IN PARALLEL with the existing signatures we are demonstrating today. As a thought exercise: An implementer wouldn't even have to wait for NIST to approve any particular quantum-safe scheme. One could deploy an experimental quantum-safe scheme today, such as FALCON and SPHINCS+, in parallel with a government approved digital signature. This is the benefit of this approach, it's not an "all or nothing" signature like many of the digital signature approaches that have preceded this breakthrough. > Does this approach allow for the support of anoncred based signatures in parallel with others? Yes, in theory. We're working with some of the AnonCred's folks on a Data Integrity mechanism that would allow the demonstration of a parallel AnonCreds signature. There are still details to be worked out; more to come in the months to follow. Perhaps someone from the AnonCreds community that is working on this particular initiative can provide a quick update on their progress in this area? > It sounds like the wallet has a specific role here >> “I'll pick the one that the Verifier will accept and that maximizes privacy for the Holder: BBS”; which also implies that the wallet could choose to be NOT select the most privacy preserving option << which then follows that this is an area that people who are making choices between wallets need to be aware and be educated on what the wallet could do behind the scenes. Is my understanding correct here? Yes. Ideally, the digital wallet automates the choices such that it's protecting the Holder to the greatest extent that it can, given the cryptography and protocols available to it during a particular transaction. For example, if an Issuer doesn't provide a VC with the option of selective disclosure or unlinkability, then there is only so much the wallet can do when it presents a VC. This, of course, raises the question on whether or not an individual is going to understand the difference between a non-selectively disclosable VC, a VC that is selectively disclosable, and a VC that is selectively disclosable AND unlinkable... or if the VC contains correlatable data even if it is selectively disclosable and unlinkable. This is where gazing into the crystal ball that sees into the future starts to get blurry. Fundamentally, we're going to have to figure out a way to build digital wallet interfaces that help an individual decide the right thing to do without overwhelming them with information. If we ask them to make a decision that they're not informed enough to make, they're likely just going to keep clicking until they get through to the thing they want (even if that means a number of self-inflicted privacy violations in the process). At present, our digital wallet does automate some of these decisions. For example, if both ECDSA and BBS are supported by the Verifier, our wallet defaults to using BBS (because at least you have unlinkability with that approach). That is a decision that can be easily automated. However, if the BBS disclosure contains Personally Identifying Information in a field that the wallet doesn't understand, what then? Share by default? Warn the Holder? If we warn the holder, what do we say? Should we even warn the holder; maybe they know what they're doing? I think we all agree that digital wallets should only involve the individual when absolutely necessary, and when that happens, need to ask questions in a way that doesn't require the individual to be a privacy expert to make the right choice for a given situation. Web browsers largely get these things right in their permission dialogs today (e.g., "Do you want to let this website access your microphone and camera?"). I expect digital wallets will compete on features such as these over the next several years, and I don't expect digital wallets that don't protect the individual's privacy to fare well over the long-term. It feels like educating Holders is going to be a difficult task (not impossible, but difficult). It might be that the simpler path forward, at least for the near term, is to try to drive the right privacy behaviour through intuitive wallet interfaces and educating issuers/verifiers on providing the right options so privacy decisions can be automated to the greatest extent possible. Of that potential future, I'm 60% certain. :P -- manu -- Manu Sporny - https://www.linkedin.com/in/manusporny/ Founder/CEO - Digital Bazaar, Inc. https://www.digitalbazaar.com/
Received on Tuesday, 30 January 2024 14:59:49 UTC