...
| Excerpt |
|---|
|
Recording from the call: 20210209 Indy DID Method Specification Call Recording
|
Hyperledger is committed to creating a safe and welcoming community for all. For more information please visit the Hyperledger Code of Conduct. |
|---|
...
- 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.
- Document about the DND and DNR records
- 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.
- Agree on the NYM + 1 ATTRIB solution
- NYM shall comprise of all security-relevant data, ATTRIB is for user → therefore ATTRIB can contain all the diddoc information that is not relevant to the security of the DID
- in the first version: verkey is the only verificationMethod, therefore ATTRIB shall not use verificationMethod (for simplicity)
- NYM generates context, id, verificationMethod
- ATTRIB shall not have id or verificationMethod
- contexts are merged with ATTRIB
- everything else from ATTRIB should be merged
Online Discussion (from RocketChat this week)
...
- See hackmd document
- Format of the ATTRIB document (`@context`, nymKeyAgreement, content)
- Process for adding ATTRIB
- Handling of existing "endpoint" ATTRIB
- is boolean variable a slippery slope?
- shall the diddoc ATTRIB only include raw DID json that is to be merged?
- disussion on nymKeyAgreement
- pro: you can rotate verkey and automatically rotate the X25519 key without touching the ATTRIB, rotating takes 1 less write transaction, saves some bytes on the ledger
- contra: less generic solution, special case for special signature mechanism, unlikely design to use same privatekey for NYM protection and KeyAgreement,
- GET_DIDDOC request might be too troublesome as we cannot provide the indy state proof for client validation right now
- rebuilding indy to include assembled diddoc might take some time
- easier solution right now is the universal resolver driver concept → client requests NYM + ATTRIB and uses reference implementation to assemble the DID doc
Future Discussions:
- Discussion on nymKeyAgreement
- What format for other objects on the ledger as DIDDocs.
- What format for existing objects on the ledger as DIDDocs?
...
- DNR and DND discussions
- Structure for Indy specific objects returned as DIDs
- What is the DID?
- What is the DIDDoc format?
- Existing objects – backwards compatibility
- DID vs. DID URL – how could that be done?
...