View Source

Summary

Ubuntu-22.04 upgrade progress reports
Future tasks
- GitHub Organization planning
- Secure Software Supply Chain
Updates
- Indy Besu updates and discussion
- DID Web VH
Open Discussion

Zoom: https://zoom-lfx.platform.linuxfoundation.org/meeting/97572546272?password=5da46f0a-57dc-4de9-8831-708ba60d97ae

Recording:

	LF Decentralized Trust is committed to creating a safe and welcoming community for all. For more information please visit the LFDT Code of Conduct.

Welcome and Introductions

Attendees

Char Howland (Indicio PBC) <char@indicio.tech>
Wade Barnes (BC Gov / Neoteric Technologies Inc.) <wade@neoterictech.ca>
Renata Toktar (DSR Corporation) <renata.toktar@dsr-corporation.com>

Related Calls and Announcements

Cool new use case: South African blockchain-powered Uber rival

Release Status and Work Updates

Indy Node/plenum – PR needed to replace Ursa with the indy-blssignatures-rs implementation. Issue https://github.com/hyperledger/indy-plenum/issues/1641
Indy-Besu - https://github.com/hyperledger/indy-besu
Indy-test-automation
Indy-Node test-automation integration next step after cleaning up the dependencies issues and getting the sovrin-test-automation finished.
Indy SDK – to be deprecated
Indy Monitoring - https://github.com/hyperledger/indy-node-monitor
Indy Node Container - https://github.com/hyperledger/indy-node-container
Indy/Aries Shared Libraries - Hyperledger (indy-vdr, indy-shared-rs, aries-askar, anoncreds-rs)
- Small update to Indy VDR to update the dynamic network discovery URL; needs to be published
Indy DID Method – https://hyperledger.github.io/indy-did-method/
AnonCreds Specification: https://anoncreds-wg.github.io/anoncreds-spec/

Meeting Topics

Coordinating Ubuntu-22.04 release
- Update CI/CD workflows to support Ubuntu 22.04; https://github.com/hyperledger/indy-node/issues/1896
  - Tests to be fixed
- Which will feed into, Upgrade indy-test-automation to support Ubuntu 22.04; https://github.com/hyperledger/indy-test-automation/issues/153
- Next steps, in order, that could be done concurrently to the above:
  - Indy VDR upgrade for plenum; https://github.com/hyperledger/indy-plenum/issues/1507
    - Eliminate dependencies on Indy SDK and Sovrin repos
    - Adam claimed
  - Indy VDR upgrade for node; https://github.com/hyperledger/indy-node/issues/1644
    - Guillaume claimed
  - Replace Ursa; https://github.com/hyperledger/indy-plenum/issues/1641
- Can this PR be closed? https://github.com/hyperledger/indy-plenum/pull/1654
  - Closed
GitHub Organization
- Complete by end of year, after the Ubuntu 22.04 upgrade
- Complete after removing obsolete dependencies
  - Revisit at next call, determine time
Secure Software Supply Chain
- Complete by end of year
- https://github.com/LF-Decentralized-Trust/governance/pull/26
- Example implementation: https://github.com/hyperledger-tooling/github-issue-schedule/pull/3
Updates
- Indy Besu updates and discussion
  - Held LFDT Meetup in Lisbon
  - Other companies are interested in Indy on Besu
  - Production discussion
    - Pilot in Brazil
  - Next task: provide a list of real use cases
  - First release coming soon
  - Annual report is updated with Indy on Besu info
  - Indy DID Method - deployment(rendering) pipeline is broken
- DID Web VH
  - AnonCreds is working- defined what they look like and how they are used
    - Revocation is (almost?) working
  - Meetings biweekly on Thursdays
    - Hoping to define 1.0
Open Discussion

Future Calls

GDPR and the right to be forgotten – mitigations and approaches.
The Indy "Corporate Firewall Problem" and the idea of a Proxy Server on Nodes? Kim Ebert
- Core issue: A mobile wallet user using a Corporate WiFi may find that they can't get to an Indy ledger because all but 80/443 ports and HTTP/S protocols are blocked
- Discussion/Options paper: https://hackmd.io/@n5FW6jwuRfCgchBDNWR3VQ/H1kNlKpmo
- Question: Is it viable to have each Indy Node also listen on port 80/443 for HTTP/S requests and arrange to have them processed?
  - Option: Receive on HTTP(S) and send on to local ZMQ instance as if coming from outside.
- Answer: We think it is probably not viable, as mobile agents require HTTPS. As such, each Steward would have to get a IP-based SSL Certificate. Technically doable, but getting everyone through that is really not practical. The cost of the certificates and maintaining them would be ugly.
  - Option: Add a DIDComm agent to every node, and use DIDComm to send the messages
  - Similar to using HTTP(S), but use a DIDComm message. Since Mobile Agents would be using a mediator, the DIDComm message would flow through that, and the HTTPS issue would not matter. This is almost easy, but... There is no encryption public key in the genesis file, so that needs to be retrieved from somewhere else...

Action items

Indy-Besu
- Continue discussion about open questions https://github.com/hyperledger/indy-node/issues/1826#issuecomment-1868609236