2022-12-19 AnonCreds Specification Working Group Meeting
Summary
Issue 102: AnonCreds object signed by the key of the publisher
Latest with AnonCreds W3C Verifiable Credentials Data Model Standard
Update on prover_did?
Progress on the anoncreds_rs implementation
Open Discussion
Recording of Call: dummyfile.txt
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>
@Rodolfo Miranda (RootsID)<rodolfo.miranda@rootsid.com>
@Steve McCown (Anonyome Labs)<smccown@anonyome.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:
Next meeting: 2023.01.09
Updates the Agenda
Agenda
Open Issue
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?
Action: Add issuerId and schemaIssuerId to the appropriate objects; add a task to the anoncreds_rs to do the same.
Latest on the AnonCreds W3C Verifiable Credentials Data Model Standard
Is it wrong to format an AnonCreds credential in the W3C Format?
Any update on what "prover_did" is used for during AnonCreds processing. Notably, does the value require any special characteristics when it is used in the AnonCreds code?
Any insight on why it was added in the first place?
If we were to deprecate it as an input, would we need to use something else to replace it in the AnonCreds code?
Help with dependabot pull request: 113
Checkin: anoncreds-rs implementation progress, requests
Open Discussion
Future Calls
To Dos:
Issue to be added and further investigation into what happens to the nonce(s) by Belsy.
Updates to the spec. re: revocation data model, prover_did and nonces uses
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.
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 meetings
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: