Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 4 Next »

Summary:

Topics:

  • Status ACA-Py 0.12.0rc1
  • Status AnonCreds RS
  • Status did:peer and AFJ Interop – where we are
  • Status Load Generator Testing at BC Gov
  • Status AnonCreds in W3C Format
  • Upgrading an ACA-Py deployment to AnonCreds RS
  • Status: ACA-Py 1.00 Checklist
  • Brainstorming: ACA-Py based Hyperledger Mentorships, and call for Mentors
  • Open Discussion

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

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

Recordings From the Call:  


Hyperledger is committed to creating a safe and welcoming

community for all. For more information

please visit the Hyperledger Code of Conduct.

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

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?
      • Next – last? part of the AnonCreds update: Implementing a 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
    • Load Generator Testing at BC Gov using Aries Akrida
      • Bottom line summary – 310/issuances per minute.
      • Some changes to be pushed into Akrida
    • DRPC Support – Aries RFC 804 PR - work is completed, documentation has been passed and a demo being done.
    • ACA-Py Issue 2000 – moving webhooks – Race condition in issue-credential v1.0 leads to credential exchange switching to abandoned state
  • AnonCreds 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.
      • 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 1.0.0 Release:
  • 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


  • No labels