Page History

...

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

• Paul Bastian
• Stephen Curran

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

...

• Action: Add to the spec that only self-certifying DIDs will be permitted, and must be enforced – not enforced on Indy today.
• Third level names for subsidiary ledgers – e.g. Sovrin Staging and Sovrin Builder net?
  • We should use ":", but that creates lots of colons. So example is did:indy:sovrin:staging:<namespace-specific-id>
    • We SHOULD NOT allow subnamespaces other than by the top namespace "owner"
    • Perhaps other rules?
  • Andrew Whitehead mentioned in chat that "." is a valid character per the DID Spec. What about that?

    • did                = "did:" method-name ":" method-specific-id
      method-name        = 1*method-char
      method-char        = %x61-7A / DIGIT
      method-specific-id = *( *idchar ":" ) 1*idchar
      idchar             = ALPHA / DIGIT / "." / "-" / "_"

  • KERI: <namespace-specific-id> MAY have a "keri:" prefix for a future way of hosting a KERI identifier, example: did:indy:sovrin:staging:keri:<keri_id>
• How to find the nodes of the network once the ledger is known?  Perhaps this sequence, but how do we want to represent that in the DID Method Spec:.  Tentative idea – formally include at least the first, consider adding the second as well, and include informative text on the potential ways to go in the future.
  1. Config files,
  2. "human" gossiped names stored on the ledger - Daniel to produce a deck to explore the idea from nothing to networks
     1. Key pair - DID for the Indy DID Method for your network - "networks" - resolve the DID and you get the cross-registered list
        1. Extend to have the Trustee or Stewards DIDs be the ones to use for the "networks" elements of DIDDocs
        2. Must have a single hardcoded config file or way to resolve one DID (could use the universal resolver)
  3. decentralized registries
     1. Use of verifiable credentials - how can we use this to build this?
  4. protocol for cross-registration – how do you do this?
• How to find previous versions of DIDs and what are the implementation ramifications of that?
  • <did>?version-id=<txnid>
  • <did>?version-time=<timestamp>

...