Summary

• Update from the implementation team
• Open PRs and Issues

Recording from the call: <ToBeAdded>

Welcome and Introductions

Announcements

Attendees

• Stephen Curran

Collaboration Channels

•  indy-did-method on RocketChat - https://chat.hyperledger.org/channel/indy-did-method
•  indy-did-method on Discord - https://discordapp.com/channels/905194001349627914/941708981825576960
• 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
  • 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
  • Status of the plan?  Phase 1 deliverable.
• 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

Future Discussions: