Summary

• ATTRIBs – cardinality, transformation, assembly – specific examples
• Spec. document structure

Recording from the call: 20210112 Indy DID Method Specification Recording

Welcome and Introductions

Announcements

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

Attendees

• Stephen Curran
• Paul

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 discussioned
• 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.

Online Discussion (from RocketChat this week)

• None

This Week's Discussion:

Review of previous decisions

• See "Agreed Upon" topics above.

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

• Status of HackMD Document – updated to reflect discussions made.
• Transformations:
  • NYM
  • "endpoint" – historical – such ATTRIBs are on the ledger now
  • Concepts agreed to:
    • Only the last value of an ATTRIB type should be merged into the document; each instance should be complete
      • We don't have to track streams of updates
      • We are less likely to get into an invalid state
    • For "endpoint" and "serviceEndpoint" – the last of either should be used.
    • The "serviceEndpoint" and other DID Core concepts are likely to be complete sections of the JSON
      • This means there is less of a chance of transforming the document
      • If all the sections are complete, is it worth breaking them up vs. having a single "DIDDoc" ATTRIB and merging into it the data from the NYM transaction?
• Controller discussion
  • Question: Should the ability to update a DID use current Indy rules (checking the NYM owner signature and if necessary an Endorser) or should the contents of the DIDDoc be used?
  • This generated a discussion of the trade-off in the changes needed to Indy vs. the need to enable DID Core capabilities and organizational use cases (e.g. a DID controlled by multiple people in an organization).
  • Idea:
    • Extend the NYM to include more complex DID Controller concepts – e.g. multiple verkeys and multiple signatures required for writes, including (perhaps) N of M requirements.
    • If we did this, the more complex NYM would have to be merged into the ATTRIB(s) that make up the DIDDoc
• Idea:
  • Instead of having multiple ATTRIBs assembled into a DIDDoc, use a version identifier to handle the transformation of the NYM+ATTRIB to make the DIDDoc to enable backwards compatibility
• Open question: While we want to merge the NYM into the DIDDoc, do we need to have multiple ATTRIBs assembled into a DIDDoc, or just one?

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?