Page History

Zoom Link: https://us02web.zoom.us/j/85188125213?pwd=UHRUVlgweFJ0T0g4SVdDUytYSkxJUT09

Summary

Recording of Call: 20221107 AnonCreds Rust Working Group Call Recording.mp4

Notices: 

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

Welcome and Introductions

Attendees

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

Related Calls and Announcements

• Proposal: Start an AnonCreds Code Development Working Group driven by this Roadmap

...

Timo Glastra (Timo Glastra) <timo@animo.id>

Victor Martinez Jurado (Víctor Martínez) <victor.martinez@sicpa.com>

Darko Kulic (Darko Kulic) <darko.kulic@sicpa.com>

Lance Byrd (RootsID) <lance.byrd@rootsid.com>

AnonCreds 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

Meeting Preliminaries:

• Welcome and Introductions
• Announcements:
  • IIW -- Nov 15-17, Mountain View, Calif.
    • Suggestions for what to do at IIW
    • Ledger-agnostic AnonCreds
    AnonCreds in W3C Format
    • Sam:
      • Governance, Aries for other than AnonCreds
• Updates Updates to the Agenda

Agenda 

• Logos – selecting the Hyperledger AnonCreds project logo. Options.
• Transition into Hyperledger AnonCreds
  • Tasks in moving this group into Hyperledger
  • Move the repos from this group into HL, get new URL
  • Create new replacement repos in this organization and publish a redirector to the new location
  • PR to update the references to the home of the specifications as being in Hyperledger
  • PR to review and update the Community License V1.0 documents.
  • Create a Meetings page off the Hyperledger AnonCreds home page
  • Move all meeting agendas to the new Meetings page
  • All the other work in establishing the Hyperledger AnonCreds project: Checklist
• RevReg Object updates -- enabling AnonCreds Methods to support both deltas and "full state" RevReg storage Timo Glastra
• Creating/sharing AnonCreds verifiable credential and presentation objects in W3C VC Data Model format
  • Repository with code: andrewwhitehead/anoncreds-w3c-mapping
• Open PRs Review, Open Issues Review
  • Issue #86: Should we allow the possibility of an Issuer using only a subset of a schema?
  • Issue #92: Does AnonCreds support in the Presentation Request / Presentation flow the concept of presenting any one of N verifiable credentials?
• Open Discussion

Future Calls

• None pending

To Dos:

• Request from Stephen Curran -- I'd like to go through the presentation section 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.
• 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

...

• Formalize the encoding in the specification
• Transition to "encoding in AnonCreds" ASAP

...

• From Will Abramson : https://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.186.5994&rep=rep1&type=pdf
• From Will Abramson : https://github.com/hyperledger/indy-hipe/blob/c761c583b1e01c1e9d3ceda2b03b35336fdc8cc1/text/anoncreds-protocol/README.md

...

• Ledger Agnostic AnonCreds Project Plan
  • Discussed, add a couple of things. Some items were claimed.
• Backwards compatibility testing
  • Tasks created and taken by Timo to look at ACA-Py and AFJ and the effort to bring in the anoncreds-rs artifacts such that we can start to use them.
  • Agreed that all peer-to-peer interactions/data structures should look the same, with the exception of the format of the IDs in the objects
  • We need to have an AnonCreds Methods registrar/resolver interface in the ACA-Py and AFJ codebases, similar to where we are with DIDs.
    • This is to enable the ledger-specific calls based on what the Aries Framework is configured to do for writing, or the resolution of AnonCreds IDs received.
  • For integration testing in Aries Frameworks and AATH: we'll wait until we're further along in producing artifacts before we move into integration testing.
  • Unit tests:
    • Keep building them (of course!)
    • There are many commented out tests – mostly because the Indy-SDK had access to an indy-wallet, and many of the tests assume that. We should add an in-memory wallet instance to enable activating those tests.
    • Task added to "uncomment" as many tests as possible and that make sense has been added.
• Maintainers List
  • Reviewed and for now we are happy with the list. The process is in place for 
• Future Meetings Schedule
  • Decision not to set a weekly/biweekly call. Instead, we'll go async first (Github, Discord), but strongly encourage Devs/Maintainers to call a meeting to address when async will taking too long. 
  • Always an option to have a discussion during or immediately after an AnonCreds spec meeting (Monday 7:00 Pacific / 16:00 Central Europe)
• Wrappers:
  • Would be nice to have generated wrappers if they are of sufficient quality and consistent with the Rust model (which may not be possible). Stephen to talk to Steve McCownabout what generated wrappers would be like to see if the rest of the Devs are supportive.
  • Keep wrappers in the repo or have them as a separate repo?
    • Argument to keep them in – we can make them a GHAction test to be working before merges – more likely to keep them up to date – and we can produce release artifacts in-sync with tags.
    • Argument to move them out – unmaintained wrappers become a burden and they make releasing features harder. Having them in a separate repo can make them easier to update (although that should really not be the case as long as we have active, engaged maintainers).
    • Proposal:
      • Keep core, active wrappers in, with GHA tests and artifact generation/publishing.
      • Keep existing, but non-core (no active maintainers) in separate repos
      • Have a process for moving a wrapper out of the main repo, and for moving a repo into the main repo.
        • Mostly tied around the number of active devs contributing to the wrappers and the roadblocks for releases because of slow wrapper maintainers
• Open Discussion

Future Calls

To Dos:

Action items

...