Summary

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

Welcome and Introductions

Announcements

• Report out on the Indy Course presented last week by Hyperledger Foundation and Indicio – Lynn Bendixsen
  • 109 people at the start!

Attendees

• Stephen Curran

Collaboration Channels

...

• Paul Bastian
• Daniel Bluhm(Indicio PBC) <daniel@indicio.tech>
• Colton Wolkins(Indicio PBC) <colton@indicio.tech>
• Michael Schäfer (Robert Bosch GmbH) <michael.schaefer6@de.bosch.com>
• Char Howland (Indicio PBC) <char@indicio.tech>
• Christian Bormann  (Robert Bosch GmbH) <ChristianCarl.Bormann@de.bosch.com>
• Dominic Wörner

Collaboration Channels

• indy-did-method on RocketChat - https://chat.hyperledger.org/channel/indy-did-method
• indy-did-method repo using SpecUp
• Published specification: ReSpec vs. SpecUp

Agreed Upon:

• See HackMD Document for most of what we have discussed

• 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...)Notes and Help Wanted from another pass over the hackmd Spec:
  Help Wanted: Wording of the "namespace" section, with primary and secondary components.
  • Question: Current verkey change does NOT require signature of a new verkey. Should it? No is the consensus.
    • Stephen Curran to check if in spec and remove if needed.
  • Question: Will it be easy/possible to do "versionTime" query for a DID? Covered
  • Question: Should a "versionId" query require the seqNo be for a NYM, or should it search back on ledger for value of NYM at that time – same as "versionTime"? Covered
  • Question: The new Claim Def DID URL does NOT include the ID of the Schema. That means that you can't have the same named Claim Def using two different Schema. Is that a problem?
    • Nice to have: Analysis of Sovrin MainNet and Sovrin StagingNet to see how many instances of that exist.
  • Question: DID URL Handling for Rev Reg Entries
    • Does not use a straight, request object/return object as with other objects. Instead, may use the RevRegDelta Txn.
    • Good idea?
  • Help Wanted: Security Considerations sections
  • Help Wanted: Privacy Considerations sections
  • 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:
      Request that schema owner create a DID on two (or more) networks and write the schema on both networks
      • Leave off the namespace and propose searching multiple ledgers to find schema
      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:
  • HackMD Cleanup – another pass
  • Requirements from the DID Core Spec. – 8.1, 8.2, 8.3
  • Convert to SpecUp and publishHow 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
    • (assuming there is no indy-plenum work)
    • indy-sdk and indy-vdr
    • universal resolver image

Future Discussions: