2024-11-05 Indy Contributors Call

@Char Howland (Indicio PBC) <char@indicio.tech>

Kim Ebert (Indicio PBC) <kim@indicio.tech>

@Renata Toktar (DSR Corporation) <renata.toktar@dsr-corporation.com>

Sovrin Foundation is preparing for the likely ending of operations of its MainNet ledger on March 31, 2025

Voting in this year's LF Decentralized Trust Technical Advisory Committee (TAC) election will happen from November 1 to 14, 2024

• Check your eligibility here: https://lf-decentralized-trust.github.io/tac-eligibility-check/

• Nominate yourself here: https://github.com/LF-Decentralized-Trust/governance/issues

Indy Node/plenum – PR needed to replace Ursa with the indy-blssignatures-rs implementation. Issue #

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)

Indy DID Method – https://hyperledger.github.io/indy-did-method/

AnonCreds Specification: https://anoncreds-wg.github.io/anoncreds-spec/

Indy Quarterly Report

Updates

• Ubuntu 22.04 upgrade

  • Seeking review of https://github.com/hyperledger/indy-node/pull/1870

• Indy Besu updates and discussion

• Trust DID Web

  • Good IIW session, spec is solid

  • DID TWD feature: did/whois

    • Easy to use on a web-based DID

    • This will be put in a separate spec so that it can be used in every DID method

    • If supported by the DID method and if the controller of the DID has published this info, you can call did/whois and see verifiable credentials about the DID subject

Open Discussion

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...

Indy-Besu

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