Summary

• Unresolved question about Indy Network Discovery
• Demo - resolving with version-id and version-time
• NYMs/ATTRIBs and DIDs/DIDDocs

Recording from the call: <to be added>

Welcome and Introductions

Announcements

• TBD

Attendees

• Stephen Curran
• Paul Bastian

Collaboration Channels

• Current hackmd document 
• indy-did-method on RocketChat - https://chat.hyperledger.org/channel/indy-did-method
• indy-did-method repo
  • ReSpec vs. SpecUp

Agreed Upon:

• The specific will be specific that all DIDs MUST be self-certifying – e.g. derived from the initial public key used in the NYM
• We'll use ":" for subsidiary ledgers, and we'll include placeholder support for KERI, leading to 4 cases:
  • Ledger with no subsidiary name, example: did:indy:sovrin:12345
  • KERI identifier on a ledger with no subsidiary name, example: did:indy:sovrin:keri:12345
  • Ledger with subsidiary name, example: did:indy:sovrin:staging:keri:12345
  • KERI identifier on a ledger with a subsidiary name, example: did:indy:sovrin:staging:keri:12345
• To find networks we will require at least the first and perhaps the second of these approaches, while the rest are suggested:
  • Config files for one or more known networks
  • A mechanism for a ledger operator to register discovery information for other ledgers (aka "human gossip")
    • A DID/DIDDoc on a ledger will contain cross-registry information
    • A mechanism is needed for finding the DID(s) that contain the registrations – ideas have been put forward - a DID Name Directory (DND) is the likely approach.
  • Decentralized registries based on verifiable credentials
  • Other registry mechanisms, such as the DDNR proposal
• did:indy will support version-id using txnID and version-time by returning the object active as of that time
  • Code will be needed to be added to did-indy to support that

Online Discussion (from RocketChat this week)

• None

This Week's Discussion:

Unresolved question from the network Discovery process:

• Should we document in the DID Indy Method Spec. the centralized publishing of ledger config files?
  • All the publishing of ledger config files in a known place – e.g. github – and under the control of an entity such as Hyperledger or DIF
    • This is centralized control because the maintainers accept the PRs that update the data
  • Decision: Do we want to propose a location to publish config files?
  • If yes, Decision: Where?

Demo - resolving with version-id and version-time

From Dec. 1 Meeting about NYMs / ATTRIBs and DIDs / DIDDocs

• DIDs / DIDDocs and NYMs / ATTRIBs - Discussion summary from last week:
  • No one likes the "don't change" Indy limitation – we'll have to change Indy to ensure consistency.
  • No on likes the possibility of inconsistent results from non-transactional (in the database sense) updates to separate ledger objects.
  • Desire is to have the NYM controller information in the DIDDoc either by the ledger verifying it is there or by injecting it during the writing or resolution.
    • Questions:
      • Should this be automatic (injected into the DIDDoc) or a MUST for the DID writer?
      • If automatic should it be on writing or resolution?
        • How would that impact signatures on transactions? 
      • If the DIDDoc has in it multiple signature requirements, does Indy enforce that? How would that merge with Indy permission rules (e.g. endorser+author to write object)
  • Need to make sure that an ATTRIB-less NYM continues to resolve to a DIDDoc – can't lose that.
    • Decision: Should an ATTRIB-less NYM return a DIDDoc conforming to (or aligning with) the did:key specification?
  • Decision: Should a DIDDoc be assembled from just the ATTRIB, from the NYM+latest(ATTRIB) (could be a specific ATTRIB version) or from the NYM+set(ATTRIBs)?
    • General feeling is not just the ATTRIB – can't separate out the NYM controller information 
      • My feeling is that assembling for a set of DIDDocs makes resolution more complex than necessary. For example, this requires rules about how to replace sections when merging ATTRIBs. Doable, but requires complexity that I think is unnecessary.
  • Decision: Does any assembly of the DIDDoc occur by the ledger, or does the ledger return the pieces to an external resolver that assembles the DIDDoc?