Summary

Reviewing the proposed data models for AnonCreds v2.0 - https://hackmd.io/ZlsnLoclSveePJOZljgMfA
Revocation using zk-SAM
Open Discussion

Recording of Call: dummyfile.txt

Notices:

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

	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>

Steve McCown (Anonyome Labs) <smccown@anonyome.com>

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:
- AnonCreds Workshop presented by Hyperledger is planned for May 31, 2023, 8:00 Pacific / 17:00 Central Europe. Details to be shared.
- I'll be talking at the Linux Foundation Open Source Summit, Metaverse Conference about Hyperledger AnonCreds and ZKPs.
Updates to the Agenda?

Agenda

Proposed data models discussion given what Mike Lodder has presented and documented here: https://hackmd.io/ZlsnLoclSveePJOZljgMfA
- Issuing AnonCreds v1.0:
  - Schema – simple list of attribute names, schema name, version
    - Attribute type is dynamically implied by the data in the credential – string or integer
  - Credential Definition – a signing key for each attribute, an extra field that is the link secret
  - Credential
    - Raw and encoded claims
    - Signature is added
- Issuing v2.0
  - From document – items:
    - Claims – Schema, Validators, Data
    - Credential Schema, Credential Definition
    - Credential
  - Proposal that types are defined in the AnonCreds specification
  - Claims Schema Repository
    - Name, ID, type, validators
    - QUESTION: Do we want to add the complexity/overhead of adding this element vs. keeping all of the information encapsulated in the Credential Schema Object
      - Could have an optional "ClaimsSchemaId" as optional in the "Credential Schema Object":
        When included, only the Claims Name/ID need be included in the Credential Schema Object
        When not included, the full Claims information (type, validators) must be included in the Credential Schema Object.
  - Credential Schema Object:
    - Name, Description (should also have version?)
    - Blindly Signed Claims Schema
      - Attribute name/ID from Claims Schema
    - Ordered List: Claims Schema
      - Attribute name/ID from Claims Schema, or
      - Attribute Name, ID, type, validators
  - Credential Definition Object
    - Keys necessary to sign credentials
      - Parameters per attribute – could be derived when using some signature schemes
    - ID of Schema Object
    - Revocation Registry – keys
  - Credential:
    - Claims
    - Signature
    - Revocation Registry Handle
    - Credential Definition ID
- Signature Schemes
  - CL
  - ~~BLS~~ - doesn't support selective disclosure
  - BBS+ - IETF submitted version can be used
    - PQ unlikely – none known at this time.
  - PS - Mike, et. al (potentially including "S" in "PS") is taking this to IETF
    - Has a post-quantum version, but slower and bigger
      - Calculation for 5 claims – in the Credential Definition: Public Key 912 bytes, PQ version: 6KB, increasing linearly (6x bigger)
        Proof: 300-400 bytes, PQ version: 24kb (50x bigger)
      - Could be public key could be fixed size 192b and then derive a per claim data parameter (tradeoff size vs. time)

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?

Browser not supported