Summary

• Review of decisions to date
• Discussion (led by Paul) about transforming NYM and ATTRIB data into a DIDDoc
  • What goes into the ATTRIB and how does it manifest in the DIDDoc?

Recording from the call: <To Be Added>

Welcome and Introductions

Announcements

• BC Gov Open Source Bounty ($60k CDN) to add W3C Standard Verifiable Credentials with ZKP and Selective Disclosure to ACA-Py. Applications accepted through Friday here.

Attendees

• Stephen Curran
• Dan Gisolfi
• Markus Sabadello

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:

• The specific will be specific that all DIDs MUST be self-certifying – e.g. derived from the initial public key used in the NYM
• We'll use ":" for subsidiary ledgers, and we'll include placeholder support for KERI, leading to 4 cases:
  • Ledger with no subsidiary name, example: did:indy:sovrin:12345
  • KERI identifier on a ledger with no subsidiary name, example: did:indy:sovrin:keri:12345
  • Ledger with subsidiary name, example: did:indy:sovrin:staging:12345
  • KERI identifier on a ledger with a subsidiary name, example: did:indy:sovrin:staging:keri:12345
• 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
• did:indy will support version-id using seqNo and version-time by returning the object active as of the specified time according to the ledger time tracking
  • Code will likely be needed to be added to did-indy to support that
• For backwards compatibility, NYMs with no ATTRIBs and NYMs with Endpoint ATTRIBs, both of which are common on the Sovrin ledger today, will continue to be returned as DIDDocs, regardless of how we redefine a "DIDDoc" ATTRIB.
  • Currently, such a transformation is done by the Universal Resolver and it returns a certain format.
  • In future, the transformation for those use cases will be formalized in the DID Method and will be along the lines of the "did:key" approach (aligned of course with the DID Spec), where a number of uses for the DID key is defined vs. the current publication of just the key itself.
• The DID Method Spec will include a requirement that a DIDDoc will be returned as a transformation of ledger data regardless of how it is stored on the ledger.  There will always be a need to transform the the ledger data (if only because the DID Core Spec will evolve). To be determined where and how that transformation will occur.
• 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

• Last meeting we talked about the easy cases:
  • NYM and no ATTRIB
  • NYM and ATTRIB only with an "endpoint" URL.
• What about more interesting cases? Paulto facilitate the discussion.
  • See notes at the end of the HackMD Document
  • Do we do validation checking on the known ATTRIB raw types? yes - where possible
  • Where does the DIDDoc construction occur? Must happen on the ledger.

Future Discussions:

• DNR and DND discussions
•  DIDDocs:
  • What is the structure of the DIDDoc template - core and extensions?
• 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?