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
- Current hackmd document
- indy-did-method on RocketChat - https://chat.hyperledger.org/channel/indy-did-method
- indy-did-method repo
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
- Ledger with no subsidiary name, example:
- 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)
Discussion:
- Review of last week:
- See discussion below and highlight/make decisions
- This week: DIDs / DIDDocs and NYMs & ATTRIBs
- Proposal from ?? (sorry - didn't write down who)
- Proposal from Kyle Den Hartogin the HackMd.io document – presentation
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.
- A "network metadata" DID embedded in the config file.
- 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?
- Proposed options for finding the "Network Metadata DID(s)" with the network listings:
- 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?
- For cross-registered networks, an array:
- 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?
- 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