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

Summary

Presentation Data Models
Predicate Types
Open Discussion

Recording of Call:

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>

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:
Updates to the Agenda?

Agenda

Proposed Presentation Data Models, based on what Mike Lodder has presented and documented here: https://hackmd.io/ZlsnLoclSveePJOZljgMfA
Review of Predicate Types:
- Hide signature – proof of signature (unlinkable)
- Hide attribute - reveal or hide - Selective Disclosure
- Presentation Request
  - List of signatures – one per source credential to be included, with a list of attributes to revealed.
    - Likely retains the same restrictions as AnonCreds v1.0 (8 items on Schema, CredDef and Attributes)
      - Includes support for both identifying the issuer or not
        When not identifying the issuer, the verifier MUST decide after receiving the credential if they "trust the issuer", since anyone can be an issuer for a given type of schema.
        Example: Verifier accepts a "diploma" credential for any issuer, and then checks actual issuer against a trusted list.
    - Need to define how revocation comes into play, without the confusion created in AnonCreds v1.0 of using the "from-to" range.
    - To Do:
      - Enable supporting a higher level concept of accepting one of N presentation requests
      - Mapping this presentation request to the DIF Presentation Exchange data model, if possible.
  - ZKP-based proofs on unrevealed attributes:
    - Link Secret
      - Same as in AnonCreds v1.0, but accessible to the Issuer to define for a given schema.
    - Range Proof
      - Extends the current AnonCreds v1.0 predicates with additional support for negative integers and ranges.
    - Equality between attributes in the same or different credentials
      - For example, that the last_name in different credentials are the same.
    - Membership/Non-Membership
      - Based on the enumerated set of attribute values in the credential schema, the verifier calculates an accumulator generated by a subset of the enumerated values.
      - The holder can prove if their attribute value contributes (or not) to the accumulator.
      - Example: Prove that the holder's "State" attribute is one of a list of 22 States defined by the verifier. Can also proof set non-membership, e.g., that the holders attribute is not one in a list defined by the verifier.
      - Note: The verifier calculates and shares only the accumulator, not the set of values. Given the accumulator, the holder can calculate if their attribute is in/not in the set before sharing the presentation.
    - Domain
      - Given the same verifier inputs across presentation requests, the holder shares an unrevealed value that is consistent across presentation requests.
      - Example: A driver can share their Driver's License as a unique identifier multiple times to a verifier, and the verifier gets a consistent, unique identifier from each presentation, but not the Driver's License itself. Another verifier that makes a similar request also gets a consistent, unique identifier, but a different one from other verifiers.
      - Note: The holder can detect if two verifiers try to use the same blinding factors to try to get a correlatable identifier.
    - Verifiable Encryption
      - The verifier provides an encryption public key (or a link to an encryption public key) that the holder uses to share an encrypted data value. The value is blinded for the verifier, but can be decrypted by the holder of the corresponding private encryption key.
      - A holder encrypts a Credit Card number using the public key of the Credit Card company. The verifier cannot see the Credit Card number, but can share the value with the credit card company who can decrypt it.
Schema Claim Type:
- Would it make sense defining date related schema claim types that are especially useful to use in ZKP predicates?
  - "iso860_date" – encodes to dateint e.g., 2023.06.26 is 20230626
  - "iso860_datetime" - encodes to Unix Time e.g., seconds since Jan 1, 1970

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?