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.
Online Discussion (from RocketChat this week)
Further discussion of State Proofs and what should the transaction be to get back a DIDDoc
Request for input on the "nymKeyAgreement" flag. Not much in the response.
This Week's Discussion:
Sergey Khoroshavin on Indy state proofs and the ramifications of a GET_DIDDoc transaction.
Comparison to the "get_revoc_reg_delta" transaction it's state proof handling.
Options for getting a DIDDoc, which are a trade-off of integrity and effort to implement
Do (almost) nothing. Client must get NYM, ATTRIB and assemble the DIDDoc.
Lack of certainty that the client gets a consistent version.
Have a single call that gets the NYM and ATTRIB and state proofs for both with same multi-signed merkle root, and leave the assembly to the client.
Same as previous but have the ledger return the assembled document.
To verify the state proofs, must still include the NYM and ATTRIB
Have NYM and ATTRIB transactions write the DIDDoc to state and return that
V1 txns work the same
V2 txns work this new way
Update NYM transaction to allow for an ATTRIB provided at the same time.
Looks like 4, but they are processed in a single call to the ledger
Create a new transaction WRITE_DIDDOC and put the object to the ledger
What's the impact on the NYM object?
For all:
How might a query that requests a "version_id=" and "version_time=" work?
version_time is doable, version_id is less clear, as we have two ids
Risk is losing time database
Any thoughts on the "nymKeyAgreement" discussion?
Is it important to remove the "content" item and just inline the rest of the ATTRIB?
What error checking should be done on the ATTRIB. See proposal in the hackmd document (valid JSON, no NYM fields, valid DIDDoc)
Other Indy Ledger Objects as DIDs (schema):
Process
Existing transactions
Putting the Ledger Objects on other ledgers using extensions