2020-02-10 Indy Contributors Call

Summary

Work updates and collaboration

  • Indy Node using Ursa
  • Indy-VDR
  • Anoncreds
  • Rich Schemas

Will schedule additional meetings for a Rich Schemas discussion and a discussion to help others support Indy networks.

We intend to record this call.

Remember the Hyperledger Code of Conduct

Anti-Trust Policy

Linux Foundation meetings involve participation by industry competitors, and it is the intention of the Linux Foundation to conduct all of its activities in accordance with applicable antitrust and competition laws. It is therefore extremely important that attendees adhere to meeting agendas, and be aware of, and not participate in any activities that are prohibited under applicable US state, federal or foreign antitrust and competition laws.

Examples of types of actions that are prohibited at Linux Foundation meetings and in connection with Linux Foundation activities are described in the Linux Foundation Antitrust Policy available at http://www.linuxfoundation.org/antitrust-policy. If you have questions about these matters, please contact your company counsel, or if you are a member of the Linux Foundation, feel free to contact Andrew Updegrove of the firm of Gesmer Updegrove LLP, which provides legal counsel to the Linux Foundation.

Introductions

Attendees

Related Calls and Announcements

  • Going forward, we will not be holding the AMER afternoon / APAC morning call
  • Identity Implementors Working Group call
    • Main place to get project updates, release status, and announcements.

Release Status and Work Updates

  • Indy Node
    • February:
      • Replacing Indy Crypto with Ursa (Kiva)
      • More "rich schema" objects
      • Tool for detecting ZMQ network problems
      • Troubleshooting guide
    • Future
      • Ubuntu 18.04 (Kiva)
        • Need to check additional dependencies: 
          Error rendering macro 'jira' : null
  • Indy SDK
    • February:
      • Bug fixes
  • Indy Catalyst
  • Anoncreds 2.0 (Mike)
    • Implementing in an Aries Shared Library
  • Aries Shared Libraries
    • indy-vdr (Andrew Whiteheadhttps://github.com/andrewwhitehead/indy-ledger-client
      • HTTP REST client that can be used to proxy ZMQ traffic
      • Next steps:
        • VDR Design Doc
        • FFI
        • Unit tests
        • Functional tests
        • Migrate repo to Hyperledger
          • First commit should point to previous history in indy-sdk
        • Integrate into existing LibIndy
          • Apply recent bug fixes to the new VDRI
      • As an Aries interface becomes standardized, a new repo will be created for the indy-aries-vdri
        • Or a single aries-vdri with modules for each interoperable ledger
    • indy-aries-anoncreds / indy-creds → indy-credx
    • Aries-Shared-Util
      • Pack / Unpack
        • Lift-and-shift would be Indy specific, but refactoring for Aries-KMS could take a long time
      • Need a place for Rich Schemas functions → many will go to Aries Credx
    • Aries-KMS
      • Mike and Cam's aries-core-rs → aries-kms-(placeholder)
        https://github.com/sovrin-foundation/aries-core-rs
        • Evolution from lox
        • Will include a default storage that is not a different implementation from the plugins
        • Hopes for a protype in February
      • Move the Indy wallet crate as a starting point → aries-kms-taiga
  • Ursa 0.3.2
    • Releasing this week?
    • Implements key exchange, so LibSodium hopefully is no longer required

Main Business

  • Special calls:
    • Conflicts: US February 17, Russia February 24, HL Global Forum March 2, Russian March 9
    • Rich Schemas:
      • Tuesday February 11 at 8 Mountain or Wednesday February 12 at 9 Mountain?
    • On troubleshooting Indy
      • Tuesday February 25 at 8 Mountain or Wednesday February 26 at 9 Mountain?
  • Collaborate on Rich Schemas
  • IS-1222 blocked by Ursa CI / CD
  • INDY-2305: Add IP address range for outbound TCP connections from validator nodes

Future Calls

Next call:

Future:

  • Requirements questions:
    • IS-1099: anoncreds.prover_get_credentials_for_proof_req should return per-credential timestamp
      • Should we allow duplicate credentials from the same issuer?

Action items

  • HIPE #138, Issue #144 (Ken and Brent)
    • Create a PR for changing status to ACCEPTED
    • Check for an Aries RFC
  • PR to RFC #0019 to compare pack/upack to msgpack (Sergey)
  • Richard and Sergey will close old pull requests with a descriptive comment.
  • Mike wants to review the 61 cases of "unsafe" libindy calls and figure out if they are justified.


Call Recording