Summary

  • Update from the implementation team
  • Discussion about indy-vdr and multiple ledgers
  • Open PRs and Issues

Recording from the call: 20220322 DID Indy Specification Call Recording.mp4


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

Announcements

Attendees

Collaboration Channels

Online Discussion (from Discord this week)

This Week's Discussion:

  • Update from the implementation team
    • Implementation Plan: https://hackmd.io/@dbluhm/did-indy-impl
    • Ironing out validation details and testing - continued focus on validation and tests
      • All checks running + all tests passing.
    • Status of self-certifying DIDs – having the author announce the self-certification version they are using.
      • Feature nearly complete; working out the final gotcha's and tests. Expected to be merged into our main did:indy feature branch soon.
      • Question/Side Note: Version must be included for valid state proofs meaning, in the future, every nym transaction would require the version 2 marker regardless of the configuration of the ledger.
    • Coming up:
      • Planning another pass of clean up and minor refactors, verifying good test coverage, etc.
      • Indy HIPE and Node documentation updates
    • Question: Changes in Indy Node vs. Indy Plenum
      • Changes are in indy-node, not indy-plenum, but should they be?  Checking with Discord, but this is likely OK.
  • Discussion: Who is responsible for multi-ledger support for an Indy VDR instance?
    • The Indy VDR service, or the client(s) using the service?
    • Issues:
      • Static – on starting the Indy VDR service, pass in the networks to be used.
      • Dynamic – caller passes the DID on an "unknown" ledger
        • Configuration - should "unknown" ledgers be supported? 
        • Discovery via github (indy-did-networks repo)
      • Handling pool refreshes
    • Question:
      • Does the use case of an Indy VDR service with one vs. many clients matter?
        • Is the behaviour tailored to the clients?
  • GitHub PRs for review
  • GitHub Issues for review
  • Discussions:
  • Previous Meetings:
    • Resolved: Dealing with the Indy SDK while testing Indy Node and self certifying DIDs transition – from Daniel Bluhm
      • For transaction creation, we can sidestep this problem without too much trouble. The general workflow is build transaction then prepare and send transaction. We simply insert into that workflow modifying the transaction before preparing and sending or just create a transaction object directly. The volume of transactions that we'd need to modify to test the new behavior is low enough that this is not burdensome. However, you could call this technical debt simply due to it being a special case that doesn't look the same as the other tests. I consider this an acceptable trade off in the short term. The changes to the ledger are also backwards compatible with the structures generated by the SDK meaning current deployments depending on the SDK will not be broken by updates to the ledger.

      • However, the new DID self-certification requirement is low key the biggest breaking change in compatibility with the SDK. All DIDs generated by the SDK and newly published on the ledger are considered invalid. This has implications for both the tests and current deployments. For one thing, all of the many tests (virtually all of them) dependent on the generation of a DID that can be written to the ledger break with the self-certification requirement.

        • Ideas:
          • Don't enforce self-certifying, possibly return self-certifying status (not, old version, new version), walking back the chain – but how would a proof of that be given?
            • Alternative – return the sequence number of the self-certifying DID if in a chain
          • Enforce as of a given time - config to enforce or not.
          • Question - why enforce on the Node side?  Those on the indy-sdk would have to update.
            • The most we will do is optionally enforce this on Node. More likely we'll just not enforce it on indy-node.
        • Request: Investigate
  • To Do:
    • How far to take a DID Resolver in indy-vdr – decided: we want to add an indy did resolver API into indy-vdr
    • Create an Indy HIPE that points to the spec.
    • Define the backlog of tasks:
      • indy-node
      • indy-plenum
      • indy-vdr
      • universal resolver image

Future Discussions: