2024-06-25 Aries Cloud Agent - Python Users Group Community Meeting

Summary:

Topics:

• PRs and Issues
• LTS Handling - Issue #, PR 
• Questions from Anonyome Labs
• 1.0.0 Progress
• Open Discussion

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

Recordings From the Call:  

Welcome, Introductions and Announcements

Attendees

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

Documentation:

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

Agenda

• Open PRs
• Open Issues:
• Anything hot that should be addressed before 1.0.0rc0?
  • • Perhaps: 3055, 3020, 3018, 2999, 2895
• LTS Handling - Issue #2993, PR #3051
  • Outlines the strategy
  • Commits to LTS for 0.11.1 and 0.12.0
  • Initial Questions:
    • Policy for setting end dates for LTS.
    • Release number for an LTS – seems we need both a minor number to be the LTS (e.g., 0.11.1), but we also need to have additional releases on the branch for identified vulnerabilities – how does that work?
    • How are we notified of only the dependabot vulnerabilities that need fixing in an LTS?
• Questions from John Court of Anonyome Labs about Universal DID Support:
  • Universal DID Resolver support is there using the --universal-resolver switch to set server location (we actually have deployed this to support cheqd DIDs locally).
    • Supported – directly in ACA-Py.
  • The AnonCreds abstraction for native registrar and resolver implementation of AnonCred VC objects exists, being defined in aries_cloudagent/anaoncreds/base.py. Currently the only concrete implemenations I see is for legacy_indy in aries_cloudagent/anoncreds/default/legacy_indy/. The other default implementations seem to mostly have "NotImplemented" for most methods. This means someone could write a native AnonCreds registrar/resolver for other VDRs (e.g. cheqd). There is however no Universal AnonCreds equivalent community project to the Universal Resolver/Registrar that I can find.
    • This is correct. Immediate goal is to get did:indy and did:tdw as the next concrete use cases.
  • The real missing piece for me seems to be there is still no abstraction of the DID Registrar concept with that functionality still being tied to the aries_cloudagent/ledger code which is indy specific. This seems to be the point of https://github.com/hyperledger/aries-cloudagent-python/issues/1876 to resolve but has stagnated since 2022 ?
    • Attempted twice, and the conclusion seems to be that a Universal Registrar is a false optimization for ACA-Py – DIDs are too variable, and as such, the plugin approach is more appropriate, allowing a deployment to pick their own.
    • did:web would be a good example, as will did:tdw.
    • Infrastructure is there for adding an admin interface and secrets access via a plugin.
    • Patrick St-Louis has been trying out GoDIDdy to see the range of types, and agrees that the plugin approach is more appropriate – deployments could add whatever plugins needed for an instance.
      • Plugins should be documented in ACA-Py for how to do that – plugins in general, DID Registrar plugins specifically.  aries-acapy-plugins is the place for them.
  • The tails-server is currently indy specific and has no abstraction layer to deal with reading revocation registry data from non-indy VDRs.
    • This should probably be changed to "anoncreds-tails-server".
    • When ledger-agnostic AnonCreds was implemented, extra endpoints were added (with some verification), and the older Indy endpoints are still there with verifications tied to Indy.
    • Should we extend out the functionality of what amounts to a file server to support other kinds of things – e.g. BitStringStatusList VCs, etc.?  Generally yes, but the verification/authorization checks need to be appropriately applied.
    • Question: What authorization is implemented in a Tails Server deployment?
      • Endpoints are locked behind a reverse proxy so that only the issuers can write to the ledger.
      • The tails files are hash checked, so you could not override an existing file.
• Question: Possible issue with the --preserve-exchange-records  flag in acapy
  • If you don't have that flag enabled, there is no way to complete a proof request if you are the verifier.
  • Should only be deleted AFTER the web-hook has fired to notify the controller.
    • The web-hook is coming back as a "terse web-hook", that does not have sufficient information, and then it is a race condition between the controller and the deleter.
    • Likely the fix needs to be making sure the webhook has sufficient info.
• Getting to a default Arm friendly release.
  • Any progress?  Nothing yet.
  • Issue posted to Mattr with a request. Stephen Curran to follow up with the them and failing that – we look for an alternative.
• Other hot issues.
• Open Discussion

Upcoming Meeting Topics:

Future Topics

Action items