...
Excerpt |
---|
Planned:
|
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
- Move from Jenkins to GitHub actions
- Indy Node
- MayJune:
- 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
- Need to check additional dependencies:
- MayJune:
- Indy SDK
- May/June:
- Indy VDR into LibIndy
- Indy Credx into LibIndy
- May/June:
- 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
- Nearing release 0.6(?) - most work complete that was needed: Design doc, FFI, testing, CI / CD
- 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.
- https://github.com/sovrin-foundation/aries-credx-framework-rs
- 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
- Mike working on documentation and architecture as an Aries RFC (KMS architecture) and Ursa RFC (API)
- indy-vdr (Andrew Whitehead) https://github.com/hyperledger/indy-vdr
- Ursa
- BBS+ added
- 0.3.5 pending, plus new additions
- Aries Shared:
Meeting Topics
- Indy Performance Testing
- Update: Migrate Jenkins to GitHub Actions (and perhaps Azure pipelines)
- Plan started - Sovrin resource migration
- Resources: NONE
- 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.
- What constraints should be applied?
- Tech Spike on Merkle Trees in process (Daniel Hardman)
Future Calls
Next call:
Future:
...