You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 5 Current »

Summary

  • AnonCreds in W3C Format - Status Update / Issues - Demo
  • AnonCreds v2 Objects – Review, suggestions – especially ALLOSAUR revocation, verifiable encryption, and (perhaps) other advanced ZKP capabilities
  • 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.

cifi

Hyperledger is committed to creating a safe and welcoming

community for all. For more information

please visit the Hyperledger Code of Conduct.

Meeting Attendees

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


Related Specifications and Repositories:

Meeting Preliminaries:

  • Welcome and Introductions
  • Announcements:
  • Any updates to the Agenda?

Agenda

  • AnonCreds in W3C Format - Status/Updates
  • 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
        • 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.
      • 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
      • 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.
    • How does Verifiable Encryption work?
      • Issuer setup
      • Issue process
      • Holder/Verifier presentation request / presentation
      • Decryption process
  • Open Discussion

To Dos:

Action items


W3C AnonCreds + AFJ Demo




















  • No labels