Versions Compared

Key

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

...

Excerpt
  • Update on AnonCreds Happenings
  • Discussion: 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.

...

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

...