Page History

...

Recording from the call:

...

 20201215 Indy DID Method Specification Call

...

Updates from this week are in bold. Strikethrough added where appropriate to previous text.

• DIDs / DIDDocs and NYMs / ATTRIBs - Discussion summary from last week:
  • Answer: No one likes the "don't change" Indy limitation – we'll have to change Indy to ensure consistency.
  • Answer: No on likes the possibility of inconsistent results from non-transactional (in the database sense) updates to separate ledger objects.
    • DISCUSSION: Agreed that there WILL be a transformation of a NYM+ATTRIB, Paul Bastianto facilitate discussion next meeting about how to combine those two to produce a DIDDoc. We had general agreement that the ATTRIB will NOT contain the "complete" DIDDoc as originally proposed in the hackmd.io document.
  • 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)
    • ANSWER:
      • Transformation will (likely – details to be discussed next meeting) be done to combine in some canonical way the NYM and ATTRIB data into a DIDDoc
      • It will be on resolution. Data will be written as today via NYM and ATTRIB transactions that can be read and verified ("source of truth") as needed from the ledger. DID resolution to transform the NYM and ATTRIB data will be an additional step.
  • Need to make sure that an ATTRIB-less NYM continues to resolve to a DIDDoc – can't lose that.
    • DecisionQuestion: Should an ATTRIB-less NYM return a DIDDoc conforming to (or aligning with) the did:key specification?
    • ANSWER: Decisions made that current ATTRIB-less NYMs and "endpoint ATTRIB"+NYM will return canonicalized DIDDocs via transformation, and that transformation will likely be structured in the style of "did:key", but up to date with the DID Core Spec.
  • DecisionQuestion: 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 
    • ANSWER: Assembled from NYM+ATTRIB (TBD – one ATTRIB or a collection of ATTRIBs?)
  • QuestionDecision: 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?
    • ANSWER: Still pending... to be discussed further.