Summary
- Revocation Registry List Data Model
- Validation of Identifiers - specification vs. implementation
- What is the "prover_did" data item?
- Checkin: anoncreds-rs implementation progress, requests
- 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>
Lance Byrd (RootsID) <lance.byrd@rootsid.com>
Steve McCown (Anonyome Labs) <smccown@anonyome.com>
Rodolfo Miranda (RootsID)<rodolfo.miranda@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
Meeting Preliminaries:
- Welcome and Introductions
- Announcements:
- Latex in the specification now enabled.
- Meetings: Last one for 2022 next week, then 2 weeks hiatus.
- First 2023 meeting: 2023.01.09
- Updates the Agenda
Agenda
Open Issue
- Issue 108: Revocation Registry List Data Model
- Issue 111: Validation of Identifiers - specification vs. implementation
- Issue 107: What is the "prover_did" data item?
- Issue 102: AnonCreds object signed by the key of the publisher
- Which is related to Issue 74: issuer_did and schema_issuer_did should be IDs?
- Checkin: anoncreds-rs implementation progress, requests
- Open Discussion
Future Calls
- No topics pending
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
- Ankur to add paragraph about philosophy of the AnonCreds API, styles
- Review the Issuing and Presentation sections to exclude Legacy Indy impacts, and to formalize the Abstract API for writing/reading published objects
- Cred Def Generation + PRIVATE_CRED_DEF -- non revocation, and plus revocation
- Normative/Non-normative references
- Collect from documents mentioned below (under action items) and from previous meeting
Action items
- Request from Stephen Curran -- I'd like to go through the
presentationsection of the spec to convert the specific implementation calls (e.g.indy_prover_...and the like) into content to be more about the data objects passed into AnonCreds/returned from AnonCreds for processing events. - Suggestion made and supported that the group request to provide a presentation about AnonCreds to the W3C VC Working Group about the formatting of AnonCreds verifiable credential and presentation in W3C format and the processing implied.
- 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: