Summary

Recording from the call: 

Welcome and Introductions

...

• 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.
    
    • 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.
    • Feature nearly complete; working out the final gotcha's and tests. Expected to be merged into our main did:indy feature branch today.
  • 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 PlenumIndy HIPE and Node documentation updates
• 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
  • (Draft) Resolvable JSON-LD DID Doc Examples  - Moved to Sam Curren for further review and research.
• GitHub Issues for review
  • Indy object naming conventions permit whitespace and other characters that impact formatting as a URL
• 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: