...
Excerpt |
---|
|
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.
...
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
...