You are viewing an old version of this page. View the current version.

Compare with Current View Page History

Version 1 Next »

Summary

  • Review: Discovery of networks
    • Given a DID, how to find it's network via gossiped ledger data
  • Handling DIDs / DIDDocs using NYMs / ATTRIBs

Recording from the call: 

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

  • TBD

Attendees

Collaboration Channels

Previous Discussions:

  • 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: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")
      • 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
    • Decentralized registries based on verifiable credentials
    • Other registry mechanisms, such as the DDNR proposal
  • did:indy will support version-id using txnID and version-time by returning the object active as of that time
    • Code will be needed to be added to did-indy to support that

Online Discussion (from RocketChat this week)

  • Not on Rocketchat, but there was a note that no change to the DID Spec would be needed for resolving "did:indy:<namespace>" to return metadata about the ledger.

  • A further suggestion could be made to find metadata about a ledger by resolving "did:indy:<namespace>:did:indy:<cross-reg namespace>" to return cross-register information
    • That DID would be resolved on the "did:indy:<namespace>" by using the namespace specific identifier "did:indy:<cross-reg namespace>"
    • TBD who that did is handled by the ledger to find the DIDDoc.

Discussion:

  • Review of last week:
    • See discussion below and highlight/make decisions
  • This week: DIDs / DIDDocs and NYMs & ATTRIBs


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?






  • No labels