See HackMD Document for most of what we have discussed
To find networks we will require at least the first and perhaps the second of these approaches, while the rest are suggested:
Config files for one or more known networks
A mechanism for a ledger operator to register discovery information for other ledgers (aka "human gossip")
A DID/DIDDoc on a ledger will contain cross-registry information
A mechanism is needed for finding the DID(s) that contain the registrations – ideas have been put forward - a DID Name Directory (DND) is the likely approach.
Decentralized registries based on verifiable credentials
Other registry mechanisms, such as the DDNR proposal
The DID Method Spec will include a reference to a repo (likely) "indy-did-networks" within Hyperledger that will be a lightly managed, structured repository of folders per Indy network with at least the config file(s) for the networks. Use of the repo is voluntary, but provides a convenient way for networks to publish information about the network. Maintainers will be selected from the community and should exhibit a light hand in accepting PRs, being concerned mainly with structure of the data (not content) and that contributors are not being malicious about updating the information of other network operators. The Hyperledger governance structure may be used for disputes as appropriate. This is not a replacement for the Governance that a specific network should implement.
NYM + ATTIBS
A DIDDoc will be dynamically generated from the NYM and related ATTRIBs by the ledger and returned via a transaction
The NYM is the controller (per the DID Spec) of the DIDDoc, and as such, MUST be in the "verificationMethod" and possibly the "controller" element of the DIDDoc
Nice to have in the future is that NYM control be extended to support multi-sig scenarios such as multiple public keys and perhaps "N of M" signatures for updates. If and when these features are added, the capabilities would be appropriate reflected in the generated DIDDoc. The ATTRIB-based elements of the DIDDoc would not be used for that.
Online Discussion (from RocketChat this week)
None
This Week's Discussion:
Continuing from the last discussion on transforming NYM and ATTRIB data to get the DIDDoc
Status of HackMD Document – updated to reflect discussions made. Additional transoformations added.
Primary question: Assuming the ledger generates the DIDDoc from the NYM and zero or more ATTRIBs (see HackMD document and assumption above), should there be just a single ATTRIB that has the entire document minus the data that comes from the NYM, or should there be a number of ATTRIBs that generate snippets of the DIDDoc, or both? From the discussion:
Snippets would be at the DID Core elements level or at the DID Registry elements level. An example of the latter is in the hackmd document.
Future Discussions:
Request for Markus Sabadello to provide guidance on aligning the "NYM as controller" concept (above) with and the DID Core specifications concept of a controller.
ATTRIB transformations to generate a DIDDoc
DNR and DND discussions
Structure for Indy specific objects returned as DIDs