/
2024-02-05 AnonCreds Working Group Meeting

2024-02-05 AnonCreds Working Group Meeting

Feb 05, 2024

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:

Extracted from the recording – Credo demo of AnonCreds in W3C VCDM format:

A demo of the Credo Framework (https://github.com/openwallet-foundation/credo-ts) issuing, holding, presenting and verifying AnonCreds Verifiable Credentials that are exchanged in the W3C Verifiable Credential Data Model using Data Integrity proofs. Presented at the AnonCreds Working Group Meeting by Animo Solutions (https://animo.tech/).



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.

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