Summary

...

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

Discussion

Collaboration Channels

• Update from the recent W3C DID Core Face to Face sessions - Brent Zundel
• Reminder:Current hackmd document 
• indy-did-method on RocketChat - https://chat.hyperledger.org/channel/indy-did-method
• indy-did-method repo
  • ReSpec vs. SpecUp

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>

  • What is the goal of the structure of the network?
  • ProposalsProposals 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 (SovrinStagingdid:indy:Sovrin:<id>) - recognizable, non-discoverable/requires a registry, not tied to the ledger
    • Combination of hash and Hash plus an alias based on the domain name (this is what TrustBloc does) 

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

  Approach	Discoverability	Decentralized ControlNaming	(Limited) Verifiability	Human Friendly	Conciseness	Dependencies
  Hash of Domain Genesis File	No	Yes	Yes	No	Yes	Registry or Config
  Domain Name	Yes	Yes	No	Yes	No	DNS
  Arbitrary Name	No	No (collision risk)	No	Yes	NoMaybe	Registry or Config
  Hash and Domain Name Alias, as in TrustBloc	Yes and No	Yes	Yes	Yes and No	Yes and No	DNS and Config
  Arbitrary Name + Hash	No	Yes	Yes	Yes	No	Registry or Config

  
  

  
  

• What is the easiest way for agents to use this?
  • Today it will be just a manual, locally maintained list of config files
  • DNS is a hard sell per Dan Gisolfi
  • A registry implies centralization - e.g. GitHub, DIF, ToIP – but all require a central controller
  • 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 Santa Barbara
Online discussion – 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.

Discussion ended here.  The following was not discussed in detail:

• First 5 characters of a hash – of what?
  • Genesis File
    • Which 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:
    • did:trustbloc:testnet.trustbloc.dev:s3did12345
    • https://testnet.trustbloc.dev/.well-known/did-trustbloc/org1.sandbox.trustbloc.dev.json
      • Configuration file – equivalent to the Indy Pool Genesis File
  • 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?
  • Config files for now
  • Decentralized registry in the future?

...

• • 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.