[proposal] Add cosmosAddress Property in verificationMethod like a ethereumAddress

[daoauth]

[proposal] jwt validation using cosmosAddress #204

Since Cosmos uses prefixes for addresses, it is an advantageous address system to use as did. So, after decomposing the address into prefix and remainder, we want to use it as a DID. And, like Ethereum, Cosmos would like to add the address of Cosmos to the property so that it can be verified by extracting the public key from the signature.

dsrv1zp78zmtj4a7qvs4p2s08ngjn9rcwpaf5k9d0la (cosmos address) did:dsrv:1zp78zmtj4a7qvs4p2s08ngjn9rcwpaf5k9d0la (did)

interface VerificationMethod {
  id: string
  type: string
  controller: string
  publicKeyBase58?: string
  publicKeyBase64?: string
  publicKeyJwk?: JsonWebKey
  publicKeyHex?: string
  publicKeyMultibase?: string
  blockchainAccountId?: string
  ethereumAddress?: string
  cosmosAddress?: string
}

[peacekeeper]

I would recommend to also add it to the W3C DID Spec Registries:

https://w3c.github.io/did-spec-registries/#verification-method-properties

[nklomp]

In addition ethereumAddress is deprecated in favor of blockchainAccountId. The current ethr driver doesn't even return ethereumAddress anymore. I don't think it would be wise from an interoperability POV to add features which are very ledger specific, before you know it the verificationMethods end up with all kinds of properties. With 100+ did methods that can become quite the challenge.

https://www.w3.org/TR/did-spec-registries/#ethereumaddress

I guess I am missing the relevant split parts you mentioned. I am not entirely familiar with the Cosmos address format, but isn't dsrv a network on cosmos and is there something like a checksum in the address? If so why not have it like many other methods and make it part of the method specific id: did:[method]:[network]:[account, address, or hashed publickey]?

Ethereum example: did:ethr:rinkeby:0x3b0BC51Ab9De1e5B7B6E34E5b960285805C41736

Its blockchainAccountId contains this: 0x3b0BC51Ab9De1e5B7B6E34E5b960285805C41736@eip155:4 So it is exactly the method specific ID after the :rinkeby: prefix and with the the EIP155 network id (4 = Rinkeby) attached to it, which is also the first part of the method specific id for the ethr DID method.

[daoauth]

Cosmos is an inter-chain blockchain that can create and service various blockchains by adding its own SDK.

Cosmos, Terra, Persistence, Agoric, Osmosis, THORChain, etc. are blockchains developed by adding their own SDK to Cosmos. And all of them are mainnets. Each name has a different prefix for the address. Each address is cosmos1nx982k7n0tcuy06gzyhse3sj9c2yshp9aawanp, terra1kd3eh206jxpqpkllqjjm5w7sw0sqm38m678ujl, persistence19c8teptw4flqwezpswwvph28ynfak0cf9n8dx8, dsrv1zp78zmtj4a7qvs4p2s08ngjn9rcwpaf5k9d0la.

So, I would like to propose to support verification on various Cosmos blockchains using blockchainAccountId.

For example:

In the Cosmos blockchain, it is used as follows, cosmos:cosmos:1nx982k7n0tcuy06gzyhse3sj9c2yshp9aawanp, In Terra Blockchain, it is used as follows, cosmos:terra:1kd3eh206jxpqpkllqjjm5w7sw0sqm38m678ujl. And in the case of DSRV, it is cosmos:dsrv:1zp78zmtj4a7qvs4p2s08ngjn9rcwpaf5k9d0la.

In this case, it seems to be necessary to add a part that handles that part to did-jwt.

[nklomp]

But what is the exact need for it then? You just want to have it in the blockchain Account ID?

Because the respective cosmos driver has to be aware of the fact there are multiple networks for the same did-method A lot of DID methods support different networks. Whether those are mainnets or testnets doesn't really matter. They use the first part of the method specific id as a network identifier, this also protects against replay attacks on other networks. It is valid according to the DID Data model, which allow for colons in the method specific ID.

So what the respective resolver driver does is split the method specific id based on the colon. If it is not there typically a mainnet is assumed (could default to cosmos) and if it is there it will access nodes for that particular network. You want to resolve anyway to verify a proof.

So the outstanding question for me would be, what is the exact need for the blockchainAccountId and why could the resolver driver not populate it as it should know the network it is talking to regardless?

[nklomp]

So your examples probably should be available as the following DIDs:

did:cosmos:cosmos:1nx982k7n0tcuy06gzyhse3sj9c2yshp9aawanp
did:cosmos:terra:1kd3eh206jxpqpkllqjjm5w7sw0sqm38m678ujl
did:cosmos:dsrv:1zp78zmtj4a7qvs4p2s08ngjn9rcwpaf5k9d0la

Which the cosmos driver can simply interpret. The benefit is that a single account/public key can be used on multiple networks, without replay problems, because the DIDs do have the network in it.

So the driver gets one of the above 3 example DIDs. It simply looks whether there is a network in the DID or not. If there is it talks to correct node(s) for that network. Then depending on how your DID documents are being created, it could simply populate the verification method with the blockchainAccountId value needed. It has constructed the accountId from the DID anyway in order to populate the verificationMethods in the DID Document to begin with

[nklomp]

Maybe the missing piece of the puzzle for you is, that you typically resolve DIDs to DID Document using the Universal Resolver or for instance the typescript did-resolver package, which in turn uses a driver per DID method. So all DID methods have their own drivers. I quickly looked at Cosmos, but I don't think it is there.

It is the driver's task to correctly return/resolve the DID into a DID Document. What you typically see is that there are some low level libraries for a particular ledger, you can use when talking to your own world, and then a driver, which connects that low level library to the universal resolver https://github.com/decentralized-identity/universal-resolver or for instance to https://github.com/decentralized-identity/did-resolver (this repo)

[nklomp]

An ethereum example for a did-resolver (typescript/javascript) is https://github.com/decentralized-identity/ethr-did-resolver and as Universal Resolver: https://hub.docker.com/r/uport/uni-resolver-driver-did-uport/

[daoauth]

For example, did:etho, did:dual using Ethereum, but do not use did:ethr:etho, did:ethr:dual. However, validation uses ethereumAddress. And similar DIDs will be proposed on the mainnet, which will be created by forking Ethereum in the future.

    {
      "id": "did:etho:1f4B9d871fed2dEcb2670A80237F7253DB5766De#keys-1",
      "type": "EcdsaSecp256k1RecoveryMethod2020",
      "controller": "did:etho:1f4B9d871fed2dEcb2670A80237F7253DB5766De",
      "ethereumAddress": "0x1f4B9d871fed2dEcb2670A80237F7253DB5766De"
    }

    {
      "id": "did:dual:0xea6328ef09549e48d4adadfcee4a8cb3a6fcdcf8#controller",
      "controller": "did:dual:0xea6328ef09549e48d4adadfcee4a8cb3a6fcdcf8",
      "type": "Secp256k1VerificationKey2018",
      "ethereumAddress": "0xea6328ef09549e48d4adadfcee4a8cb3a6fcdcf8"            
    }

And the checkSignatureAgainstSigner function in did-jwt only supports Ethereum. However, blockchainAccountId is specified so that other blockchains can also use it. However, only Ethereum is currently supported.

So, in the case of Cosmos, we can prepare in advance for verification through "toCosmosAddress" like Ethereum's toEthereumAddress function through blockchainAccountId using an address system that can use prefixes.

I would like to suggest that it is also possible to use the following in cosmos as well.

    {
      "id": "did:dsrv:1zp78zmtj4a7qvs4p2s08ngjn9rcwpaf5k9d0la",
      "type": "EcdsaSecp256k1RecoveryMethod2020",
      "blockchainAccountId": "cosmos:dsrv:1zp78zmtj4a7qvs4p2s08ngjn9rcwpaf5k9d0la"
    },

[daoauth]

Updated to https://github.com/OR13/lds-blockchain2021/pull/3 for further clarification.

[daoauth]

https://github.com/w3c/did-spec-registries/issues/347