Summary
- Discovery of networks
- Given a DID, how to find it's network via gossiped ledger data
Recording from the call: 20201117 Indy DID Method Spec 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
- 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 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 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 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")
- 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 - presentation
- How to find previous versions of DIDs and what are the implementation ramifications of that?
- <did>?version-id=<txnid>
- <did>?version-time=<timestamp>