Allow to use addresses instead of public keys.

[Drabiv]

As explained here – https://github.com/WebOfTrustInfo/rebooting-the-web-of-trust-spring2018/blob/master/topics-and-advance-readings/DID-Method-erc725.md by @peacekeeper –

"In Ethereum, looking up a raw public key from a native 20-byte address is a complex and resource-intensive process. The DID community may want to consider allowing hashed public keys in the DID documents instead of (or in addition to) the raw public keys. It seems this would make certain DID methods such as erc725 much simpler to implement, while at the same time not really limiting the spirit and potential use cases of DIDs."

Will it be possible to add to DID spec "publicAddress" property (with the same rules as for publicKey property)?

[msporny]

Will it be possible to add to DID spec "publicAddress" property (with the same rules as for publicKey property)?

We should resolve this issue by specifying the signature suite for Koblitz2017 and specifying a "publicAddress" property in the key description for that signature suite.

There is nothing to do in the DID Spec as the "publicAddress" is a key material property which should be specified in the signature suite and not the DID Spec.

Close this issue once we have a tracking issue for this in the Koblitz2017 signature suite.

[Drabiv]

@msporny just to be sure I understand correctly. Will it be possible to describe key material in DID Document with value of Public Address only, as given below? Note I use "publicKeyAddress" instead of "publicKeyPem", "publicKeyJwk", "publicKeyHex", "publicKeyBase64" etc (examples from https://w3c-ccg.github.io/did-spec/#public-keys)
The reason I ask – it is not easy to get Public Keys in Ethereum, as standard Ethereum tools for convenience reasons, operate with and return as end results public addresses (last 20 symbols of Public Key hash). Values of public keys hidden and not retrievable in most standard Ethereum tools. Hence it will be very convenient to be able to not calculate Public Keys at all and use values of Public Addresses only.

. . . 
"publicKey": [{
		"id": "did:erc725:ropsten:2F2B37C890824242Cb9B0FE5614fA2221B79901E#key-1",
		"type": ["Secp256k1SignatureVerificationKey2018", "ERC725ManagementKey"],
		"publicKeyAddress": "98A2B334E9Daa39C3dDa7f804A5d2098e5bD5574"
	}]
. . .

[pelle]

@Drabiv we have this proposed method here:

https://github.com/uport-project/eth-did-resolver

{
  '@context': 'https://w3id.org/did/v1',
  id:'did: eth:0xf3beac30c498d9e26865f34fcaa57dbb935b0d74',
  publicKey: [{
    id: `did: eth:0xf3beac30c498d9e26865f34fcaa57dbb935b0d74#keys-1`,
    type: 'EthereumAddress',
    owner: 'did:eth:0xf3beac30c498d9e26865f34fcaa57dbb935b0d74',
    address: '0xf3beac30c498d9e26865f34fcaa57dbb935b0d74'
  }]
}

[Drabiv]

Thanks a lot @pelle. What is the relation of this DID resolver to Uport? I have not seen address property in uport specs (https://github.com/uport-project/specs/blob/a2576239115d74ec6bae82703614e7cdc81ab618/pki/diddocument.md)
Also, BTW is MNID an Ethereum address?

[OR13]

Please do not mix addresses with public keys. If addresses are needed in the DID Spec, they should be in a new publicAddress property. EcdsaKoblitzSignature2016 gets this totally wrong imo.

Signature suites should avoid relying on addresses for verification, and when possible should not use blockchain specific encoding.

There is no repo for Koblitz2017, and searching for it returns nothing.

[peacekeeper]

This has been addressed in 8dbfe62 and by creating a new Linked Data Cryptographic Suite https://github.com/w3c-dvcg/lds-ecdsa-secp256k1-2019, which can define an ethereumAddress public key property. Closing.