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:

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

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.