Re: Breakthrough: Parallel Signatures - NIST, ECDSA-SD, and BBS

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