2020-11-10 Indy DID Method Specification Call

Summary

  • Update from DID F2F last week – resolutions?
  • Continued: 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: 20201110 did indy Method Specification Call Recording

Welcome and Introductions

Announcements

  • TBD

Collaboration Channels

Discussion

  • Update from the recent W3C DID Core Face to Face sessions - Brent Zundel
    • `type` will not be included in the spec, which impacts how we will store non-DID ledger objects (e.g. schema, etc.) as DIDs
    • JSON, JSON-LD and CBOR will all be supported in the spec., although DID Methods have the option of supporting some representations
      • This impacts the `type` issue in that we can solve the issue in just, say JSON-LD, and cover it in the other representations.
  • The <network> element of the DID – did:indy:<network>:<id>
    • Proposals to start the meeting: 
      • Hash (did:indy:543F4:<id>) – unrecognizable, verifiable with the ledger, short, non-discoverable/requires a registry
      • Domain Name (did:indy:example.com:<id>) – recognizable, discoverable, not tied to the ledger, dependent on DNS
      • Arbitrary Name (did:indy:Sovrin:<id>) - recognizable, non-discoverable/requires a registry, not tied to the ledger
      • Hash plus an alias based on the domain name (this is what TrustBloc does) 
      • Combination of arbitrary name and hash e.g. did:indy:sovrin:543F4:<id> 

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


  • Online discussion after last week's meeting – about the value of the hash for verifiability and the risk of spoofing.
    • Purpose of the hash is not so much for verifiability as for decentralized naming – no risk of squatting on the same name as there would be with an arbitrary name.
    • Added the "Decentralized Naming" to the table above.
  • The in-call discussion about the proposals:

    • Eliminated the DNS-based one as not desirable because of dependency on DNS


    • Eliminated the hash and DNS-based alias because of the complexity in using the two names for the identifier in signing scenarios, and the use of DNS.
    • Eliminated the hash only approach because of the lack of benefit of doing the hash vs. the downsides
      • The verifiability in using the hash is lost by using just 5 characters, but using a sufficient number makes the identifier too long
        • Micha generated a new Sovrin genesis file with a matching hash by varying only the alias name of one of the nodes in 30 minutes
        • Since we assume there will be in the low thousands of networks at the outside, the decentralization inherent in using the hash is not crucial
    • Eliminated the hash + arbitrary name because the hash is not providing additional value.
    • Leaving "Arbitrary Name" as the selected solution.


  • Next questions:
    • Third level names for subsidiary ledgers – e.g. Sovrin Staging and Sovrin Builder net?
    • How to find the nodes of the network once the ledger is known?  Config files, registries, gossiped names, etc.