Do we need a DID method-type feature (capturing new discussion)

[cboscolo]

@talltree wrote:

BTW, this thread brings up another DID feature that is not yet on our list, but which I'm now seeing several communities needed: DID method types. This is the ability for one DID method to re-use the code defined for another DID method, just in a different DID method namespace (meaning it has a different governance authority and/or target DID registry).

This would enable a whole family of DID methods to reuse the same resolution code while having different DID method names.

@kdenhartog wrote:

In short though, I was of the understanding method type works as follows:
did::{:method-specific-identifier} where the method-type falls under the namespacing ABNF of the method. In this case what this means is that method indicates the process by which the identifier is de-referenced to the did document, and the method-type falls under the scope of the authority of the method.

I've seen some of this functionality supported via the universal registrar e.g. did:sov:danube:968zF324uXTLGzWpFqcTYg. Of note, some did methods are doing this via namespacing like is done in the sov example, while things like sidetree have opted for their own namespacing authority. From an implementation standpoint, this makes sense how our identifiers ended up this way because the sovrin method is reusing the indy-sdk, but connecting to different pools, where as with sidetree, there's two separate implementations that couple the network to anchor transactions with the implementation which led to the implementer's to opt for did:ion and did:elem rather than did:sidetree:ion and did:sidetree:elem. Note, it doesn't have to be done this way but as it stands this is what's implemented - element is a separate codebase which doesn't depend on the sidetree protocol library.

@OR13 wrote:

It would be more accurate to say did:elem does not depend on did:ion codebase, we both depend on the sidetree spec... which is not a codebase, but a protocol definition, the fact that a typescript library exists for implementing that spec (in the same repo), and that ion uses it and element does not is what you are getting at... This is similar to how many different implementations exist for HTTP servers, with varying degrees of support for HTTP spec features, and some amount of shared components (like use of the http module in a node js example).

I would not be opposed to taking a nested prefixing approach for sidetree, but thats a separate issue.

[talltree]

@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 did:111:, did:222:, and did:333:. But they all plan to use a Hyperledger Indy ledger and the same resolution code. They just have different governance frameworks for the Indy ledger networks that these DID namespaces will operate against.

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.

[kdenhartog]

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. did:sov driver could claim did:sov and did:kiva. The other one I could see working is the nested prefixing approach. e.g. did:sidetree:elem and did:sidetree:ion. From an implementation standpoint, I think the driver would do the same as before where it would claim multiple namespaces, or could be setup to be different drivers (because they're talking with different networks). I think both approaches will be used because the former approach works well if the split is decided from the outset (e.g. there is two separate indy networks), where as the latter approach works well for managing forks.

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 did:sov:123 to network 1 and network 2. Then this means I can have a split in state by trying to resolve did:sov:123;network=1 vs did:sov:123;network=2 which means the matrix parameter is required to identify the different metadata I want - even if I still am referring to the same entity (hence did:sov:123 remains the same).

[jricher]

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 did:sov, but we can put normative requirements on it such that there's exactly one way to resolve a did:sov URL. The fact that you use the same method to do did:kiva is an artifact that comes from this pattern.

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.

[peacekeeper]

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. did:sov:kiva:..., did:sov:findy:..., etc.

This has also been done with Ethereum-based DID methods, e.g. did:erc725:ropsten:..., did:erc725:rinkeby:... that simply use different instances of Ethereum.

Since they all use the same technology and resolution code, they should all share the same DID method.

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".

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 did:ion and did:elem is something else, in this case they use some common technical components but also differ quite a bit (they use different ledgers, etc.). So here we have different DID methods. Deploying the same technology multiple times however does not constitute different DID methods.

[OR13]

Deploying the same technology multiple times however does not constitute different DID methods.

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?

[peacekeeper]

Is it not the case that a cluster of Hyperledger Indy ledgers are NOT the same technology though?

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.

[cboscolo]

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 did:foo:xyz123 to a particular DID Document. For foo if you follow the protocol rules and initial state defined for the foo method, you can perform this mapping from foo DID to DID-Document.

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 foo-test).

[kdenhartog]

I think we should be holding off on making a decision on this issue until the matrix parameters discussion is complete.

[burnburn]

(Matrix) parameters discussion is scheduled for 26 March.

[talltree]

From 2020-03-24 WG call: We are still waiting on the matrix parameters discussion to be closed before we can close on this.

[peacekeeper]

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:

The method-specific-id format MAY include colons, which might be used by DID methods for various purposes, such as establishing hierarchically partitioned namespaces, or identifying specific instances or parts of the DID registry.

[kdenhartog]

@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.

I too agree that method-specific parameters (MSP) should be avoided whenever there's another easier solution. However not all MSP affect resolution or dereferencing. If the MSP is simply something that's passed on, it should not be a concern of the resolver code.

BTW, this thread brings up another DID feature that is not yet on our list, but which I'm now seeing several communities needed: DID method types. This is the ability for one DID method to re-use the code defined for another DID method, just in a different DID method namespace (meaning it has a different governance authority and/or target DID registry).

This would enable a whole family of DID methods to reuse the same resolution code while having different DID method names.

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.

[OR13]

I think this has drifted significantly.... I'm not sure its concretely about anything at this point.

[OR13]

please review: #152 (comment)

[dlongley]

-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.

[OR13]

I'm in favor of not implementing this in the spec and closing this issue.

[msporny]

Agree, can we close this @cboscolo? There doesn't seem to be interest in broadly implementing this feature.

[cboscolo]

I'm in favor of closing it as well.
@talltree I recall opening this issues in response to a comment you made on another thread. Please reopen if you feel it should be.