2024-12-09 AnonCreds Working Group Meeting

Summary

• Revocation Scheme Design – based on ALLOSAUR and cryptographic accumulators
• Status update on Revocation Manager
• Getting to "AnonCredsBBS" – How Can We Make That Happen?
• 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 GUID (16 Characters) + a literal dash ("-") + a "delta" which are 2 chunks of data, one 48, the other 32 bytes.  That is (I think...) 100 characters base64 encoded. Thus, the "revocations" file is 118 characters per revocation, plus JSON overhead and the timestamp.
    • 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 parallel-izeable 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
• Open Discussion

To Dos:

Action items