2024-02-12 AnonCreds Working Group Meeting

Owned by Stephen Curran
Last updated: Feb 12, 2024
3 min read

Summary

  • AnonCreds in W3C Format - Status Update / Issues
  • AnonCreds 0.2.0 Release – contents
  • AnonCreds Release 1.0.0
  • AnonCreds v2 ZKP Capabilities – verifiable encryption, equality proofs and domain proofs
  • Open Discussion

Time: 7:00 Pacific / 16:00 Central Europe
Call Link: https://zoom.us/j/97954159540?pwd=WWk3WmQ3MVh1SXBYZGVreGl0QllGdz09

Recording:

Notices: 

This specification creating group operates under the Linux Foundation Community Specification License v1.0.

cifi

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>

Steve McCown (Anonyome Labs) <smccown@anonyome.com>


Related Specifications and Repositories:

Meeting Preliminaries:

Agenda

  • AnonCreds in W3C Format - Status/Updates
  • Recent updates to AnonCreds RS – 0.2.0 release
    • When AnonCreds v1.0 1.0.0?
  • AnonCreds V2 ZKP Capabilities
    • Adding BBS+ to the library?
      • Extraction layer – abstracting other signatures, once done, adding BBS+ available.
    • Missing Object – revocation registry
      • Verifying key (96) and accumulator (48) – VK could be the identifier.
      • Definition - not needed
      • State - published on every accumulator update
    • How does Verifiable Encryption work?
      • Can be done by any party – need a BLS key pair - issuer, auditor, etc.
      • Issuer setup – anything? Encoding types?
        • Public key has to be published somewhere – most likely the CredDef,
        • A "message_generator" - point on the curve, like the public key – could use this to tie it down to a specific field.
      • Issue process
        • Nothing is done with VE at issuance time
        • Can be used with any claim
          • Could be used for specific values, e.g., Credit Card Number
          • But not defined apriori
          • Could use for a unique value – e.g. the revocation key
      • Verifier presentation request
        • Please give me a VE about a certain claim – reference to the two public data items (generator, pubkey), reference to attribute
      • Holder
        • Generates the encrypted value (verifiable cyphertext). Will be unique because of the nonce from the verifier.
      • Decryption process
        • Pass cyphertext (nonce, generator is embedded in cyphertext) to someone that knows the private key – decrypt to get the claim
    • Equality proofs – claims across two source verifiable credentials
      • Could be in the same credential 
      • Statement ID, List/Map of statement ID, claim ID.
      • Holder:
        • Creates a proof statement based on input of the claims
      • Verifier:
        • Verification of the proof and data
      • AnonCreds v1 aggregate – called "challenge" right now.
        • All of the proofs were generated by one holder
        • A signature over all of the proofs knew the raw data.
        • Not associated with the link secret in v1
          • In v1, there was an equality proof
        • Proofs that the data was fresh – e.g. used the same nonce in all of the proofs
          • In example – proof request ID is the nonce – everything is included in the aggregate proof signature.
    • Domain proofs (called a Commitment in V2) – consistent identifiers for a verifier – different across different verifiers
      • Issuer setup?
        • None
      • Issue process?
        • None
      • Verifier presentation request?
        • Creates two values – message and blinder generators - passed in the presentation request applied to a specific claim
        • Always use the same generators
      • Holder presentation process
        • Same as verifiable encryption – no decryption key
      • Verifier gets a consistent value from the holder
  • Question – call home for revocation
    • Does the issuer know who is calling home? No... (smile)
    • Trade-off – massive list, holder tells verifier which entry they are
    • Mitigate:
      • Get the latest state somehow.
      • Anonymous Revocation Handle Update - Call home – get me an update so I can proof a proof.
        • I have a credential.
        • Verifier to holder: Prove revoked as of this accumulator.
        • Holder to issuer: Give me an up to date witness for the accumulator – issuer does not know who is asking.
          • Holder – passes signature proof (I have a valid credential) – optional, accumulator, N shares of their element.
            • Issuer returns shares of the result. 
          • If revoked – not useful.
          • If never issued a credential – not useful.
  • Claim Schema format
    • Default encoding if no other information?  E.g. if just the name is given.
      • Dynamic encoding using AnonCreds v1 rules?  Notably: "If integer or integerString, then integer, else stringified and hashed"
    • link_secret automatically added as in AnonCreds v1?
    • Externalized set for list of set members
    • Date as ISO Date and encoded as Integer Date
    • DateTime as ISO Date and encoded as Unix Time
    • Research – what can be derived from JSON-LD information?
  • Open Discussion

To Dos:

Action items