Summary:
Topics:
- PRs and Issues
- LTS Handling - Issue #, PR
- Questions from Anonyome Labs
- 1.0.0 Progress
- Open Discussion
Recording:
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
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?
- 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 (Deactivated) 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).
- 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.
- 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 ? \
- The tails-server is currently indy specific and has no abstraction layer to deal with reading revocation registry data from non-indy VDRs.
- Getting to a default Arm friendly release.
- Other hot issues.
- Open Discussion