Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

  • Incubation status graduation.

    • Complete the three items mentioned earlier in this document and apply for graduation.

  • Continue to refine documentation.

    • Consolidate documentation for onboarding contributors.

  • Network stability of the first production deployment (Sovrin).

  • Schema improvements!
    • We are currently working on enhanced schemas that will be compatible with the W3C Verifiable Credentials standards.   Our current credentials use schemas that are simple flat lists of untyped strings and this effort will allow complex data structures such as those available from   schema.org .
    • New encoding methods (to convert properties to signature values) and presentation (proof) requests will be able to preserve privacy and security through zero-knowledge proofs (ZKP) while maintaining the cryptographic assurances that the credential values have not been modified. The new encoding methods will expand the number of credential values that can be used in predicate proofs, such as "greater than", "less-than-or-equal", etc.
    • Schema re-use between Verifiable Credential issuers will promote interoperability.
  • Indy Catalyst
    • The OrgBook implemented as part of British Columbia's Verifiable Organization Network (VON) is being contributed to Hyperledger as Indy Catalyst. It provides a template for bootstrapping credential ecosystems built on Indy.
Indy Node
  • Consume official builds of Hyperledger Ursa (the shared crypto-lib), as they are approved.

  • Further improvements to automated testing.

  • Audit ledger
    • As we move permission management to the config ledger, we identified the need for an audit ledger to make it easy to verify what permissions were in place with each write.
    • The audit ledger will also ensure deterministic catch up between ledgers which resolves some BFT consensus corner cases.
  • Research into Ledger 2.0

    • We are confident that Indy Node can scale to millions of users, but we have identified a number of problems with the existing implementation that will limit future scalability. Solutions are likely to require fundamental architectural changes.

    • Improve the stability and performance of View Change, Catch-up, and Replication

    • Establish a cache for reads, such as observer nodes

    • We are recruiting contributors from various organizations to assist in designing the future of the ledger and starting implementation.

  • Broader OS support.

...