-
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
Do we need a DID method-type feature (capturing new discussion) #152
Comments
@kdenhartog You are definitely correct that any DID namespace authority (aka DID method authority or DID governance authority) can create subnamespaces that by definition inherit the same DID method type, i.e., can use the same DID resolution code. So we don't need the concept of DID method types for that. Where we need it is if one top-level DID method namespace wants to use the DID method defined by another top-level DID namespace—for example to run it against a different instance of a DID registry. Here's a simple example. Say there are 3 DID namespace authorities who want to govern So rather than having to redo the same code (and the same DID method specs) three times, they want to collaborate and create one DID method spec for the method type, and then each of their own DID method specs would be instances that refer to that DID method type spec. You might ask, "Why do these three DID namespace authorities want their own top-level namespaces?" There can be many answers to that, but the one I'm seeing in the market is that each of these governance authorities wants to be "sovereign", i.e., not under the authority of some other governance authority. So for example, they might be three governments that all want to host Hyperledger Indy ledgers with nodes within their own respective countries, but each of them want to be the governance authority for their own Indy network, and not be under some other "meta-authority". The good news is that it should be quite easy to support this functionality by definiing a DID method type property, i.e., a single property in a DID document for the DID method namespace. I haven't submitted a PR for this yet; I'd planning to discuss it at the W3C DID WF F2F next week first. |
Ok, I get the general direction you're going with this. This becomes quite an interesting method to handle forks as well. I see now where you're heading with this. The main advantages I see to this is that it allows for different governance as you point out, which could be useful during fork splits. I think I'm likely to have additional questions around this thinking later, but in general at this point I'm in favor of this thinking. The primary question that will come up in my mind is how will the identifiers need to change. Right now, I see 2 potential good patterns and one bad pattern. The two good ones are to change the method name and a resolver architecture could allow a driver to claim multiple name spaces e.g. The final approach that I would be unfavorable of is the use of method specific matrix parameters. The main reason for this is that it makes a resolver more complex around the parsing of the identifier. I'm trying to reduce the complexity of that at this point because it already feels quite complex. Additionally, in my mind the mental model around matrix parameters feels like an optional aspect, where if network is indicated through the matrix parameter it makes it more like an extension to the identifier itself. Specifically what I mean by this is, let's say that I anchored |
I don't think the identifiers need to change. Instead, we should be rethinking what it means to map a did method identifier to a specific set of real-world actions. Right now, a resolver is allowed to do literally whatever it wants when it sees I've long argued that we need to be much more prescriptive with how resolution is handled if we want any hope of interoperability and extensibility at this layer. |
I don't really agree that a "method-type" feature is a good idea. In my opinion, sub-namespaces should be used for that, e.g. This has also been done with Ethereum-based DID methods, e.g. Since they all use the same technology and resolution code, they should all share the same DID method.
I can only see the marketing argument behind that. Let's call it the "I want my own DID method" (IWMODM) effect. In reality, the governments or authorities are under a "meta-authority" anyway, which is the Hyperledger project and the community around it. That meta-authority defines how the DIDs get created/updated/resolved/deactivated; the individual governments don't define that. They may each define their own governance/trust frameworks, but they all share exactly the same DID technology. The example of |
Very interesting. Is it not the case that a cluster of Hyperledger Indy ledgers are NOT the same technology though? I'm not an indy expert, but I believe that its the case that node operators are essentially controlling authorities... they decide which nodes they will talk to, what operations they will take, etc... If they were all part of the same network, I could see the case for making them all use the same namespace, but AFAIK each indy ledger network is its own kingdom, its a combination of the technology solution and the governance rules that creates a distinct network in indy correct? Can we provide some more concrete examples of specific indy ledger based dids that are anchored on separate networks that don't communicate? |
They all speak the same protocol; you can talk to all the instances using the same software (indy-sdk). The only technical differences are that 1. you use a different genesis transaction file for each, and 2. other minor configuration options. I would agree that governance may differ quite a bit, but my understanding of DID methods is that they are about technology, not governance. I don't think anyone would suggest that Bitcoin Mainnet and Testnet should be two different DID methods. Or the various Ethereum Testnets. Same with different Indy networks. I believe in the future there may be technologies where it could be argued either way (separate DID methods, or sub-namespaces), but I don't think that's the case with Indy. As I said I can understand the marketing value of having separate DID methods for each Indy instance, but I think that would be neither politically honest nor technologically accurate. |
I am NOT in favor of adding a method-type. IMO, a DID method is like a public blockchain (Bitcoin, Ethereum, Ethereum Classic...) Each DID method defines both the protocol rules and the initial state that prescribes how to map a particular DID And like a public blockchain, this also encompasses the governance that describes how changes can be made to the protocol rules for the DID method. Since a particular DID method controls the namespace, it is up to the DID method to define whether or not it can support testnet capabilities in the method-specific names or if testing needs to be done via a different DID method, (like |
I think we should be holding off on making a decision on this issue until the matrix parameters discussion is complete. |
* Clarify use of colon in method-specific-id. Addresses #98, #152. * Address comment by @davidlehn about use of colons. * Use hyphen in "method-specific". Co-Authored-By: Manu Sporny <msporny@digitalbazaar.com> Co-Authored-By: David I. Lehn <dil@lehn.org>
(Matrix) parameters discussion is scheduled for 26 March. |
From 2020-03-24 WG call: We are still waiting on the matrix parameters discussion to be closed before we can close on this. |
I don't think this issue has anything to do with matrix parameters. If two different DIDs in two different networks/ledgers/etc. are created, then the DIDs themselves have to be different, without using matrix parameters. My understanding is that this issue is only about the question what those two different DIDs would look like. Note that we recently added the following language in #215:
|
@peacekeeper the reason I believed that this was blocked by the matrix parameters discussion was because of Drummond's original proposal for how to handle this.
My interpretation of this was that @talltree was suggesting that rather than sub-namespacing (e.g. did:sidetree:ion:123) he was proposing that a method specific parameter would be used and the namespace would remain top level. e.g. did:ion:123;ion:resolve=sidetree While what I proposed is one method to handle this has been added in the text, @talltree was proposing a different method to handle the same functionality using parameters which allowed method authors to maintain top level authority of the namespace. It's worth noting as well for accurate representation that while I used a matrix parameter, what he's indicated could likely be handled with a query parameter as well. |
I think this has drifted significantly.... I'm not sure its concretely about anything at this point. |
please review: #152 (comment) |
-1 to a parameter that indicates where to find the DID -- that's what the DID method (embedded in the DID) and any method-specific resolution rules are for. It would not be interoperable to require a special parameter on a DID to say where to find it and would defeat one of the purposes of DIDs, IMO. This is fundamentally different, IMO, than specifying parameters to, for example, find some older version (vs. the current version) of a DID Document. |
I'm in favor of not implementing this in the spec and closing this issue. |
Agree, can we close this @cboscolo? There doesn't seem to be interest in broadly implementing this feature. |
I'm in favor of closing it as well. |
@talltree wrote:
@kdenhartog wrote:
@OR13 wrote:
The text was updated successfully, but these errors were encountered: