Summary

• Update from the implementation team
• Discussion: Using Indy SDK in the testing of the "did:indy" version of Indy Node
• Discussion: Transitioning to the new "self-certifying" DIDs enforcement
• Open PRs and Issues

Recording from the call: 20220222 did indy DID Method Specification Call Recording.mp4

Welcome and Introductions

Announcements

Attendees

• Stephen Curran
• Daniel Bluhm(Indicio PBC) <daniel@indicio.tech>
• Paul Bastian <paul.bastian@bdr.de>
• Lynn Bendixsen(Indicio PBC) <lynn@indicio.tech>
• Christian Bormann(Robert Bosch GmbH) <ChristianCarl.Bormann@de.bosch.com>
• Wade Barnes(Neoteric Technologies Inc.) <wade@neoterictech.ca>

Collaboration Channels

•  indy-did-method on Discord - https://discordapp.com/channels/905194001349627914/941708981825576960
  • Invitation: https://discord.gg/hyperledger
• indy-did-method repo using SpecUp
• Published specification: https://hyperledger.github.io/indy-did-method

Online Discussion (from RocketChat this week)

This Week's Discussion:

• Update from the implementation team
  • Implementation Plan: https://hackmd.io/@dbluhm/did-indy-impl
• GitHub PRs for review
• Discussions: 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?

• GitHub Issues for review
• 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: