Versions Compared

Old Version 2

changes.mady.by.user Markus Sabadello

Saved on

compared with

New Version Current

changes.mady.by.user Stephen Curran

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

Excerpt
  • Review: Discovery of networks
    • Given a DID, how to find it's network via gossiped ledger data
  • Handling DIDs / DIDDocs using NYMs / ATTRIBs

Recording from the call: 20201201 Indy DID Method Speciation Call Recording

Hyperledger is committed to creating a safe and welcoming

community for all. For more information

please visit the Hyperledger Code of Conduct.

...

Collaboration Channels

...

  • Not on Rocketchat, but there was a note that no change to the DID Spec would be needed for resolving "did:indy:<namespace>" to return metadata about the ledger.

  • A further suggestion could be made to find metadata about a ledger by resolving "did:indy:<namespace>:did:indy:<cross-reg namespace>" to return cross-register information
    • That DID would be resolved on the "did:indy:<namespace>" by using the namespace specific identifier "did:indy:<cross-reg namespace>"
    • TBD who that did is handled by the ledger to find the DIDDoc.
  • Drummond to lead documenting this process in a new section of the HackMD.io doc

Discussion:

  • 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

...