Page History

...

The call was recorded is available here:

...

20200518 Indy Contributors Call

Remember the Hyperledger Code of Conduct

...

• Move from Sovrin Foundation infrastructure - Help Wanted
  • Move from Jenkins to GitHub actions
    • Sovrin Foundation Jenkins machines are going away
    • Sovrin resource migration
    • #cicd discussion "Indy CI / CD Migration" (in #cicd use menu item "Discussions" to see/get to the discussion)
  • Move repo.sovrin.org → Hyperledger Artifactory for all except Sovrin Foundation specific artifacts
• Indy Node
  • June:
    • Replacing Indy Crypto with Ursa (Kiva)
    • More "rich schema" objects
    • Ubuntu 20.04 (Kiva)
      • Need to check additional dependencies: 

        Jira
        server Hyperledger JIRA serverId 6326cb0b-65b2-38fd-a82c-67a89277103b key INDY-2196

• Indy SDK
  • June:
    • Indy VDR into LibIndy
    • Indy Credx into LibIndy
• Aries Shared Libraries
  • Aries Shared:
    • indy-vdr (Andrew Whitehead)  https://github.com/hyperledger/indy-vdr
      • Nearing release 0.6(?) - most work complete that was needed: Design doc, FFI, testing, CI / CD
        • CI - GitHub actions runs unit tests and basic integration tests
        • CD not there
        • No design doc, but crate docs
        • Rich Schema merged and behind a feature flag
        • Refactoring PR not merged - cleanup, internal simplification, crate docs
    • indy-credx - https://github.com/bcgov/indy-credx
      • Experimental ACA-Py branch created that can do credential exchange with indy-credx
    • indy-shared-rs - https://github.com/bcgov/indy-shared-rs
      • Shared features across indy-vdr and indy-credx
      • pack/unpack on Ursa (not libsodium)
    • aries-credx
      • https://github.com/sovrin-foundation/aries-credx-framework-rs
        • 6 most common attribute encodings (but not anoncreds 1 attribute encoding)
      • Can make a non-revocable credential and create proofs.
    • Aries Secure Storage initiatives:
      • Mike working on documentation and architecture as an Aries RFC (KMS architecture) and Ursa RFC (API)
        • PR is submitted: https://github.com/hyperledger/aries-rfcs/pull/440
      • Mike and Cam's work aries-kms-mayaguez - Postgres backend for credential storage
        https://github.com/sovrin-foundation/aries-kms-rs
        • Persistence work allows plugging in any database engine.
        • Focus is using an external enclave.
      • aries-kms-vostok
        • Andrew also working on that
  • Ursa
    • BBS+ added
    • 0.3.5 pending, plus new additions

Meeting Topics

• Indy Performance Testing
• Revocation 2.0 
  • Tech Spike on Merkle Trees in process (Daniel Hardman)
    • Tech Spike Implementation: https://github.com/dhh1128/merklespike 
    • Notes on Issues: size of compressed leaves, resources to calculate internal nodes 
    • Good progress on time to a size of about 256k but the memory usage is high (1GB).
      • Optimizations likely for performance and size as possible next steps.
  • Tech Spike on using ranges in the bitstream (Andrew Whitehead) which is looking very promising
    • 1M revocation registry seems viable, 16M may be possible
    • Question as to whether this approach will yield a range proof (user exposes range) or a ZKP
    • Next step: Andrew Whitehead Mike Lodder Brent Zundelto discuss and define if work on this approach should continue.
  • Discussion: How big should a revocation registry should be?
    
    • What constraints should be applied?
      
      • Issuer: revocation profile (% revoked, frequency), total credential pool size, number of rev. registries
      • Holder (especially mobile holder) resources: bandwidth, memory, compute resources, revocation frequency
      • Verifier: Rev Registries/Entries
      • Ledger: Rev Entry size, frequency, reads
      • Herd size
    • Should it be as large as possible within the tightest constraints, or should we aim for just a specific size?
    • Answer: Go for the largest that we can achieve within the constraints, with a likely minimum acceptable size being 1M credentials/registry
      • Issuers can choose smaller based on the use case, but we should aim for the largest feasible.

Future Calls

Next call:

Future:

...