Summary

• NYMs/ATTRIBs and DIDs/DIDDocs
• Unresolved question about Indy Network Discovery

Recording from the call: <to be added>

Welcome and Introductions

Announcements

• TBD

Attendees

• Stephen Curran

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:

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?

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?