2023-08-21 AnonCreds v2.0 Working Group Meeting

Owned by Stephen Curran
Last updated: Aug 21, 2023
2 min read

Summary

  • AnonCreds v1.0 Spec PRs – Cryptographic Elements
  • Open Discussion

Recording of Call:  

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>


Related Repositories:

Goals of the Working Group:

The goal of AnonCreds v2.0 is to retain and extend the privacy-preserving features of AnonCreds v1.0, while improving capabilities, performance, extensibility, and security.

Meeting Preliminaries:

  • Welcome and Introductions
  • Announcements:
  • Updates to the Agenda?
    • Patrik: Revocation lists in Anoncreds spec
      • revocation lists in relation to indy "from, to" intervals
      • Anoncreds registry specification for indy
      • Anoncreds 2.0 revocation

Agenda

  • PRs from AnonCreds v1.0 Spec.
    • Clarification about nonces used in the issue credential process:
      • Nonces are used to prevent replay attacks, requiring the other party to use the nonce in proofs, thus requiring that they be calculated in real time – and preventing the reuse of a previously calculated proof. 
      • Issuer generates nonce n0 and sends it to the holder in OfferCredential data structure.
      • Holder:
        • Uses nonce n0 in creating the blinded_link_secret_correctness_proof that proves the holder knows the link secret that was used to create the blinded link secret.
        • Generates nonce n1.
        • Sends both the  blinded_link_secret_correctness_proof and n1 to the issuer in the RequestCredential data structure.
      • Issuer:
        • Uses nonce n0 and the blinded_link_secret_correctness_proof to verify the proof.
        • Uses the nonce n1 when creating the signature_correctness_proof that proves the issuer knows the private keys used to generate the signature over the credential (didn't just send a previously signed credential).
        • Sends the data, signature, and signature_correctness_proof to the holder.
      • Holder
        • Uses nonce n1 to verify the signature_correctness_proof
        • Accepts the credential from the issuer as valid.
  • Open Discussion

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?

To Dos:

Schema Claim Type:

  • Would it make sense defining encodings for 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
  • Yes – these would be "numbers" by type, but with special encoding handling.

Action items