Page History

...

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

...

• Serialization formats

This Week's Discussion:

...

• Naming of non-NYMs to include the namespace

...

• At risk – DNR/DND

...

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

Future Discussions:

• 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?
    Handling existing objects on the ledger as DIDDocs?
    • • Could be used to reference non-NYM objects on an Indy ledger – eg. for a schema `did:indy:sovrin:<schemaID>?resource=true` where the `resource=true` is used to indicate that a DIDDoc will not be returned but instead the Schema Object.
        • The `<schemaID>` component might be the seqno, and it might be the extended schema ID (e.g. `<dest NYM ID>:schema_name:<tag>`)
          • Note that in the extended version, the <dest NYM ID> is itself an identifier (a DID) for the Schema writer, and if we want to support the use case of the DID of the writer possibly existing on another ledger, there are actually two identifiers therein, and hence, the possible need for two namespace indicators.  This is unlikely to be an concern with schema and the DID writer (not permitted), but is definitely a concern with CLAIM_DEF where a component of the extended ID is the ID of the schema, which could be on another ledger.
      • Could be used to reference external resources via a DID, such as a governance document.
        • Suggestion was to use the DIDDoc "alsoKnownAs" field to reference the external resource, or an ATTRIB that contains the resource.
        • For example, an ATTRIB might contain an encoded version of the resource – e.g. compressed, base-64 version of the Governance Framework PDF.
    • Not sure yet how existing transactions would be handled?
      • Is this just an Indy-SDK/Indy-VDR issue in the handling of embedded references in (for example) proof requests?
  • 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.

  ...