Page History

...

Recording of Call:   20230123 AnonCreds Specification User Group Meeting.mp4

Notices: 

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

...

Rodolfo Miranda (RootsID)<rodolfo.miranda@rootsid.com>

Matteo Midena  (Monokee) <matteo.midena@monokee.com>

Lance Byrd (RootsID) <lance.byrd@rootsid.com>

Related Repositories:

• AnonCreds 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
  • Ledger Agnostic AnonCreds Project Page: https://github.com/orgs/hyperledger/projects/16

...

• Welcome and Introductions
• Announcements:
  • Request for a host for the meeting next week – Timo
• Updates the Agenda

Agenda

Open Issue

• PRs for review and merging
  • Prover DID PR needs more work. From Berend: The prover_id gets hashed with, optionally, the revocation index in there as well
• Issues to Discuss
  • issuance_by_* handling
  • Revocation Interval
    
    • To set "validation" to true/false based on the RevRegEntry timestamp in relation to the revocation interval?  Presentation 
    • Key points:
      • 1. an RevRegEntry is “current” from the time it is written, to the time of the next RevRegEntry
      • 2. “within the interval” is based on when a RevRegEntry is “current” (see 1.), not its timestamp.
      • 3. AnonCreds should calculate “within interval” (using 2.) and mark verification true if the RevRegEntry used by the Prover is within the interval, else false.
        • However, this is different than what is done today – which is to just return the status of the Non-Revocation Proof based on whatever RevRegEntry/timestamp the Holder used.
        • Danger:
          • False-Negatives: If a strict "timestamp used is between from, to" and not based on when a RevReg is "current" (per 2.), we will get "not verified" incorrectly.
          • False-Positives: If we don't do any checking of the timestamp and the interval, the holder could incorrectly use an old RevRegEntry.
      • 4. General point: AnonCreds should return both a summary (true/false) and if false, additional data about why it was false.
    • Next steps:
      • Consider options and discuss again next week.
  • Issue #137 added regarding further investigation into what happens to the issuance data flow nonce(s) by Belsy
• Do we need an anoncreds-indy-rs repo for the legacy indy and did:indy AnonCreds methods?
  • Briefly discussed.
  • Decision: No extra repo is needed. An Aries (or other tech stack) implementation (e.g., ACA-Py, AFJ) should implement the AnonCreds methods required.
    • Likely we need more discussion of this, and to put this into spec.
• Checkin: anoncreds-rs implementation progress, requests
• Open Discussion

...