Summary:
| Excerpt |
|---|
Topics:
|
...
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
...
- Status Updates:
- AnonCreds RS in ACA-Py
- 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
- 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 AnonCreds RS Update process:
- Upgrade process – Issues: Single wallet: #2776, multitenacy wallets: #2785
- Data to be upgraded:
- 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".
- Core approach: Stop instance, run update script, start instance.
- 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 tractionTraction, 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.
- Should the execution of the upgrade block the use of the old endpoints?
- 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?
- Checklist Issue, labelled Issues and PRs
- 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
...