2023-06-12 AnonCreds v2.0 Working Group Meeting

Summary

Recording of Call:  https://youtu.be/qAkODMA3dgc

Notices: 

This specification creating group operates under the Linux Foundation Community Specification License v1.0.

Meeting Attendees

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

Related Repositories:

• Mike Lodder's proposed Data Models: https://hackmd.io/ZlsnLoclSveePJOZljgMfA

• AnonCreds v2.0 Specification Repository: https://github.com/hyperledger/anoncreds-spec-v2/

• AnonCreds v1.0 Specification: https://hyperledger.github.io/anoncreds-spec/

• AnonCreds Methods Registry: https://hyperledger.github.io/anoncreds-methods-registry

• AnonCreds Rust Open Source Code: https://github.com/hyperledger/anoncreds-rs

Goals of the Working Group:

The goal of AnonCreds v2.0 is to retain and extend the privacy-preserving features of AnonCreds v1.0, while improving capabilities, performance, extensibility, and security.

Meeting Preliminaries:

• Welcome and Introductions

• Announcements:

  • 2023.05.15 (this Thursday): Presentation: ZKPs – the High School Math Edition - @Stephen Curran at the Identity SIG Meeting

• Updates to the Agenda?

Agenda

• Update on AnonCreds Happenings

• Discussion: Modularity in the Underlying Signature Schemes - Mike Lodder

  • AnonCreds v2.0 could use one of four (CL, BLS, BBS, and PS) signatures schemes at the moment. How does that work?

  • As with CL Signatures, data is encoded as numbers

  • The additional Schema Claim data allows for "improved" encoding – e.g. zero centring integer data

  • The signature type and the Schema Claim data determine exactly what is needed per claim to enable comparable presentation ZKP capabilities.

    • These will have to be defined in the specification – e.g.

      • the requirements of the cryptography for the features, and,

      • for specific signatures to be supported (perhaps BBS+ and PS), the details of using those signatures

• Purposes/use cases for the Schema Types proposed for AnonCreds v2.0, with a goal of leading to some useful names for the different types:

  • Enumeration

    • Hashed

    • Numeric

    • Scalar

  • String

  • Unsigned Byte/Binary

    • Hashed: claim data is hashed before signing

    • Numeric: claim data is zero centered before signing

    • Scalar: claim data is already a cryptographic value. Equivalent to a null hash

• Predicates:

  • Hide signature – proof of signature (unlinkable)

  • Hide attribute - reveal or hide - Schnorr Proof

  • Set memberships, such as

    • Zip/postal Code

    • State

    • City

    • Accumulator

  • Commitment - same value

  • Range Proof

  • Verifiable Encryption

  • Commitment

  • Not discussed: Claim equality across credentials (e.g. proof that the claims in two credentials are the same without sharing the value).

Future Calls

• Collect some use case specific examples and continue the discussions:

  • Applying the data structures to a real use case or two

    • Take an existing AnonCreds Schema (maybe this) and Credential Definition (maybe this) and define what it would be using Mike's proposed data models.

      • Where would the data models exist, such as on ledger, in the AnonCreds specification?

  • What concrete uses other than link-secret is there for blinded data in a credential?

To Dos:

Action items