Skip to end of metadata
Go to start of metadata

Summary

  • Summary of close-to-done Spec.
  • Serialization formats - use JSON?
  • To Do's going forward

Recording from the call: 20210504 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.

Welcome and Introductions

Announcements

Attendees

Collaboration Channels

Agreed Upon:

  • See HackMD Document for most of what we have discussed

Online Discussion (from RocketChat this week)

This Week's Discussion:

  • The "close-to-finished" Hackmd DID Method Spec – please review
    • Added identifiers for other objects
    • Removed the sequence number for of DID – I don't think it is needed
    • Removed – DNR/DND, KERI
  • JSON vs. JSON-LD
    • From Daniel: Here's a google doc that captures my thinking. I am not so emotionally or intellectually caught up in my own perspective here that I will balk if I am out-voted, but I would appreciate knowing that a thoughtful discussion about it occurred before a decision was made.
    • Proposal: Leave it up to the controller to decide:
      • If there is no DIDDoc Content, use JSON as the template 
      • If the DIDDoc contains the `@context` – add it in and the document becomes JSON-LD (must include the DID Core Context)
  • To Do:
    • HackMD Cleanup – another pass
    • Requirements from the DID Core Spec. – 8.1, 8.2, 8.3
    • Convert to SpecUp and publish
    • Create an Indy HIPE that points to the spec.
    • Define the backlog of tasks:
      • indy-node (assuming there is no indy-plenum work)
      • indy-sdk and indy-vdr
      • universal resolver image

Future Discussions:

  • Deferred to 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.