Page Comparison

Summary

Recording of Call: dummyfile.txt

• Part 1: dummyfile.txt
• Part 2: dummyfile.txt 

Notices: 

This specification creating group operates under the Linux Foundation Community Specification License v1.0.

Meeting Attendees

Stephen Curran (BC Gov / Cloud Compass Computing Inc.) <swcurran@cloudcompass.ca>

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

Lance Byrd (RootsID) <lance.byrd@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

...

• Presentation from Mike Lodder
• Open PRs Review, Open Issues Review
• 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.
• Open PRs Review, Open Issues Review
• 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
    • • .
• 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

...