2022-12-05 AnonCreds Specification Working Group Meeting

Owned by Stephen Curran
Last updated: Dec 05, 2022
3 min read

Summary

  • Open Issues
  • Discussion of Mike Lodder's proposals from last week and paper posted this week
  • 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>

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

Steve McCown (Anonyome Labs) <smccown@anonyome.com>

Related Repositories:

Meeting Preliminaries:

  • Welcome and Introductions
  • Announcements:
  • Updates the Agenda

Agenda

  • Open PRs Review, Open Issues Review
  • Request for work on the specification – especially the cryptographic elements
  • Discussion of what an AnonCreds 2.0 might look like based on the work Mike has done.
  • Open Discussion

Future Calls

  • No topics pending

To Dos:

  • Issue #100: Clarifying if the holder is the software agent acting on behalf of an entity or the entity itself
    • Agreed to update the issue and specification with a change to the definition of "holder", "issuer" and "verifier" to mean that software that acts on behalf of the controller entity. Any examples where (for example) the term "holder" implies the person will be adjusted appropriately. Possibly, we will add another term, such as "holder-entity", etc. or "controller" to mean the entity for which the "holder" (etc.) on behalf.
  • 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
  • Revocation data elements -- definition
  • Normative/Non-normative references
    • Collect from documents mentioned below (under action items) and from previous meeting

Action items