Page History

Summary

Zoom: https://zoom.us/j/93198495358?pwd=TS80VklHVElJS3lEcjUzQjV0VHVtUT09

Recording: 

Welcome and Introductions

Attendees

• Wade Barnes (BC Gov / Neoteric Technologies Inc.) <wade@neoterictech.ca>
• Lynn Bendixsen (Indicio, PBC) <lynn@indicio.tech>
• Bruno Hivert  (https://idlab.org) <bruno.hivert@idlab.org>
• Emiliano Suñé (BC Gov / Quartech) <emiliano.sune@quartech.com>
• Sean W. Bohan (Hyperledger) <sbohan@linuxfoundation.org>
• Renata Toktar (DSR Corporation) <renata.toktar@dsr-corporation.com>
• Sylvain Martel (Qc Gov) <sylvain.martel10@mcn.gouv.qc.ca>

Related Calls and Announcements

Release Status and Work Updates

• Indy Node/plenum – PR needed to replace Ursa with the indy-blssignatures-rs implementation. Issue #
• 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)
• Ursa
• Indy DID Method – https://hyperledger.github.io/indy-did-method/
• AnonCreds Specification: https://anoncreds-wg.github.io/anoncreds-spec/

Meeting Topics

• Indy network upgrade progress
  • Indicio TestNet - upgrade to 20.04 is complete!
    • TestNet issue: add a new node, new node could not connect to primary node. Troubleshooting guide provided (see Indy Node PR 1819), ready to be merged
  • Indicio DemoNet began an update - 4/7th of the way.  Issues were encountered.
    • DemoNet: Node removed, keys retained, node added – couldn't be added to consensus and that split network – some nodes have one primary, other nodes have another primary.
    • Debugging/testing being done. Theories, but the effort to prove are a lot of work.
    • Issue might be the size of the audit log – 1.5M
    • Get a copy of the ledger from a working node – by stopping the node make a copy – copy that to the starting node – continue with the start up, and all is well.
      • Best practice?  Seems to be – start with a copy of the ledger (the data directory, renamed to the new node name) on every new node.  Reduces the catch-up time.
    • First two were rough, last two were "easy" using the workaround of having a copy of the data directory.
  • Sovrin: Document is done – ugrade on BuilderNet is to start soon.
  • Documentation:
    • Upgrade guides being converted to Markdown and to be submitted.
• Indy Ecosystem Summit follow up – Indy on Besu
  • AnonCreds objects – Smart Contract based interactions
    • Could be put in the Smart Contracts so would be on chain.
      • All transactions for AnonCreds are small enough.
    • DSR is doing a design and POC spikes – welcome to have discussions about the project.  Feedback would be very much appreciated!! Contact Renata Toktar
      • ed25519 usage is not there – who/whether to add/
      • DIDDocs – what should they look like?  Full DIDDoc, or one derived based on data elements such as is currently done with Indy (nym+attrib).
      • Idea is to get this to work with an Aries agent with a small SDK.
    • Consensus – what is the model? Proof of Authority model – QBFT, IBFT 2.0, and Clique are options, DSR selected QBFT with no gas.
  • VeriDID work on Canon – using Besu as an Indy replacement
• 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