-
Notifications
You must be signed in to change notification settings - Fork 94
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
How should contributors register the same DID Method on multiple networks? #478
Comments
@peacekeeper can you add links? |
@talltree , I've heard you articulate your thinking on this. Do you have any written summary you could share here? |
@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 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? |
Thanks @peacekeeper, I had forgotten about that closed issue (you have a positively encyclopedic memory of DID issues!) |
@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
A while ago I worked on the "erc725" method which did exactly the same in its syntax specification (see here):
The "btcr" method doesn't use colons, but still encodes a network identifier in the
We added some language to DID Core to explain this in #215 to say that colons in the Apparently this particular wording was removed again in #319 by @rhiaro. I wonder if there was a good reason to remove it; I think this wording should be added back in. |
Another place where this was discussed is decentralized-identity/ethr-did-resolver#27 |
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? |
@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.) |
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
DID Method Subamespaces
In this case, the authorities for the
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 ***** |
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 I don't understand how this makes the DID namespace more centralized. I think it makes it less centralized, since only 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. |
@rhiaro I think that would be great, since there had been quite a bit of discussion that led to the language in #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 #319 did a really good job improving this section! |
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. |
@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. |
@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 Thus my suggestion for the other approach of publishing an abstract DID method spec. |
@talltree from a security / governance perspective, I would be concerned about the damage from a poorly configured network... for example:
If you don't put the subnetwork in the identifier... when a subnet goes down a percentage of all 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 |
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/ |
@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. |
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 #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 |
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 #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 |
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 #387). So I think we should close this. But @talltree should also comment. |
Agree this should be closed. |
There is not action on this issue, its assigned to me, I am marking it pending close, since its a question asked and answered. |
It has been 8 days since this issue was marked pending close... there have been no objections, closing. |
Some related conversation in the sidetree / ethereum ecosystem: decentralized-identity/element#207
There has been discussion in the Indy community regarding best practices for this.
We should provide guidance in DID Method Registry regarding this.
The text was updated successfully, but these errors were encountered: