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

Thanks for posting about this, Manu -- great stuff!  In response to your
request:

> Perhaps someone from the AnonCreds community that is working on this
> particular initiative can provide a quick update on their progress in this
> area?


In the AnonCreds and Aries work in Hyperledger/OWF, we're converting
AnonCreds to be W3C Verifiable Credentials Data Model (VCDM) Standard
compliant by changing the format for AnonCreds VCs and VPs into Data
Integrity Proofs. The AnonCreds Specification[1] has been updated to
embrace the VCDM formats, and the AnonCreds Rust[2] implementation has been
updated to support the W3C VCDM v1.1 and v2.0 specifications. Currently,
work is going on in Aries Cloud Agent Python[3] and the OWF"s Credo[4] (the
new name of Aries Framework JavaScript) implementations to use the new
format.  We've demonstrated issuing a VCDM credential with multiple
signatures (as Manu describes in the original email, but with AnonCreds),
and have made adjustments (based on some clever ideas from Timo Glastra,
Animo Solutions) to the Aries issuance protocols to enable requesting and
issuing W3C VCs with multiple signatures with holder binding as needed.
We're also going to be using DIF Presentation Exchange[5] for AnonCreds and
non-AnonCreds presentations.The Government of British Columbia is helping
to fund the initiative, and we've had great feedback from the Data
Integrity community on getting that VC-DI format right and plan to have the
implementations "in the wild" in the coming months.

[1]: https://hyperledger.github.io/anoncreds-spec/
[2]: https://github.com/hyperledger/anoncreds-rs
[3]: https://aca-py.org
[4]: https://github.com/openwallet-foundation/credo-ts
[5]: https://identity.foundation/presentation-exchange/

We're also working on AnonCreds v2, which extends the easy-to-use ZKP
capabilities of AnonCreds v1 (unlinkability w/revocation, selective
disclosure, holder binding, predicates) and updates the underlying
signature scheme from CL Signatures -- as a Data Integrity Proof. We have
code for AnonCreds v2 that uses PS[6] Signatures, but is pluggable to
support BBS+ Signatures and there is even a possible post quantum option
possible with PS PQ[7] signatures (experiments needed!).  In addition to
the AnonCreds v1 ZKP capabilities, v2 adds ZKP claim equality (proving
claims in different VCs are equal without revealing the values), domain
proofs, verifiable encryption, set membership, range proofs, blinded claim,
and a peer-reviewed, scalable ZKP-based (unlinkable) revocation scheme --
ALLOSAUR[8].  The specification and implementation are not yet to the
AnonCreds v1 level of maturity, but there is a complete AnonCreds v2 Rust
implementation[9], and a to-do list of what is needed to "make it real". We
see this work as merging the outstanding BBS+ Signatures work with the ease
of use of AnonCreds -- apply some additional decisions about how to use the
ZKP capabilities in a way to enable interop -- using the patterns long
established by AnonCreds v1.

If anyone is interested in collaborating, please reach out.

[6]: https://eprint.iacr.org/2015/525, https://eprint.iacr.org/2019/1201
[7]: https://eprint.iacr.org/2022/509
[8]: https://eprint.iacr.org/2022/1362
[9]: https://github.com/hyperledger/anoncreds-v2-rs

Our overall goal is identical to what Manu has expressed here -- being able
to have a single credential with multiple signatures suitable for
presentation in different scenarios -- and that is easy to use from both a
developer and end-user perspective.

If anyone is interested in learning more or collaborating, please reach out.