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

Hello,

Thanks for explaining. I don't know much about either the Ethereum or 
Cosmos communities, but if the difference between "zones" is mostly 
governance, and the underlying technology is essentially the same, then 
again I don't think there should be separate DID methods.

Also, DID methods are not really meant for marketing, but well yes 
unfortunately in practice that's an aspect as well :)

Markus

On 17.02.22 21:40, Vishwas Anand wrote:
>
> 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 <https://hypermine.in>| R&D Engineer
>
> /Building //Hypersign/ <https://hypersign.id>– /An////interoperable 
> decentralized identity blockchain network///
>
> *From: *Markus Sabadello <mailto:markus@danubetech.com>
> *Sent: *17 February 2022 16:28
> *To: *Vishwas Anand <mailto:vishwas@hypermine.in>; public-did-wg@w3.org
> *Cc: *Vikram Bhushan <mailto:vikram@hypermine.in>; Irfan ッ Khan 
> <mailto:irfan@hypermine.in>; abhijit sinha 
> <mailto:sinha.abhijit007@gmail.com>
> *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 <https://hypermine.in/>| R&D
>     Engineer
>
> /BuildingHypersign <https://hypersign.id/>/–/An////interoperable 
> decentralized identity blockchain network/
>