Skip to end of metadata
Go to start of metadata

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

Compare with Current View Page History

« Previous Version 6 Next »

Summary

  • Discovery of networks
    • Given a DID, how to find it's network via gossiped ledger data
  • Versioning

Recording from the call: <To Be Added>

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






  • No labels