RE: Can we keep did-method as a variable in the spec?

Hey Daniel,

Thank you for your response, yes this makes more sense,  the reason we did not want to put “hypersign” as a primary method name is because zones might be reluctant to use our “branding”.  We have previously face this kind of problems with identity wallets as well, customers do not want to use your branding, hence we need to whitelabled it for them.  But yeah “did:cosmos:<zones>” makes sense to me since all of these zones are from cosmos ecosystem and we would be one of them. 

--

Vishwas Anand Bhushan 
Co-Founder @ Hypermine Technologies | R&D Engineer
Building Hypersign – An interoperable decentralized identity blockchain network 

From: Daniel Hardman
Sent: 17 February 2022 16:23
To: Vishwas Anand
Cc: public-did-wg@w3.org; Vikram Bhushan; Irfan ッ Khan; abhijit sinha
Subject: Re: Can we keep did-method as a variable in the spec?

This is essentially the same problem that Hyperledger Indy has explored. There are many deployments of Indy; we wanted one DID method that could support all of them, where the set of new deployments is dynamic.

I think the solution you have imagined is somewhat out of harmony with the DID method spec, because you are reserving large amounts of namespace directly after "did:", in advance. What happens if someone writes a DID method named "foo" and then a Cosmos zone wants to use the name "foo"? The DID method spec says that each method controls content after "did:" PLUS their method name -- not just after "did:" itself.

A slight variation on your idea, that might work better, is to use "cosmos" as your method name, and then to follow it with zone and network:

did:cosmos:<zone>:<network>:rest.

--Daniel

On Thu, Feb 17, 2022 at 10:38 AM Vishwas Anand <vishwas@hypermine.in> wrote:
Hi all, 
 
We are building Hypersign using Cosmos SDK whose purpose it to manage digital identities in Cosmos ecosystem and any other zone should be able to resolve DID via IBC bringing interoperability within zones. We are going through W3C spec and are in the process for defining our did method and registering it in the W3C did registry. We have some confusion regarding this which we would like to clarify. 
 
The Cosmos ecosystem consists of application specific blockchains, called zones. These blockchains/zones are for specific purpose, built for one use case. We can visualize each smart on Ethereum being a separate blockchain having its own governance. Any one can build a zone using Cosmos SDK which provides base framework for building a chain and then one can implement their use case on top of this SDK. The Cosmos Zones also have way to interact with each other using a tech called IBC – Inter Blockchain Communication. 
 
At first glance it looks like Hypersign going to be a centralized blockchain which will manage DIDs for all zones in the cosmos ecosystem. But the way we are visualizing is, once we have built the SSI module properly for our zone, we will request Cosmos SDK to merge this module as a native module. This way any zone can enable SSI  module in their network. I believe that in future there will be multiple registstires instead of one centralized place for DIDs. A issuers may exists on zone 1 whereas a verifier may sits on zone 2 and vice verse.  DIDs issued on one zone can be resolved on the other to achieve interoperability. We feel this would be great step towards the adoption of SSI  technology. 
 
The problem is, if a zone need to become a registry  then they also need to properly implement the SSI principles by going through W3C spec and then they need to register their DID-method in the registry. We know that is very tedious task and beside this it will distract them  from building their own application specific use case / business requirements.
 
I was wondering can it be possible to have template or a variable for method-name  something like this? 
 
did                                  = "did" ":"  method-name  ":" network-namespace ":"  unique-id 
method-name              = zones
zones                             = “zone1” / “zone 2” / “zone3” / …. / “zone n”
network-namespace   = "main" / "test"
unique-id                       = 32*255id-char
idchar                             = ALPHA / DIGIT
 
 
Like, we can register a did-method with list of known zones. In future if a new zone is added to the cosmos ecosystem , then they can just raise the PR for the same spec to add their zone names in the list of zones. Can it be possible to do so ? and will it be feasible from the security point of view? Or does it violates SSI principles? 
 
Sorry, if this idea is too naïve. But wanted to clarify it. Looking forward to hear your thoughts. TIA.
 
--
 
Vishwas Anand Bhushan 
Co-Founder @ Hypermine Technologies | R&D Engineer
Building Hypersign – An interoperable decentralized identity blockchain network