Summary

  • Recap of IIW Discussion
  • Collaboration Tools
  • About the <network> element of the DID

Hyperledger is committed to creating a safe and welcoming community for all. For more information please visit the Hyperledger Code of Conduct.

Recording from the call: 20201103 Indy DID Method Call Recording

Welcome and Introductions

Announcements

  • Status of relevant, unresolved issues in the DID Core Spec
    • A `type` attribute

Discussion

  • Recap of discussion at IIW
  • Collaboration Tools:
  • About the <network> element of the DID – did:indy:<network>:<id>
      • What is the goal of the structure of the network?
        • Hash (543F4) – unrecognizable, verifiable with the ledger, short, non-discoverable/requires a registry
        • Domain Name (example.com) – recognizable, discoverable, not tied to the ledger, dependent on DNS
        • Arbitrary Name (SovrinStaging) - recognizable, non-discoverable/requires a registry, not tied to the ledger
        • Combination of hash and domain name (this is what TrustBloc does) 

        • Combination of arbitrary name and hash <arbname>:<hash>  e.g. did:indy:sovrin:<hash>:<id>

    ApproachDiscoverabilityDecentralized
    Control    		(Limited)
    Verifiability    		Human FriendlyConcisenessDependencies
    Hash of Domain Genesis FileNoYesYesNoYesRegistry or Config
    Domain NameYesYesNoYesNoDNS
    Arbitrary NameNoYesNoYesNoRegistry or Config
    Hash and Domain Name
    Alias, as in TrustBloc    		Yes and NoYesYesYes and NoYes and NoDNS and Config
    Arbitrary Name + HashNoYesYesYesNoRegistry or Config


      • What is the easiest way for agents to use this?
        • DNS is a hard sell per Dan Gisolfi
        • A registry implies centralization - e.g. GitHub, DIF, ToIP
        • Today it will be just a manual list of name - config files
        • Does readability matter?   Who sees a DID?
          • Should be no one.  "If anyone sees a DID, we've failed at our job" - quote from RWoT

Discussion ended here.  The following was not discussed in detail

  • First 5 characters of a hash – of what?
    • Genesis File
      • What Genesis File?  Domain (does not change - first n transactions on the ledger), Pool (does change - inevitable as it contains IP:port of nodes)
        • Proposal: Use the Domain Genesis File hash
        • Pool file is required to contact nodes of the network.
        • If Domain, what to do if there is a fork?
          • Proposal: Domain Genesis file contains the first n records after the fork, as the sequence number is the same
  • Should an "alias" be allowed as TrustBloc uses?
    • From Troy Ronda: A quick update on our did:trustbloc handling of multiple networks. With the ability to specify a canonical DID in the DID document, we are adding the ability to have both discoverable domains in the DID - e.g., did:trustbloc:domain:suffix and also to have a stable consortium genesis identifier - e.g., did:trustbloc:<consortium genesis hash>:suffix. The canonical DID would become the <consortium genesis hash> version such that the resolution of discoverable domain DIDs would point to this canonical DID in the resolution result.
    • TrustBloc alias example:
    • So Indy might use: 
      • <domain> alias is :example.com, https://example.com/.well_known/did-indy/ ??
        • Perhaps a folder with current ledger pool genesis file (to find the ledger) and ledger domain genesis file (to find/check the hash)
  • If the DID to be resolved is NOT using an alias, how is the Pool Genesis File found?
    • Known by all that need to know it?
    • Registry? GitHub?


Attendees: Stephen Curran Alexander Jonsson Kumaravel N Paul Bastian