Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

Summary

Excerpt
  • Update on AnonCreds Happenings
  • Discussion: Flexibility Modularity in the Underlying Signature Schemes - Mike Lodder
  • Understandable names for schema types
  • Presentation Data Models
  • Open Discussion

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

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>

...

...

  • Update on AnonCreds Happenings
  • Discussion: Flexibility 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?
    Proposed Presentation Data Models, based on what Mike Lodder has presented and documented here: https://hackmd.io/ZlsnLoclSveePJOZljgMfA
    • 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?

...