...
Excerpt |
---|
|
Time: 7:00 Pacific / 16:00 Central Europe
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.
...
- AnonCreds in W3C Format - Status/Updates
- Demo (recording here) from Martin Auer of Animo Solutions
- Proposal to use new format for issuing: https://github.com/hyperledger/aries-rfcs/pull/809 (based on https://hackmd.io/JEIOxf_ETnaX33kTIu7YJw?view)
- Test Vectors Repo: https://github.com/TimoGlastra/anoncreds-w3c-test-vectors
- Attachment Format to use for Present Proof will be DIF Presentation Exchange - Aries RFC 0510
- ACA-Py work design document in repo
- AnonCreds RS PRs
- AnonCreds V2 Objects - Presentation from last meeting, evolved
- How does ALLOSAUR Revocation work? High level – not at the crypto. More about what data gets generated (inputs, size) and shared between participants.
- Data:
- Accumulator – fixed sized digest regardless of the number of credentials - public
- Elements of the set – one per credential – could be whatever you want (e.g. Hashed UUIDs) – what the holder gets associated with their credential.
- Must be tracked by the issuer and associated with the holder – this is what gets revoked – this element is removed from the accumulator.
- The "witness" (aka revocation handle, revocation signature) – known only to the holder, created by the issuer. Needed, with the element, to produce the holder's NRP (Non-Revocation Proof).
- The key pair used for managing the revocation registry. Verifiers must have the accumulator (that the holder used) and the public key.
- Issuer and Revocation Manager relationship
- Could be one and the same, but could be separate.
- Separated out "thresholdizing the private key of the revocation set" – if different than the issuer, the private key can be split across revocation manager (called MPC – multi-party computation).
- Accumulator must change when elements are removed.
- Issuer notifies the revocation managers of elements that are removed.
- Requires some part of the private key to do the removals.
- Issuer setup
- Decides on the element construction – e.g. a hashed UUID
- Requests a new revocation manager create a new registry – new key is created.
- Revocation managers use a distributed key generation (DKG) – where it may be just one.
- Publishes the public key
- Publishes the accumulator
- Issuer credential issuance
- Data to holder
- Data to revocation manager
- Issuer generates an element
- Element sends element to revocation manager
- Issuer requests from the revocation manager the witness for a given element, forwards this to the holder.
- Data to holder
- Signed credential, element, witness, accumulator
- Issuer revocation
- Authorization, element(s) being revoked.
- Revocation manager returns the new accumulator
- Issuer publishes the new accumulator
- Verifier presentation request
- Verifier gets accumulator from a public location (could get multiple), and public key
- Allows the verifier to define how fresh of a revocation they want
- Sends those to the holder.
- Data to revocation manager
- Verifier gets accumulator from a public location (could get multiple), and public key
- Holder and revocation manager for presentation – request data, response data
- Holder checks if they already have the data
- for that accumulator – generates the NRP using the element and witness
- If not, holder contacts (somehow) revocation manager to get a new witness
- Sends Schmir's Secret split of their element to the revocation managers and requests their witness – could send multiple splits to the same revocation manager – assembles resulting shares
- Could do this with a single revocation manager — split element
- Sends Schmir's Secret split of their element to the revocation managers and requests their witness – could send multiple splits to the same revocation manager – assembles resulting shares
- Holder to verifier non-revocation proof data
- NRP that is generated using the element and witness, accumulator
- Verifier and revocation manager – request data, response data
- Verifier has already retrieved the accumulator or the verifier confirms the accumulator that the holder gave them.
- Data:
- How does Verifiable Encryption work?
- Issuer setup
- Issue process
- Holder/Verifier presentation request / presentation
- Decryption process
- How does ALLOSAUR Revocation work? High level – not at the crypto. More about what data gets generated (inputs, size) and shared between participants.
- Open Discussion
- Workshop This Thurs Feb 8: Decentralized Identity + Interoperability: Connecting Credo (Agent Framework Javascript) with Hyperledger Besu, Cardano, Cheqd, Hyperledger AnonCreds, and OIDC4VCFuture Calls
- Workshop Weds April 24th: Zero Knowledge Proofs and ZK Programming in Blockchain Application Development
...