2021-02-02: Indy DID Method Specification Call

Owned by Stephen Curran
Last updated: Feb 02, 2021
3 min read

Summary

  • ATTRIBs – 0/1 or 0/N ATTRIBs?  How do we resolve this issue?
  • How to represent Indy Ledger Objects as DIDs?

Recording from the call: 20210202 Indy DID Method Call Recording

Hyperledger is committed to creating a safe and welcoming

community for all. For more information

please visit the Hyperledger Code of Conduct.

Welcome and Introductions

Announcements

  • Indy Node and Indy Plenum CI/CD process continuing – progress being made.

Attendees

Collaboration Channels

Agreed Upon:

  • 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.
  • NYM + ATTRIBs
    • 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)

  • HackMD updated –
    • Suggestion to include the "keyAgreement" section in the DIDDoc from the NYM
    • Adjustment to transformation NYM → DIDDoc
    • Added recommendation about multi-sig
    • Added recommendation about signature scheme and adding a separate keyAgreeement key

This Week's Discussion:

Continuing from the last discussion on transforming NYM and ATTRIB data to get the DIDDoc

  • Primary question: ATTRIB vs ATTRIBs
  • Already agreed on: ledger serves the DID doc
  • Agree on the NYM + 1 ATTRIB solution due to given motivation:
    • 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, the ledger must not need care too much
    • Indy resources
    • DIDdoc content might change too often in the near future and changeing the Indy DID Method might be too much trouble
  • draft ideas:
    • 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
  • ability to update the DID should be taken from NYM only, not the DIDdoc
  • in the future we will need other signature schemes
    • NIST curves are not preferred
    • post-quantum security will get relevant therefore this needs to be done anyway
  • in the future our verificationMethod might define a "type" referenced in the DID registries and we would include a context, this might become necessary when more complicated rules get put into NYM

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
    • What is the DID?
    • What is the DIDDoc format?
    • Existing objects – backwards compatibility
      • DID vs. DID URL – how could that be done?