Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

Excerpt
  • Update from the implementation team
  • Open PRs and Issues

Recording from the call:

...

 20220215 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.

...

  • Update from the implementation team
    • Implementation Plan: https://hackmd.io/@dbluhm/did-indy-impl
      • Is there a better place for this document? 
      • DID Doc support is well defined
      • Investigation into required changes for resolving AnonCreds objects is ongoing 
    • Walked through the process of adding the DIDDocContent to NYM
      • Assessment so far – no need for separate storage
      • Dominic's branch was very useful – especially on version
    • New take on self-certifying DIDs
  • GitHub PRs for review
  • 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?
      • For implementers to determine:
        • What would it mean to not have the schema on the same ledger?  Is that easy to do?
        • Possible solution: Have endorsers require that they verify the schema on another ledger exists.
        • Daniel Bluhmand team to review and come back with a decision.
      • Previous discussion:
        • Possible: Put a reference on NetworkB to schema on NetworkA
        • Idea: Inter Blockchain Communication Protocol (IBC Protocol) - genesis transaction from NetA on NetB, when write reference to Schema from A to B, can include state proof
          • NetworkB becomes a client of NetworkA
          • CLAIM_DEF MUST reference the local instance of the SCHEMA
          • Extend definition of SCHEMA to include an optional reference to the original schema (DID URL and state proof from other ledgers)
        • Idea: Put this as future work?  Put this in as a consideration for issuers.
          • Don't allow for now – future work to enable cross-ledger references
          • Allow but do no extra checking – future work to constrain
        • Idea: Don't allow Claim_Def to reference object on another ledger – schema MUST be on the same ledger.
      • Options:
        • Do nothing, allow this and ignore the "network can go away" issue.
        • Do nothing, don't allow this.
        • Don't allow, but allow some way to have a local copy of the schema.
  • To Do:
    • How far to take a DID Resolver in 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

...