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

Hey Markus,

Thank you replying and providing those threads, went through them.

The way I am visualizing this problem is less from technical perspective and more from business / marketing perspective. Cause that brings hindrance in the adoption of a tech. We have previously faced this problem while identity wallets – its very hard to convince them to use branding unless, of course we are some big tech giants. We had to whitelabled it which itself comes with its own set of problem (just for an example). 

The other argument which I have is, I think it would be not be feasible to directly compare Cosmos and  Ethereum ecosystem. Ethereum only has one governance framework hence “did:ethr:<sub-namesapces>” makes sense whereas in Cosmos, every zone has its own governance. I feel Cosmos is more closer to Hyperledger in this respect except the fact that every zone is permission less. 

Which is why I believe using “did:hypersign:<zone>”  will probably bring friction to the community.  However, as Daniel pointed out in the previous reply, we could possibly use “did:cosmos:<zone>” , for example “did:cosmos:hypersign:<unique-id>”.




Not sure if  I am making sense from Cosmos perspective. 

I personally loved the idea of abstract did method (thanks for sharing those threads). Looks like it was rejected already. 

--

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

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

Hello Vishwas,
The DID Working Group has discussed this topic in the past, about potentially having "DID method types" or "abstract DID methods" that can be used as a basis for multiple DID methods, e.g. see discussions here:
https://github.com/w3c/did-core/issues/152
https://github.com/w3c/did-core/issues/478
The conclusion was that this is probably not a good idea, and that a single DID method (such as "hypersign") with sub-namespaces should be used. In your syntax you already using something called a "network-namespace", and I think the "zones" should just be another namespace before that, e.g.:
did = "did" ":" "hypersign" ":" zone ":" network-namespace ":"  unique-id 
Then you don't need separate DID methods in the W3C DID method registry. Do you see a problem with that?
I think the "test" should be whether or not there is a substantial difference in how the DID operations create/read/update/deactivate work technically. If those operations work essentially the same way across different zones and networks, only with different parameters or configuration, then you don't really have separate DID methods.
Other DID methods such as did:indy or did:ethr are doing something similar, they use sub-namespaces for identifying different networks, or zones, etc.
Also see the green note box at the end of this section:
https://www.w3.org/TR/did-core/#method-syntax
Markus
On 17.02.22 10:35, Vishwas Anand 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