Summary
| Excerpt |
|---|
|
...
Call Link: https://zoom.us/j/97954159540?pwd=WWk3WmQ3MVh1SXBYZGVreGl0QllGdz09
Recording:
| Widget Connector | ||
|---|---|---|
|
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. |
|---|
Meeting Attendees
- Stephen Curran (BC Gov / Cloud Compass Computing Inc.) <swcurran@cloudcompass.ca>
...
- 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 bytes of data – 64 , the other 32 bytes. That is (I think...) 100 characters base64 encoded. Thus, the "revocations" file is 71 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.
- Updates needed to the document:
- Status update on the Revocation Manager Project
- Open Discussion
...