Summary
- PRs
- issuance_by_* handling
- Revocation Interval
- Do we need an anoncreds-indy-rs repo for the legacy indy and did:indy AnonCreds methods?
- Progress on the anoncreds_rs implementation
- 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>
Rodolfo Miranda (RootsID)<rodolfo.miranda@rootsid.com>
Matteo Midena (Monokee) <matteo.midena@monokee.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
Meeting Preliminaries:
- Welcome and Introductions
- Announcements:
- Request for a host for the meeting next week
- Updates the Agenda
Agenda
Open Issue
- PRs for review and merging
- 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
- 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?
- Checkin: anoncreds-rs implementation progress, requests
- Open Discussion
Future Calls
To Dos:
- Backwards Compatibility
- PRs in (#82, #105) that seem to change public data structures – ones that are handled outside of AnonCreds and/or by two or more participants (issuer, holder, verifier)
- We want to retain compatibility with existing data – credentials that have been issued and the published AnonCreds objects on which they rely.
- That extends to business logic – e.g. the handling of the objects not just by AnonCreds, AnonCreds Methods and Aries Frameworks, but also by business applications built on Aries.
- Suggestion:
- Include in the specification a statement about backward compatibility
- Perhaps this is what Ankur had planned to do?
- Formalize what data structures will be expected by AnonCreds
- This is being done throughout the specification and verified against the current implementation.
- As needed support sending and receiving data in "old" and "new" formats, but (for now) always sending "old" formats.
- TBD if there are any such cases.
- Include in the specification a statement about backward compatibility
Action items
- Adding support for W3C Format AnonCreds to the anoncreds implementation and the spec.
- Issue -- should "encoded" generation be handled by the Issuer or within AnonCreds?
- Formalize the encoding in the specification
- Transition to "encoding in AnonCreds" ASAP
- Links to be referenced in the spec and used where needed: