2024-03-18 AnonCreds Working Group Meeting

Owned by Stephen Curran
Last updated: Mar 18, 2024
3 min read

Summary

  • Status Updates on AnonCreds in W3C VCDM Format projects
  • Revocation Manager for ALLOSAUR and AnonCreds – Design
  • Schema Object for Complex JSON Objects – Discussion
  • 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:

Agenda

  • AnonCreds in W3C VCDM Format - Status/Updates
  • ALLOSAUR/AnonCreds Revocation Manager Component – what is it, design?  ALLOSAUR/AnonCreds Credential Status Manager (reflects 
    • Presentation
    • Hyperledger Mentorship Program
    • Proposed Hyperledger Mentorship project: AnonCreds Revocation Manager Component Implementation
    • On the Ledger:
      • RevRegDef: ID, Public Key, Accumulator, RM URLs
      • RevRegEntry: Accumulator (no list of changed status)
    • Is this NIST-compliant?
      • NIST has no approved pairing cryptography libraries, and this is based on pairing cryptography
      • Uses BLS12381 – which is used by many of the blockchains, BBS+, etc. – stronger curve – zCash and others
  • Update on the Hyperledger Labs Agora Libraries
  • PS vs. BBS+ Attributes
    • Aside: Rumour has it that a PS key size changes based on number of attributes to sign. If so, does that impact support for arrays in complex JSON?
      • PS must know the maximum number of claims you are going to sign at credential definition time.  Tradeoff of key size vs. number of claims.
      • PS vs. BBS+ relates to threshold signing.
      • PS has stronger security proofs.
      • PS – smaller and faster to generate
    • Nice point – could choose based on use case.
  • Complex JSON in AnonCreds – ideas for the Schema Object
    • Thinking about AnonCreds V2 with complex JSON, and what the Schema would look like.
    • In V2, there are is metadata per VC attribute that provides input into the encoding for the element -- e.g., it's a string, an integer, an integer range, a date, an enumerated set, scalar (e.g. link secret).
    • Example of a simple schema to show the metadata: https://github.com/swcurran/anoncreds-v2-rs/blob/samples/examples/schema-with-linked-secret.json
    • Question – how do we manage the schema when we need to support complex JSON (structures, arrays). 
      • Idea 1: Use JSON.Path so we are back to a list of attributes
        • Schema is a flat list like we have in AnonCreds v1, but attribute names are in JSON Path format. 
        • Metadata is attached to each attribute in the (flat) list.
      • Idea 2: Use JSON-LD 
        • How much would JSON-LD help with this?
          • Probably not much
        • Is there already enough data to tell us much of those things?
          • I would guess not. It could have a lot of it, but not all that we need.
          • Completely dependent on the use case – definitely not guaranteed. Must be able to supplement it.
        • What tools are there to see for a given JSON-LD document what attributes we know about each attribute?
          • Tools are available.
        • Would it make sense to use JSON-LD and supplement attributes as needed?
          • Question for the JSON-LD crowd.
      • Idea 3: Combine the two
        • Use JSON-LD for much of the data
        • Use JSON.PATH to add additional metadata when needed to specific items.
      • Idea 4: Pure JSON-LD, adding new "features" to get support for what we need
        • Don't really know what this entails...
  • Open Discussion

To Dos:

Action items