Page History

...

• Review of last week:
  • See discussion below and highlight/make decisions
• This week: DIDs / DIDDocs and NYMs / ATTRIBs
  • Proposal from ?? (sorry - didn't write down who)Paul Bastian – in hackmd.io document – "Alternative Version" section
  • Proposal from Kyle Den Hartogin the HackMd.io document – presentation
  • Discussion summary:
    • 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.
      • This is for adherence to the DID Spec and for security – to make clear in the DIDDoc the controller rules.
      • 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.
      • Suggestion made that an ATTRIB-less NYM return a DIDDoc conforming to (or aligning with) the did:key specification.
    • Debate: 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.
    • Debate: 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?

Summary - Cross-Registering Networks on a Ledger

...