Versions Compared

Old Version 1

changes.mady.by.user Stephen Curran

Saved on

compared with

New Version Current

changes.mady.by.user Ry Jones

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: add recording

Summary

Excerpt
  • Presentation Data Models
  • Predicate Types
  • Open Discussion

...

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>

...

Agenda

  • Proposed Presentation Data Models, based on what Mike Lodder has presented and documented here: https://hackmd.io/ZlsnLoclSveePJOZljgMfA
  • Review of PredicatesFor each – what Schema Claim Types can/must be used? Predicate Types:
    • 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)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

...

  • 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

Recording