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

>
> > 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?


I'm not directly working on the initiative however I've been following it
closely. There is code available in the anoncreds repository to issue such
a credential which I've tested. I will be working on designing a production
credential in the next few months that combines a TraceableCredential from
the traceability draft specification and the AnonCreds DataIntegrity work
through parallel signatures. Ideally this credential will be compatible
with different systems and allow issuers to present these credentials to
various partners depending on their business needs. I also co-authored the
AnonCreds did:web: method spec draft which is what I will base this
prototype on.

On Tue, Jan 30, 2024 at 10:00 AM Manu Sporny <msporny@digitalbazaar.com>
wrote:

> 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/
>
>