Summary

  • Update from the implementation team
  • Open PRs and Issues

Recording from the call: 20220308 Indy DID Method 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
    • Early assessment of using config transactions for activating self-certification enforcement
      • Findings can be found here: https://hackmd.io/@dbluhm/did-indy-impl#Self-certifying-Nym-transaction-transition
      • Summary
        • Static configuration would require high (likely impractical) levels of coordination between node operators but would make nym writes faster.
        • Dynamic configuration via config ledger seems doable but we don't have many precedents in the code already where a domain transaction handler is reading from the config ledger. It's unclear how severe of a performance hit we would take on new nym writes to check the config ledger before doing self-certification validation. There may be an opportunity for caching in a simpler data structure, similar to the identifier cache currently in node.
        • Idea: add new field that specifies whether the submitted nym is self-certifying; could provide an interesting opportunity to enable progressive enforcement of nym requirements.
  • GitHub PRs for review
  • GitHub Issues for review
  • Discussions:
    • 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?
      • Decision: ...
    • Question from Nathan George: are revocation registry entries and deltas returning the correct state proofs when resolved by URL?
      • Since the process of resolving by URL includes mapping the URL back to traditional GET_REVOC_REG and GET_REVOC_REG_DELTA transactions, we're relatively confident that the proposed implementation is at least as correct as the original implementation.
      • Daniel Bluhm and team to investigate more to make sure this is the case
  • Previous Meetings:
    • diddocContent Validation: @context validation requirements
      • Is the context likely to change? What happens on new versions?
      • Decision: relax the requirement in the spec; see the issue for more details. 
    • 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: