Summary

Recording from the call: <to be added>

Welcome and Introductions

...

• Update from the implementation team
  • Implementation Plan: https://hackmd.io/@dbluhm/did-indy-impl
  • Ironing out validation details
  • Early assessment of using config transactions for activating self-certification enforcement
    • Findings to be distilled in a new section of Implementation Plan
• GitHub PRs for review
  • Remove ATTRIB URL
  • Add version to document
  • Revocation Registry returned value clarification
  • (Draft) Resolvable JSON-LD DID Doc Examples
• Discussions:
  • diddocContent Storage
    • To be stored directly in ledger state as opposed to in a separate data store. Compare to claim def and schema transaction size.
    • Somewhat arbitrary 10KiB size? To be configurable at some future date (along with other transaction size limits)?
  • diddocContent Validation: @context validation requirements
    • Is the context likely to change? What happens on new versions?
• GitHub Issues for review
• Previous Meetings:
  • 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

    • Anyone have thoughts on a migration plan? Do we make enforcement of self-certification configurable and allow each ledger to decide when to flip the switch? Is that something that should be configured through the config ledger or statically?

  • Leftover from the last meeting (a long time ago...)
    • DECISION NEEDED: Schema on NetworkB, Claim_Def on NetworkB; NetworkA goes away. Can a holder proof/verify from a credential?
      • Decision: For now, Indy will only support Schema on the same ledger as Claim Defs, etc. 
• 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: