Summary

• Updating the NYM object to include additional DIDDoc items
• Serialization formats
• Resolving ledger objects as DIDs?

Recording from the call: 20210302 Indy DID Method Specification Call Recording

Welcome and Introductions

Announcements

Attendees

• Stephen Curran
• Dan Gisolfi
• Paul Bastian

Collaboration Channels

• Current hackmd document 
• indy-did-method on RocketChat - https://chat.hyperledger.org/channel/indy-did-method
• indy-did-method repo: ReSpec vs. SpecUp

Agreed Upon:

• See HackMD Document for most of what we have discussed

Online Discussion (from RocketChat this week)

• What is in a NYM state proof and if it can be "easily" extended
• Serialization formats

This Week's Discussion:

• From last week's discussion – confirmation of approach:
  • Update the NYM to add a "diddocContent" item that is the equivalent of what we proposed would go in the DIDDoc ATTRIB, with assembly left to the client 
    • Include support for the version_id and version_time resolution parameters.
    • Confirm error checking done on the NYM write.  See proposal in the hackmd document (valid JSON, no NYM fields, valid DIDDoc)
      • What are the security implications of running this code on a node – vulnerability possibility.
  • Other options rejected
    • 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.
      • Likely choice if extending the NYM is impractical
    • Do nothing
    • Single call with both state proofs and ledger does assembly
    • Write DIDDoc on ledger writes and have state proof for DIDDoc
    • Add WRITE_DIDDOC transaction
• Serialization formats
  • Include in document that DIDDocs are JSON-LD
    • Three serialization formats in the DID Core spec – let's go with 1 to reduce interop and implementation effort.
• Decision on assembly points of concern:
  • The "nymKeyAgreement" flag
  • Remove the "content" item and just inline the rest of the DIDDoc content
• Other Indy Ledger Objects as DIDs (e.g. schema, etc):
  • Drummonds proposal: https://docs.google.com/document/d/1f99z4Bf8F-DA8EbkNjInVQv2ncJGPwF_Dp7I7Mfyhqs/edit
  • Other options:
    • Use the `@context` to indicate what type of Indy object is being referenced.
    • Use a GET_DID transaction that uses the local identifier for the different objects and the ledger figures out the doc type and returns the appropriate result – e.g. a SCHEMA, CLAIM_DEF, etc.  The existing transactions remain and are used if the client wants.  The GET_DID can also be used to return a NYM.
      • STATE_PROOF comes back in the reply as currently done.
  • Existing transactions

Future Discussions:

• What format for other objects on the ledger as DIDDocs.
• Handling existing objects on the ledger as DIDDocs?
• DNR and DND discussions
  • 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.