"Key Addresses" on the did:erc725 method doc [Question]

[cbruguera]

Hello @peacekeeper, I was just reading the method proposal and for resolving the DID, step 3 states:

For each returned key address, look up the secp256k1 public key associated with the key address.

I'm not fully understanding the meaning of the term "key address" in this context. From the current specs of ERC725, keys are stored as uint32, is this the "address" that's being referred to or is this uint32 data the (public) key itself (that was my understanding) and the address is something else? Is this "address" an ethereum addresses linked to the key or is this assuming that keys correspond in fact to ethereum addresses?...

Quite probably I'm missing a few things on the ERC725 proposal. If you can help me clear this up, I'd appreciate it.

[peacekeeper]

The uint32 stored in the ERC725 smart contract contains a hashed public key. Typically this will be an Ethereum address (that's why I used the term "key address" - maybe not ideal). It could also be another kind of hashed public key, e.g. hashed RSA key.

The DID spec currently assumes that DIDs resolve to actual public keys, not hashed public keys. So you need to find the actual public key for the uint32 (that's only the hash of the public key). This is what the sentence you highlighted means.

However finding the actual public key for an Ethereum address is difficult, so there's also a discussion that perhaps DIDs should not strictly require actual public keys, but also support hashed public keys, see here: w3c-ccg/did-spec#56

[cbruguera]

Maybe off-topic and more related to the ERC725 proposal than DID, but it sounds to me really complicated for it to define all "keys" as hashes of actual keys if the keys need to be "resolved" from the hash. As you comment, retrieving public keys from hashes is a really complicated matter, especially in the case of Ethereum addresses, in which the address is not even the complete hash (only the rightmost 160 bits) of the public key. Hash functions are called "not invertible functions" for a reason.

Wouldn't it be simpler for ERC725 to assume it'll only handle ethereum addresses? Or maybe I'm missing something in my understanding of ERC725?...

On another subject, adding publicAddress as a key property on DIDs is spot on for sure.

[peacekeeper]

This has been addressed in w3c-ccg/did-spec@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.