Summary

Identifiers with naming for non-NYM ledger objects
Serialization formats - use JSON?

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

Stephen Curran

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)

Serialization formats

This Week's Discussion:

Note: Work from Gimly (Jack Tanner) on "DID verifiable conditions" – e.g. "N of M signatures to update a DID" – https://github.com/Gimly-Blockchain/verifiable-conditions
Other Indy Ledger Objects as DIDs (e.g. schema, etc):
- Code and documentation:
  - https://github.com/hyperledger/indy-node/blob/master/indy_node/server/request_handlers/read_req_handlers/get_claim_def_handler.py
  - https://github.com/hyperledger/indy-node/blob/master/docs/source/requests.md
- Rule: Only allow cross-ledger references for DIDs and SCHEMA – all other ledger references are assumed to be on the same ledger
  - All objects must be on the same ledger as their creating controller
  - CLAIM_DEFs may reference SCHEMA on the same or another ledger
  - REV_REG_* objects must be on the same ledger as the related CLAIM_DEF
- Identifier adjustments:
  - ```
  NYM: did:indy:sovrin:staging:F72i3Y3Q4i466efjYJYCHM
```
- Schema: "F72i3Y3Q4i466efjYJYCHM:2:npdb:4.3.4" (<nym_id>:<object type>:<name>:<tag>)
  - How do we get a namespace into the identifier?
    - I think changing the <nym_id> to a <did> would resolve it.
      did:indy:sovrin:staging:F72i3Y3Q4i466efjYJYCHM:2:npdb:4.3.4
      Alternative: did:indy:sovrin:staging:SCHEMA:F72i3Y3Q4i466efjYJYCHM:2:npdb:4.3.4
      did:indy:sovrin:staging:56495 Resolver: did:indy:sovrin:staging:56495?resource=true
    - That would make it look like a DID, even though the DID is just a component.
      Do we auto-detect the "type of DID"?
      Presumably if "?resource=true" returns the ledger object, but what if that query parameter is left off? Do we just return the DIDDoc of the DID?
- CLAIM_DEF: "5nDyJVP1NrcPAttP3xwMB9:3:CL:56495:npdb" (<nym_id>:<object type>:<signature_scheme>:<schema_txn>:<tag>)
  - Note how the SCHEMA is referenced in the CLAIM_DEF identifier – as a transaction ID.
  - Changes:
    - Change <nym_id> to <did>
      did:indy:sovrin:5nDyJVP1NrcPAttP3xwMB9:3:CL:56495:npdb
      Alternate: did:indy:sovrin:CLAIM_DEF:5nDyJVP1NrcPAttP3xwMB9:3:CL:56495:npdb
    - Change <schema_txn> to either
      <schema_txn> (no change when on same ledger)
      did:indy:<namespace>:<schema_txn> (different ledger)
      did:indy:sovrin:5nDyJVP1NrcPAttP3xwMB9:3:CL:did:indy:idunion:56495:npdb
      <DID of controller>:<object type>:<signature_scheme>:<ledger of schema_txn>:<tag>
      Alternate: did:indy:sovrin:CLAIM_DEF:5nDyJVP1NrcPAttP3xwMB9:3:CL:did:indy:idunion:SCHEMA:56495:npdb
    - Add Sequence Number DID version:
      did:indy:<namespace>:<seqno>?resource=true
      Do we need to also provide a DIDDoc version of the objects? What would that look like – especially if we have to provide it as JSON-LD
- No Changes:
  - REVOC_REG_DEF: "5nDyJVP1NrcPAttP3xwMB9:4:5nDyJVP1NrcPAttP3xwMB9:3:CL:56495:npdb:CL_ACCUM:TAG1" (<nym_id>:<ver>:<cd_nym_id>:<ver>:<sig>:<seqno>:<?>:<?>:<tag>)
  - REVOC_REG_ENTRY: "5:5nDyJVP1NrcPAttP3xwMB9:4:5nDyJVP1NrcPAttP3xwMB9:3:CL:56495:npdb:CL_ACCUM:TAG1" (<?>:<nym_id>:<ver>:<cd_nym_id>:<ver>:<sig>:<seqno>:<?>:<?>:<tag>)

JSON vs. JSON-LD
- 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. .
The "close-to-finished" DID Method Spec – please review
- Perhaps not close to finished – doesn't talk about other objects yet – the conversation above
- At risk – DNR/DND

Future Discussions:

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.
- Daniel Hardmanwants to discuss this further, so that we consider JSON.
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.