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 <https://hypermine.in/> | R&D Engineer
> *Building Hypersign <https://hypersign.id/>* – *An* *interoperable
> decentralized identity blockchain network*
>