...

...

Summary

Recording from the call: 

...

20201124 Indy DID Method

...

Specification Call Recording

...

...

Welcome and Introductions

Announcements

• TBD

Attendees

• Stephen Curran
• Paul
• Alexander Jonsson  (Laniakea Health) <alex@laniakeahealth.com>
• 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

Previous Discussion:

• 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 placehold 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 no subsidiary subsidiary name, example: did:indy:sovrin:staging:keri: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")
  • Decentralized registries based on verifiable credentials
  • Other registry mechanisms, such as the DDNR proposal

Online Discussion (from RocketChat this week)

Discussion:

• Discussion led by Daniel Hardman about how to implement the gossiping mechanism via "networks" ledger DIDs -
  • Daniel Hardman presentation
  • DID Namespace DID: https://github.com/WebOfTrustInfo/rwot8-barcelona/blob/master/topics-and-advance-readings/did-namespace-records.md
• How to find config files in a centralized place?
  • ToIP, DIF, OrgBook for networks
  • Folder where the spec is – indy-did-method repo
• How to find previous versions of DIDs and what are the implementation ramifications of that?
  • <did>?version-id=<txnid>
    • Return the txnid as part of DID resolution so it can be included in URIs
  • <did>?version-time=<timestamp>
    • Indy does do timestamping - coarse:
      • tracked as part of consensus to (a) within 5 minutes (b) batch time greater than the last one
      • leader node picks, but vetted by other nodes, understanding that the leader node's time could drift.
    • How to do time based querying?
      • Probably not indexed
      • Could do binary search querying of the txnids
    • Code needs to be written to do this.

Summary - Cross-Registering Networks on a Ledger

• Start with a config file for one or more networks
  • The config file will contain at least the pool transactions for the ledger – could contain more; see below
• On the ledger will be one or more DIDs that have associated "Network Metadata" information that includes (and might be limited to) information about cross-registered networks.
  • Proposed options for finding the "Network Metadata DID(s)" with the network listings:
    • A "network metadata" DID embedded in the config file.
      • Proposed that writing to the DID would be controlled, such as by a Trustee or some other config rules.
    • Could be found via resolving "known DIDs" so that knowledge of the "special" DID is not needed:
      • DIDs of each Trustee on the network (requires search by role)
      • DIDs of each Steward on the network (requires search by role)
      • A DID with a new "Network Metadata" role (requires search by role)
        • Same as putting the DID in the config file, but this enables finding it by role.
      • Resolving the "namespace DID" (e.g. DID with no ledger specific identifier). Requires change to DID Core Spec.
  • Decision: DID in Config File, Trustee DID, Steward DID, New Role DID, Namespace DID
    • Impact: What code needs to be written?
    • Impact: If trustee or steward DIDs – what processing rules should be applied?
• Decision: Does the network metadata go into an ATTRIB, or does it go into the DIDDoc associated with the DID?
• Data associated with the "Network Metadata" DID(s):
  • For cross-registered networks, an array:
    • Namespace
    • Pool Transactions file contents or
    • Location of Pool Transactions file
  • Metadata about the ledger
    • Link to Governance Framework information
    • Other?
  • Decision: What categories of data should go into a DID holding Network Metadata?
  • Decision: What is the exact format of the data?
• Centralized publishing of ledger config files
  • All the publishing of ledger config files in a known place – e.g. github – and under the control of an entity such as Hyperledger or DIF
    • This is centralized control because the maintainers accept the PRs that update the data
  • Decision: Do we want to propose a location to publish config files?
  • If yes, Decision: Where?