Summary

Recording from the call: 

Welcome and Introductions

Announcements

• TBD

Attendees

• @Stephen Curran

• @Markus Sabadello

• @Dan Gisolfi

• @Paul

• @Kamlesh Nagware

• @Alexander Jonsson

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

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.

• Drummond to lead documenting this process in a new section of the HackMD.io doc

Discussion:

• Review of last week:

  • See discussion below and highlight/make decisions

• This week: DIDs / DIDDocs and NYMs / ATTRIBs

  • Proposal from Paul Bastian – in hackmd.io document – "Alternative Version" section

  • Proposal from @Kyle Den Hartogin the HackMd.io document – presentation

  • Discussion summary:

    • No one likes the "don't change" Indy limitation – we'll have to change Indy to ensure consistency.

      • No on likes the possibility of inconsistent results from non-transactional (in the database sense) updates to separate ledger objects.

    • Desire is to have the NYM controller information in the DIDDoc either by the ledger verifying it is there or by injecting it during the writing or resolution.

      • This is for adherence to the DID Spec and for security – to make clear in the DIDDoc the controller rules.

      • If the DIDDoc has in it multiple signature requirements, does Indy enforce that? How would that merge with Indy permission rules (e.g. endorser+author to write object)

    • Need to make sure that an ATTRIB-less NYM continues to resolve to a DIDDoc – can't lose that.

      • Suggestion made that an ATTRIB-less NYM return a DIDDoc conforming to (or aligning with) the did:key specification.

    • Debate: Should a DIDDoc be assembled from just the ATTRIB, from the NYM+latest(ATTRIB) (could be a specific ATTRIB version) or from the NYM+set(ATTRIBs)?

      • General feeling is not just the ATTRIB – can't separate out the NYM controller information 

      • My feeling is that assembling for a set of DIDDocs makes resolution more complex than necessary. For example, this requires rules about how to replace sections when merging ATTRIBs. Doable, but requires complexity that I think is unnecessary.

    • Debate: Does any assembly of the DIDDoc occur by the ledger, or does the ledger return the pieces to an external resolver that assembles the DIDDoc?

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?