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

Summary

Recording of Call:  

Notices: 

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

Meeting Attendees

@Stephen Curran (BC Gov / Cloud Compass Computing Inc.) <swcurran@cloudcompass.ca>

Related Repositories:

• Mike Lodder's proposed Data Models: https://hackmd.io/ZlsnLoclSveePJOZljgMfA

• AnonCreds v2.0 Specification Repository: https://github.com/hyperledger/anoncreds-spec-v2/

• AnonCreds v1.0 Specification: https://hyperledger.github.io/anoncreds-spec/

• AnonCreds Methods Registry: https://hyperledger.github.io/anoncreds-methods-registry

• AnonCreds Rust Open Source Code: https://github.com/hyperledger/anoncreds-rs

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