2024-11-11 AnonCreds Working Group Meeting

Summary

• Revocation Scheme Design – based on ALLOSAUR and cryptographic accumulators
• Status update on Revocation Manager
• IIW Presentation from Google about "ZKmdoc" – ZK circuit based approach to privacy-preserving mDocs
• Open Discussion

Time: 7:00 Pacific / 16:00 Central Europe

Call Link: https://zoom.us/j/97954159540?pwd=WWk3WmQ3MVh1SXBYZGVreGl0QllGdz09

Recording:

Notices: 

This specification creating group operates under the Linux Foundation Community Specification License v1.0.

Meeting Attendees

• Stephen Curran (BC Gov / Cloud Compass Computing Inc.) <swcurran@cloudcompass.ca>

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
• Announcements:
• Any updates to the Agenda?

Agenda

• A proposed revocation scheme – based on ALLOSAUR and cryptographic accumulators
  • Updates needed to the document:
    • During issuance, the Issuer must contact the Revocation Manager (RM) and get back the witnesses for the elements (requires access to the public key)
    • For revocation batches, the Issuer provides the GUIDs of the revoked credential to the RM and gets back a "delta" for each. This is what the issuer publishes to the "revocations" file.
      • The "deltas" are 48 bytes of data – 64 characters base64 encoded. Thus, the "revocations" file is 4x the size previously noted.
    • For the performance of the Witness Server
      • Assume it takes about 500ms to apply 10000 deltas or 20k/second (where there is 1 delta per revocation of a credential).
      • This is a parallelizeable math operation – it can be parallelized to the number of threads supported by a processor - up to hundreds on a cloud-based server.
      • We would not expect batch sizes above a couple of thousand a day for large volume issuers (millions of credentials in a revocation registry).
      • As such, the bottleneck of the processing is more likely the retrieving and updating of the holder witnesses to storage vs. the witness updating.
• Status update on the Revocation Manager Project
• Not discussed: IIW Presentation from Google about "ZKmdoc" – ZK circuit-based approach to privacy-preserving mDocs
• Open Discussion

To Dos:

Action items