How should contributors register the same DID Method on multiple networks?

[OR13]

Some related conversation in the sidetree / ethereum ecosystem: https://github.com/decentralized-identity/element/issues/207

There has been discussion in the Indy community regarding best practices for this.

We should provide guidance in DID Method Registry regarding this.

[OR13]

@peacekeeper can you add links?

[dhh1128]

@talltree , I've heard you articulate your thinking on this. Do you have any written summary you could share here?

[talltree]

@dhh1128 Indeed I have said I wanted to submit a PR to add a few paragraph to the DID Method section of the DID spec to provide this guidance. I haven't written it yet, but this thread is a good a chance as any to get it started.

First, some background. I had originally thought of proposing a DID document property called method-type that could be used in a special DID document for the DID method itself (since all DID method names need to be unique). However after discussion with several DID method authors, we agreed that approach was too heavyweight.

A better solution would be to simply to provide guidance to DID method specification authors that they could collaborate on an abstract DID method specification that could then be referenced by multiple concrete DID method specifications who all wanted to share the same resolution code, just instantiated with different config data for each instance.

So here is a rough first draft of possible text for the DID Method section of the DID spec:

Abstract DID Method Specifications

In some cases, multiple DID method specification authors may wish to use the same basic DID method to access multiple instances of the same verifiable data registry technology. In these cases, the only technical differences in the methods are: a) the DID method names, and b) the configuration metadata needed by a DID resolver to access a particular instance of a compatible verifiable data registry.

In these cases, it is RECOMMENDED that the DID method specification authors collaborate on producing an abstract DID method specification that can then be referenced by multiple concrete DID method specifications. The abstract DID method specification SHOULD specify everything necessary to implement a DID resolver (or a code module for a pluggable DID resolver) for the abstract method except: a) the DID method name, and b) the configuration metadata necessary to access a specific instance of a compatible verifiable data registry. However the abstract DID method specification SHOULD specify exactly what configuration metadata should be specified in a compatible concrete DID method specification.

The concrete DID method specifications SHOULD then reference the abstract DID method specification and only need to specify the DID method name and the configuration metadata necessary to access a specific instance of a compatible verifiable data registry.

DID resolver implementers SHOULD be able to implement only one instance of the code necessary to support the abstract DID method specification. This code SHOULD be configurable to use a specific compatible verifiable data registry using only the configuration metadata supplied in a concrete DID method specification.

END PROPOSED TEXT

Feedback?

[peacekeeper]

@talltree

I had originally thought of proposing a DID document property called method-type

For reference, this was discussed in https://github.com/w3c/did-core/issues/152.

[talltree]

Thanks @peacekeeper, I had forgotten about that closed issue (you have a positively encyclopedic memory of DID issues!)

[peacekeeper]

@talltree's earlier idea of "method types" and more recent idea of "abstract methods" would allow people to have their own DID method that would share and re-use specifications and code of another DID method. I have been initially critical of this, since I felt the meaning of a "method" is to encapsulate the DID syntax and how DID operations work. If the syntax and operations work essentially the same way, only on a different network, then I don't think that's a different "method". On the other hand, in the interest of not limiting innovation, my understanding of @talltree 's position has increased slightly :)

The more "traditional" way of supporting multiple networks is to use colons in the method-specific-id, e.g. see @OR13 's examples in https://github.com/decentralized-identity/element/issues/207#issuecomment-668146295:

did:elem:ropsten:...

A while ago I worked on the "erc725" method which did exactly the same in its syntax specification (see here):

did:erc725:ropsten:...

The "btcr" method doesn't use colons, but still encodes a network identifier in the method-specific-id, e.g. even though it's not human-readable, the following DID includes the information that it is resolvable on Bitcoin Testnet, not Mainnet or elsewhere:

did:btcr:x705-jznz-q3nl-srs

We added some language to DID Core to explain this in https://github.com/w3c/did-core/pull/215 to say that colons in the method-specific-id can be used for purposes such as establishing hierarchically partitioned namespaces, or identifying specific instances or parts of the verifiable data registry.

Apparently this particular wording was removed again in https://github.com/w3c/did-core/pull/319 by @rhiaro. I wonder if there was a good reason to remove it; I think this wording should be added back in.

[peacekeeper]

Another place where this was discussed is https://github.com/decentralized-identity/ethr-did-resolver/pull/27

[rhiaro]

I wonder if there was a good reason to remove it; I think this wording should be added back in.

I was trying to reduce this section to normative language that can be easily scanned by someone evaluating whether a DID method meets all the requirements of the spec and this got lost in the shuffle. I can make a PR to add it back in as a note, or in parentheses after the bit about colons?

[dhh1128]

@talltree Everything you said makes sense to me, but I'm surprised to see it not touching on the issue of a centralized registry. I had been under the impression that you were troubled by the centralization of a DID method registry because it created a registrar problem similar to DNS. Is that no longer a concern for you? (If it's not, that's okay by me. I am just checking.)

[talltree]

I wonder if there was a good reason to remove it; I think this wording should be added back in.

I was trying to reduce this section to normative language that can be easily scanned by someone evaluating whether a DID method meets all the requirements of the spec and this got lost in the shuffle. I can make a PR to add it back in as a note, or in parentheses after the bit about colons?

I agree that the option of using subnamespaces under a DID method name is one way for multiple verifiable data registries to share the same DID method. However, as @dhh1128 points out, that approach requires multiple DID method spec authors to not only agree on a DID method namespace and spec, but to adopt some form of governance over the namespace—which takes us right back to centralized registries.

For a small number of DID methods in a highly cooperative community, that approach might be fine. However a more decentralized approach would be to write an abstract DID method that does not require any cooperation on DID method subnamespaces.

So, to @dhh1128's point, here's an update to my proposed text to incorporate all those thoughts:

Reusable DID Methods In some cases, multiple DID method specification authors may wish to share the same basic DID method to access multiple instances of the same type of verifiable data registry. This has the advantage of allowing one resolution code module to be shared across multiple methods (if such an efficiency is desired). There are two basic options for accomplishing this:

1. DID method subnamespaces
2. Abstract DID method specifications

DID Method Subamespaces The first option is for the DID method specification authors to collaborate on a DID method that supports colon-delimited subnamespaces under a shared top-level DID method name. For example, the following are subnamespaces of the DID method did:example: (where the "..." is replaced by the type of method-specific identifier specified by the hypothetical did:example: method specification):

• did:example:foo:...
• did:example:bar:...
• did:example:baz:...

In this case, the authorities for the did:example:foo:, did:example:bar:, and did:example:baz: namespaces SHOULD:

1. Collaborate on one DID method specification for the did:example: method name, and
2. Register the configuration metadata necessary to access their respective subnamespaces, either directly in the did:example: method specification, or in some type of namespace registry specified in that specification.

Although this approach to sharing a DID method is straightforward and requires writing only one DID method specification, it does reintroduce a centralized namespace that must be shared across the subnamespace authorities.

Abstract DID Method Specifications

A second, more decentralized approach is for multiple DID namespace authorities to collaborate on producing one abstract DID method specification that can be referenced by multiple concrete DID method specifications.

In this approach, the abstract DID method specification SHOULD specify everything required by the concrete instances except: a) the DID method name, and b) the specific configuration metadata needed by a DID resolver to access a particular instance of a compatible verifiable data registry.

The abstract DID method specification SHOULD provide a precise list of what configuration metadata MUST, SHOULD, and MAY be included in a concrete DID method specification based on that abstract DID method.

DID resolver implementers SHOULD be able to implement only one instance of the code necessary to support the abstract DID method specification. This code SHOULD be configurable to use a specific instance using only the configuration metadata supplied in a concrete DID method specification.

END PROPOSED TEXT

[peacekeeper]

I don't think anyone would suggest that BTCR on Mainnet and BTCR on Testnet are two different DID methods with two different DID method specifications. This is one DID method, and the DID method specification authors have to define how to distinguish between the different networks (e.g. by using colons, or in some other method-specific way).

In the same manner, the Indy community should also have one DID method specification did:indy and define how to differentiate between networks, e.g. did:indy:mainnet:..., did:indy:bedrock:..., did:indy:findy:..., did:indy:lissi:.... Although each one of these networks may have different governance rules, the underlying DID method technology and the resolver code is always the same. These networks are not independent, their underlying technology is controlled by the same set of entities (Hyperledger Indy, Trust-over-IP).

I don't understand how this makes the DID namespace more centralized. I think it makes it less centralized, since only did:indy: would be added to the W3C DID spec registries, and everything underneath it would be delegated to the Hyperledger Indy / Trust-over-IP community. If each instance of a given network technology had its own DID method, then all of them would have to be added into the centralized W3C DID spec registries, instead of this specific community self-governing its own DID method namespace.

This isn't what DID methods were meant for. I just can't see a good reason for this except marketing (I want my own DID method!). I don't think the abstract DID method approach should be "prohibited", I just don't think it's the preferred approach.

[peacekeeper]

I can make a PR to add it back in as a note, or in parentheses after the bit about colons?

@rhiaro I think that would be great, since there had been quite a bit of discussion that led to the language in https://github.com/w3c/did-core/pull/215. So yes maybe adding it back as a note, or just adding it to the existing note "Colons in method-specific-id" would be a good idea. BTW other than this I think your PR https://github.com/w3c/did-core/pull/319 did a really good job improving this section!

[msporny]

I don't think the abstract DID method approach should be "prohibited", I just don't think it's the preferred approach.

Agreed. If you have a DID Method that functions on different networks using exactly the same protocol, it's still the same DID Method, just operating on a different network. did:v1 has a network indicator following did:v1:NETWORK -- we may want to go as far as saying that doing so is a best practice (since other DID Methods do exactly the same thing to specify on which network they're operating).

[talltree]

I don't understand how this makes the DID namespace more centralized. I think it makes it less centralized, since only did:indy: would be added to the W3C DID spec registries, and everything underneath it would be delegated to the Hyperledger Indy / Trust-over-IP community. If each instance of a given network technology had its own DID method, then all of them would have to be added into the centralized W3C DID spec registries, instead of this specific community self-governing its own DID method namespace.

@peacekeeper I think my use of the word "centralized" may have been misleading. Yes, the W3C DID Spec registry is centralized, but right now it's the only centralization point involved with DIDs. What you are suggesting is that verifiable data registries who share the same DID method protocol with different VDRs should be forced to have to collaborate on a shared namespace, i.e., a second centralization point (requiring a second level of governance).

All I'm saying is that, while that option is fine for those who want to use it, it should not be required as the only way to share a DID method protocol. The other option of using an abstract DID method spec should be fine too.

As a practical matter, I am 99% certain that the different VDR governance authorities who plan to share a Hyperledger Indy DID method will not agree to all register in a subnamespace. It's not a "marketing" decision, it's a "sovereignty" decision. So it would be quite ironic if the DID spec did not suggest an option a way each of those VDRs can be self-sovereign.

See also my response to @msporny below.

[talltree]

Agreed. If you have a DID Method that functions on different networks using exactly the same protocol, it's still the same DID Method, just operating on a different network. did:v1 has a network indicator following did:v1:NETWORK -- we may want to go as far as saying that doing so is a best practice (since other DID Methods do exactly the same thing to specify on which network they're operating).

@msporny That makes sense when those subnets are all under the control of the same governance authority. I have no problem with suggesting that as a best practice in that case—as you say, that's what Veres One does, and that's what the Sovrin Foundation does with its subnets.

But what I don't think you're accounting for is when independent (and possibly competing) VDR governance authorities wanting to share the same DID method protocol, just using it with different VDR instances. This is the case right now with the Hyperledger Indy community, where they are looking at 5+ new Hyperledger Indy networks coming up over the next year. While it is theortically possible that those different governance authorities might decide to collaborate under one did:indy: namespace, I think there's near-zero chance of that in practice.

Thus my suggestion for the other approach of publishing an abstract DID method spec.

[OR13]

@talltree from a security / governance perspective, I would be concerned about the damage from a poorly configured network... for example:

did:indy:foo makes it clear that foo was responsible for this particular configuration... the network itself is part of the security properties of a did method... for example: did:ethr:ropsten inherits from the security properties of ropsten ethereum testnet, which can go down / get destroyed at any moment....

If you don't put the subnetwork in the identifier... when a subnet goes down a percentage of all indy or ethr dids are destroyed... folks will come to view that as an indication of failure for the method as a whole, not just a particular network.

TL;DR; in order to protect the reputation of a DID Method, you need to prevent poor deployments from being indistinguishable from good ones.

What is the other option? I assume its just not reusing a did method at all... in which case, there will be many variations of indy but all called different things, based on the governance associated with them? IMO thats also fine, and preferred to reusing indy but then not having them share governance.

[peacekeeper]

Just a quick note that there was some great discussion about this topic in the Indy Interop-athon this week, the agenda has presentations and session notes: https://wiki.hyperledger.org/display/II/Agenda

E.g. see these slides by @talltree and myself about "One DID Method to rule them all": https://docs.google.com/presentation/d/1WbHU6wtMbZUZZbGHQc1GMa0ihrD11sfqM8AlxSQr1Ak/

[OR13]

@peacekeeper @talltree @csuwildcat seems like it might be helpful for us to describe this issue in an appendix of did-core / somewhere.... I am eager to here more about where indy lands on this.

[kdenhartog]

We're actively discussing this and it seems we're going to go the direction of sub-namespaces while also hopefully using hashes of network txn/genesis txn file (To be decided) so we don't have to govern the namespace.

Curious with https://github.com/w3c/did-core/pull/387 being merged already do we want to close this or should it still be moved to did-core? I assume we aren't going to be able to add much more other than what was added in that PR before CR freeze. Thoughts @talltree

[kdenhartog]

Moving this to did-core where we can decide what to do next with it. On one hand, I believe this feature would fall outside feature freeze and we shouldn't be addressing it in the DID-Core spec. However, it could be argued that this is a continuation of https://github.com/w3c/did-core/issues/152 and so we can still address it (152 stated the feature didn't have enough adoption to complete and was closed).

Let's figure this out over here. Could the chairs weigh in on this? @brentzundel @burnburn

[peacekeeper]

I believe that most implementers are now favoring a design that doesn't consider multiple instances of the same technology/network to be different DID methods, but actually use a single DID method with multiple colons in the method-specific-id (as described in https://github.com/w3c/did-core/pull/387).

So I think we should close this. But @talltree should also comment.

[OR13]

Agree this should be closed.

[OR13]

There is not action on this issue, its assigned to me, I am marking it pending close, since its a question asked and answered.

[msporny]

It has been 8 days since this issue was marked pending close... there have been no objections, closing.