Page History

...

• Welcome and Introductions
• Announcements:
• 2023.05.15 (this Thursday): Presentation: ZKPs – the High School Math Edition - Stephen Curran at the Identity SIG Meeting
• 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 PredicatesPredicate Types:
  For each – what Schema Claim Types can/must be used? 
  • 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
  • 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.
    Not discussed: Claim equality across credentials (e.g. proof that the claims in two credentials are the same without sharing the value)
• 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

...