2025-11-24 AnonCreds Working Group Meeting
Summary
Open Discussion
Time: 15:00 Pacific / 23:59 Central Europe
Call Link: https://zoom.us/j/92023385582?pwd=bb7CFdbibQKGTkqKnXzEi3xhbbi1du.1
Recording:
Notices:
This specification creating group operates under the Linux Foundation Community Specification License v1.0.
LF Decentralized Trust is committed to creating a safe and welcoming community for all. For more information please visit the LFDT Code of Conduct. |
|---|
Related Specifications and Repositories:
AnonCreds v1.0:
The v1.0 specification is published here: https://hyperledger.github.io/anoncreds-spec/
The Working Group uses this GitHub repository to manage the specification: https://github.com/hyperledger/anoncreds-spec
The AnonCreds Methods Registry: https://hyperledger.github.io/anoncreds-methods-registry
The v1.0 implementation in Rust is here: https://github.com/hyperledger/anoncreds-rs
The v1.0 implementation is dependent on this Rust CL Signatures implementation: https://github.com/hyperledger/anoncreds-clsignatures-rs
AnonCreds v2.0
The initial framework for the v2.0 specification repository is here: https://github.com/hyperledger/anoncreds-spec-v2
The v2.0 implementation in Rust is here: https://github.com/hyperledger/anoncreds-v2-rs
Underlying AnonCreds v2.0 are cryptographic libraries in Hyperledger Labs Agora
Meeting Preliminaries:
Welcome and Introductions
Any updates to the Agenda?
Agenda
European ZKPs efforts:
Longfellow ZK (Google/Matteo/abhi) and mDocs/mDL
Selective disclosure, PoP, unlinkability.
No revocation as yet.
Anja Lehmann – VISION paper – general modules.
BBS + Proof of Possession (PoP) via a ECDSA Proof bound to the BBS proof.
DockNetwork Crypto has this implemented in their library see this.
Holder generates key pair – ideally in hardware, but could be cloud service.
May prove to issuer that the public key is hardware bound, e.g. via Google/Apple Key Attestation proof.
Issuer signs and inserts the public key into the credential
Holder can generate a ZK PoP proving that a signature over verifier provided data uses the signed public key – without sharing the public key.
BBS + pseudonymous identifier
Enables verifiers to get a directed identifier, unique to each verifier, and suitable for account identification.
Technique allows holder to provide a “root” blinded identifier to the issuer that can be reused on reissuance – allowing the same pseudonymous identifiers to be generated after the loss of a wallet (assuming the “root” identifier was backed up/restored).
Technique also allows for the same root to be used for multiple pseudonymous identifiers to be generated per verifier so that the multiple accounts can be used that are rooted in the same verifiable credential without knowledge of the verifier. Used for example, for a personal and work account at an online retailer.
BBS + other ZK proofs – predicates, equality, verifiable encryption.
Work seems to be moving towards JSON Web Proofs as a credential format, rather than W3C VCDM. Simpler format, avoids the complexity of JSON-LD.
Open Discussion