2024-02-20 Aries Cloud Agent - Python Users Group Community Meeting

Summary:

Zoom Link: https://zoom.us/j/98856745538?pwd=VkJROWRxeW43d3hOdnJLemwrS0JKUT09

Call Time: 8:00 Pacific / 17:00 Central Europe

Recordings From the Call:  

Welcome, Introductions and Announcements

• Aries Annual Report PR for the Hyperledger TOC has been has been created – comments are still welcome.

• The report will be discussed at the Hyperledger TOC meeting this Thursday, Feb. 22 at 7:00 Pacific / 16:00 Central Europe – Meeting Notice. Everyone from the project is invited to attend.

• Hyperledger Mentorship Program – now accepting project proposals – great results last year in Hyperledger AnonCreds.

• IIW coming up April 16-18.

Attendees

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

• @Emiliano Suñé  (BC Gov/Quartech) <emiliano.sune@quartech.com>

• And 16 others...

Documentation:

• ACA-Py documentation: https://aca-py.org

  • Being updated such that the site will be generated from the ACA-Py repo directly, rather than from aries-acapy-docs.

Agenda

• Status Updates:

  • AnonCreds RS in ACA-Py

    • Endorser progress – PRs 2715, 2720, 2782 all merged. Left?

      • Getting multitenancy going is next. Issue #2767 (needed), #2792 (problem with what we have)

    • Next – last? part of the AnonCreds update: Implementing a AnonCreds Methods Registry – with documentation on how to implement it.

      • Need an example, and an implementation.

  • AnonCreds in W3C Format

    • ACA-Py team from What's Cookin' is progressing – draft PR opened

  • did:peer and AFJ Interop

    • AATH – tests implemented for did:peer:1, 2, 4

    • PR 2748 with fixes for Credo/ACA-Py for did:peer:4

      • Before 0.5.0 there was not a framework that does did:peer:2 or 4 in a standard way.

      • Perhaps – we should do did:peer:1 emit in ACA-Py (we already do receive).

    • Want to get Credo working for AATH – upgrade to backchannel controller for DID Exchange and OOB, restart the agent with new settings for everything

      • Sheldon is looking at this – starting with devcontainers so that a local environment is not needed.

      • Pick the devcontainer when you start the project – good pattern for the use of devcontainers on our repos

    • DID Rotation – @Akiff Manji is going to be working on this starting today.

  • Load Generator Testing at BC Gov using Aries Akrida

    • Bottom line summary – 310/issuances per minute.

    • Some changes to be pushed into Akrida

• AnonCreds RS Update process:

  • Upgrade process – Issues: Single wallet: #2776, multitenacy wallets: #2785

  • Data to be upgraded:

    • Issues #2384, #2385 are about revocation objects

    • Issue #2386 is about schemas and creddefs

    • Issue #2389 is about private keys related to AnonCreds objects.

    • Much less data than needed to be updated in the Indy SDK to Askar upgrade.

  • Proposal: Upgrade script to migrate from Askar to Askar-AnonCreds, similar to the Indy SDK to Askar script in aries-acapy-tools.

    • Core approach: Stop instance, run update script, start instance.

      • But...what about multitenancy? 

    • Side Issue: Can we extend the definition of what is in the ACA-Py plugins repository to cover the upgrade scripts currently in "aries-acapy-tools"?

      • Removes the need for an extra repo, and puts all of the "extras" for ACA-Py into a single place.

      • We could rename the repo, or just add information that "extends" the meaning of "plugins" to include other stuff.

      • Could also do that for examples in aries-acapy-controllers?

    • Concerns with "in-flight" credential exchanges – do we support those?

    • Upgrades will not include going from one database type to another (e.g., sqlite to postgres).

    • See issues below about multi-tenant upgrades. I think we have to see if we can avoid a "database update" vs. a "tenant updating records per tenant".

  • Upgrading the controllers in sync with updating the wallet:

    • Should the execution of the upgrade block the use of the old endpoints?

      • Pretty much has to or one is in a mess – records in the wallet that are old school and new.

      • What do we use to do this?

        • Data in the wallet that is checked on startup, and that blocks the endpoints?

        • Or do we use a startup parameter for the same purpose?

        • Can we dynamically remove the endpoints from the Swagger to cut down on the open-api size?

    • Multi-tenancy – can we run the upgrade on a per tenant basis vs. all tenants?  E.g., make the script operate at the tenant level vs. the database level?

      • In scenarios like Traction, where each tenant might use a different controller, doing an "all at once" upgrade is extremely difficult, bordering on impossible.

      • Question: are we changing the database structure (I don't think so...) vs. just changing the JSON content of records?

    • Upgrade has to be run with the Agent paused – e.g. no controller operations, since we need to upgrade the data before using the new endpoints.

      • How do we do that with multiple tenants. We don't want to force all of the tenants to upgrade at once.

      • Idea: Implement a "pause" mechanism that holds all processing of a deployment of ACA-Py instances while the upgrade is in process.

        • Careful: Has to be based on data in the wallet that has to be checked continuously, just in case an upgrade might happen.

        • Idea: Start-up parameter that when set tells the instance not to proceed until a wallet value set to a preset value.

          • Upgrade all ACA-Py instances to new version, with parameter set. All are sleeping, waiting for magic value.

          • Run update script that updates all records, set magic value.

          • ACA-Py instances see the magic value and proceed.

          • Subsequently, remove the startup parameter, or leave it and on startup, things proceed.

  • Need documentation for the API endpoint updates – what is the minimum update needed to convert from old to new?

• Status of ACA-Py 0.12.0rc1 - done.

• Status of ACA-Py 1.0.0 Release:

  • Checklist Issue, labelled Issues and PRs

    • Other issues/PRs to be added?

  • Should we wait on the AnonCreds RS work?

  • LTS Considerations per Aries RFC 0799 Long Term Support

  • Other considerations?

• Brainstorming: ACA-Py based Hyperledger Mentorships, and call for Mentors. Ideas:
  
  

  • Full pass over all the documentation and demos to make sure it is all up to date.

  • Investigating, designing and adding mDL support into ACA-Py.

  • Integrate ACA-Py and Aries SocketDock to make a hyper-scaling mediator.

  • Enabling tracing support in ACA-Py.

  • AnonCreds ideas:

    • Formalize the AnonCreds v2 programming interface, accounting for the existing AnonCreds v1 interface, but fully embracing AnonCreds v2.

    • Post-Quantum PS Signatures in AnonCreds v2.

    • AnonCreds v2 Cryptography Documentation.

    • Productizing ZKP-based scalable revocation using ALLOSAUR.

• Other PRs Ready for Review and Issues to Discuss

Upcoming Meeting Topics:

• Discussion Topics:
  
  

  • Update on ACA-Py Container Scanning

  • Multi-architecture containers

    • Issue with BBS+ package – doesn't support ARM containers – need an update to their CI

    • Solution: A third container published that includes BBS+ package, but is single architecture

    • Others are Askar

Future Topics

Action items