Implement DID's

[colin-axner]

Summary

Add DID as an SDK type

Problem Definition

Any application that wants to integrate identity verification is going to look at using DID's since they are simple and useful. Since the purpose of DID's is to be interoperable, I think it makes sense to add it to SDK types instead of having third party developers each implement their own DIDs interfaces. It is light weight, simple, and should have low engineering debt (if any)

Proposal

A DID has 3 parts:

• Scheme (ex: "did")
• Method (ex: "cosmos")
• Method Specific Identifier (ex: cosmos addrs, "5sy29r37gfxvxz21rh4r0ktpuc46pzjrmz29g45")

DID: "did:cosmos:5sy29r37gfxvxz21rh4r0ktpuc46pzjrmz29g45"

type DID struct {
    GetScheme() string
    GetMethodName() MethodName
    GetMethodSpeicifcID() MethodSpecificID
}

type MethodName {
    Method string

    // https://w3c.github.io/did-core/#method-specific-parameters
    ValidateBasic() error  // dependent upon method naming requirements
}

type MethodSpecificID {
    Identifier string

    // https://w3c.github.io/did-core/#method-specific-parameters
    ValidateBasic() error  // dependent upon method-specific-id naming requirements
}

• DID scheme must be lower case
• DID method must be lower case

A ValidateDID function should be added to ensure a DID meets the generic naming requirements and calls MethodName.ValidateBasic() and MethodSpecificID.ValidateBasic()

I am not suggesting usage in any SDK modules.

---

For Admin Use

• [ ] Not duplicate issue
• [ ] Appropriate labels applied
• [ ] Appropriate contributors tagged
• [ ] Contributor assigned/self-assigned

[fedekunze]

I like the idea but I think it would need to be spec'ed in an ADR

[aaronc]

Yeah, I like the idea. We thought of doing something similar for Regen Network, and to make things a bit easier made our bech32 prefix xrn: so that addresses by default look like xrn:5sy29r37gfxvxz21rh4r0ktpuc46pzjrmz29g45.

Would love to see a more fleshed out ADR.

How would people feel about cosmos: as the bech32 prefix?

I would note that just inserting the : without changing the actual prefix sort of breaks bech32.... Unless we defined a default conversion of did:<bech-prefix>:<bech-addr> <-> <bech-prefix><bech-addr> or something

[alessio]

Could we avoid Java-ish Get prefixes altogether please?

[egidiocasati]

Nice Idea, we totally back it up. Maybe you could find useful to see what we "did" with commerc.io network, like pair-wise did, a w3c registered did method, did authentication, etc.

[colin-axner]

Sweet, thanks for everyone's feedback. I'll start working on trying to get an ADR up for this, but it may take me some time as I have just come across DIDs and will need some spare time to wrap my head around the scope of everything.

If anyone has a concrete idea of what they would like to see for this, feel free to jump ahead of me on the ADR.

It seems to me there are few possible sides to this:

• a DID interface (and likely DID document interface) added to sdk types
• a DID module that can be used for easy registration and verification of existing DID methods

and a more controversial topic of discussion of migrating cosmos addrs to be DIDs

[alexanderbez]

Could we avoid Java-ish Get prefixes altogether please?

You can't if the fields are public.

[egidiocasati]

we already migrated cosmos address to be DIDs.

I hope I don't miss anything above my head, but, since our implementation is open sourced, I would warmly suggest you to not reinventing the wheel.

On the other end, since this (Self Sovereign Identity) is not a merely technical topic (identity verification, trust model reward for issuer and verifier of VCs, etc) you could also give back feedback to our work (started 1 year and a half ago), resulting in a contribution that could scale.

[colin-axner]

Of course @egidiocasati! I just wish there was a module registry (or maybe there is?) for cosmos so others aren't inclined to develop their own DID module. I'm very glad to see a fully fleshed out DID module since I think this is something better maintained by the community than SDK core devs (A good contribution to cosmos/modules if that is still a thing).

I do think there is benefit to having DID interfaces in the SDK types, but I will surely keep your id module implementation in mind when I get the time to spec it out

[github-actions[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[fedekunze]

This seems relevant: https://payid.org/

[migueldingli1997]

The ixo blockchain has an IxoDid type implemented which is worth checking out: https://github.com/ixofoundation/ixo-blockchain/blob/master/x/did/exported/did.go#L36-L41

It is currently modelled after Sovrin DIDs where the identifier is derived from an Ed25519 verification key. The ixo blockchain takes things a step further and uses the DIDs as sender/receiver/etc identifiers (in place of addresses) in its custom module messages. The underlying addresses being effected are derived from the Ed25519 keys stored in the referenced DIDs.

[colin-axner]

Has anyone looked into collectively owned DIDs?

The use case I'm thinking of is when a community needs to have a single entity operate a server on their behalf via a well known URL in the network (other parties rely on this URL being persistent). But if the operator becomes malicious, the community has no option, but to start a new community (because they don't control the server connected to the URL). I'd like to give the community a DID that resolves to a DID document on the cosmos hub (or some fairly secure blockchain) that is controlled by proposals passed by this community.

So instead of the network relying on the URL, they use the DID which resolves to the latest URL of the community. This sounds feasible to me and collectively owned DIDs sounds like a nice way to decentralize ownership

[alessio]

We (AiB) are planning to do work on this. More news will come soon!

[drgorb]

I would note that just inserting the : without changing the actual prefix sort of breaks bech32.... Unless we defined a default conversion of did:<bech-prefix>:<bech-addr> <-> <bech-prefix><bech-addr> or something

An identifier in the DID standard is not represented solely by method:address there can be more information appended for parameters as explained in the URL syntax https://w3c.github.io/did-core/#did-url-syntax

[colin-axner]

I'm going to try to spend the next month or so writing up an ADR for this. Based on my current mental model, I think I would end up writing two ADRs, one would be aimed to be implemented in gaia as a DID registry. I don't think the SDK should host DID registry modules since the value proposition lies with hubs and not zones using this module.

The other would be an IBC module housed in the SDK which would act as a on chain resolving/certification mechanism. A DID controller comes to chain A with some action it wants to take and potential proof of their control over the DID. This DID exists on chain B. Chain A uses its IBC module connected to chain B to send a packet request for certification of this DID along with the provided proof. Chain B replies with an acknowledgement either succeeding or failing, indicating whether the entity is actually the DID controller, it can also optionally supply DID subject information. This allows chain A to take action in reference to the DID while also supporting all the arbitrary authentication mechanisms chain B (or any connected chain) supports for registered DIDs

I still need to dive deeper though, so take my current words with a grain of salt

[aaronc]

@colin-axner awesome that you're working on this! Can we find a time to chat about this live as the key management work regen has been working on may be related? I haven't thought too deeply about how this would be implemented, but it's likely we want to think of DID methods related to the group module.

Also doing DID authentication over IBC would be great 👍

/cc @robert-zaremba

[colin-axner]

@colin-axner awesome that you're working on this! Can we find a time to chat about this live as the key management work regen has been working on may be related? I haven't thought too deeply about how this would be implemented, but it's likely we want to think of DID methods related to the group module.

Yes definitely, this would be great! I think inter module communication will likely have a role here as well in order to allow for flexible verification relationships and verification methods

[PaddyMc]

We're currently researching best practices for a DID module and would love to be apart of the chat! :pray:

@aaronc @colin-axner

[colin-axner]

Discussion should be continued here

[youngjoon-lee]

I'm glad that Cosmos team is working on this idea. I've implemented my own DID method on my blockchain (powered by cosmos-sdk). It is being used in production in my company. https://github.com/medibloc/panacea-core/tree/master/x/did. I really like the idea to make IBC-enabled DIDs. I will keep taking a look the ideation and the developement. And, I hope I can help anything if the cosmos team needs some feedback about the production experience.

[robert-zaremba]

We restarted a work for the DID in the Cosmos ecosystem: the Interchain Identifiers. It's based on Cosmos Cash /x/did cc: @PaddyMc

[tac0turtle]

closing this as it would not need to live in the cosmos-sdk