You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 5 Next »

Summary

  • Update on Sovrin Node pipeline
  • Help needed on getting Indy Node to past "RC" status
  • Update on indy-vdr issue with Genesis File/Node mismatch issue + plus tests
  • Updates on the AnonCreds work that impact Indy
  • Security testing outcomes
  • Eliminate the indy-sdk initiative
  • Q&A


Recording of Call:


Hyperledger is committed to creating a safe and welcoming

community for all. For more information

please visit the Hyperledger Code of Conduct.

Welcome and Introductions

Attendees


Related Calls and Announcements


Release Status and Work Updates

Meeting Topics 

  • Sovrin Node build
  • Help on the transition of indy-node from RC to final
  • Update on indy-vdr issue with Genesis File/Node mismatch issue (indy-vdr#106)
  • Question from Christian today – using indy-node-container for the indy-vdr tests
  • Deprecate the indy-sdk initiative:
    • Enable shared components in all Aries Framework – notable AFJ and Aries VCX
    • indy-vdr with did:indy support – how do we get that released?
    • indy-vdr is using Ursa, which is using a deprecated Rust module "failure" – https://github.com/hyperledger/ursa/issues/199; CVE - very high score! Possibly not critical for us, but looks bad.
    • Create a migration tool to export indy-wallet contents and load into aries-askar
    • Create a "shared components" version of the Indy CLI
    • New transaction types in indy-vdr – draft PR, but needs work and testing
    • Indy Test Automation relies on the indy-sdk, needs to be moved to indy-sdk
    • Community impact on the use of the indy-sdk – a need to migrate
    • Tools on the indy-node nodes – do they use libindy?  Investigation needed – Lynn BendixsenWade Barnes to look at/create issue.
  • Indy Roadmap
  • Other Topics

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...
  • Status of Indy-SDK
    • Statement on the future of the Indy SDK: PR 2329
    • Plans for future of Indy CLI (move to Indy VDR?)
    • Indy SDK in test for Indy Node (move to Indy VDR?)
    • Status of GitHub Actions for the Indy-SDK
  • Indy bugs
    • Using GitHub tags "Good First Issue" and "Help Wanted" 
    • Node 1490: problems with large catch-up
    • Plenum 1506: view change message consensus calculation error

Action items

  • No labels