2022-11-21 AnonCreds Specification Working Group Meeting

Owned by Stephen Curran
Last updated: Nov 21, 2022
3 min read

Summary

  • IIW Update
  • PRs and Backwards Compatibility
  • Latest on AnonCreds in W3C VC Standard Data Model format
  • Open Issues
  • 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>

Alex Andrei(RootsID) <alex.andrei@rootsid.com>

Christian Bormann (Robert Bosch GmbH) <christiancarl.bormann@de.bosch.com>

Rodolfo Miranda (RootsID)<rodolfo.miranda@rootsid.com>

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



Related Repositories:

Meeting Preliminaries:

  • Welcome and Introductions
  • Announcements:
    • RootsID is working on deploying AnonCreds on the Cardano Network
  • Updates the Agenda

Agenda 

  • IIW Update
    • Session on Hyperledger AnonCreds
    • Discussions about JSON-LD usage
    • Lots of discussions of supporting AnonCreds in "other formats" – e.g. OWF, OID4VCs
    • BBS+ Predicates work that is happening - Dan Yamamoto
    • Aside: Mike Lodder presentation
  • 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.
  • Creating/sharing AnonCreds verifiable credential and presentation objects in W3C VC Data Model format
  • Open PRs Review, Open Issues Review
    • PR #80
      • Ready to merge – need Timo Glastrato resolve conflicts with the PR
    • 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.
    • Issue #84: Changing encoding to be in AnonCreds and NOT handled by the issuer
      • This issue has been referenced in the new "Issuance Update" PR that was submitted over the weekend.
  • Open Discussion

Future Calls

  • No topics pending

To Dos:

  • 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