did:ethr is it address or public key?

[nickz-t3]

Bug severity
5

Describe the bug
Looking at the docs here https://veramo.io/docs/veramo_agent/did_methods/
did:ethr should produce and ethereum address - a 42 character hex string if 0x included.
However when I run veramo did:create I get a 68 character hex string (including 0x). This is apparently not ethereum address but a public key - a compressed representation of the curve point.

The difference is that eth_address is the last 20 bytes (40 hex characters) of the keccak256(public_key).

Why is there discrepancy with docs?

The problem here is that metamask would not easily tell you the public_key - only the address. To get the public key you need to ask user to sign smth and then you can derive it from a signed message. So it is not straightforward to issue VCs to users for whom you know the eth_address.

Besides that having public key in the open like that is simply not very secure. Public key is not post-quantum resistant. Which means that theoretically in 20-30yrs we will be able to derive private key from it. While ethereum address (which applies additional hash function on public key) is post-quantum resistant.

To Reproduce

1. run verame did create
2. choose did:ethr
3. count characters

Observed behaviour
68 characters did:ethr

Expected behaviour
42 characters did:ethr

Versions:
Veramo 5.6.0

[mirceanis]

did:ethr identifiers can be represented as both address or public key. See method-specific-identifier

Using only the ethereum address creates a subset of the DID document by default, which is why we prefer the public key variant whenever possible as it provides broader compatibility with signing algorithms without the need for an additional transaction or other signature.

Any further updates to the DID document of a did:ethr identifier would be reflected in both variants of that identifier. The only difference is in the presence or absence of the initial public key as one of the verification methods.

Quantum resistance of the address variant is not a real argument as any signature produced by the corresponding private key would reveal the public key.
The same is true for any externally owned account on ethereum.