[proposal] Add support for full publicKey identifiers

[mirceanis]

Problem

There is an inherent limitation to ethr-did regarding the types of keys that can be expressed in the default DID document.
The default DID document lists the ethereumAddress backing up the DID as a signature verification key, but it is not a full public key, only the truncated hash of one.
Therefore it cannot be used for Diffie Hellman negotiations, nor for direct signature checks using ecVerify(), or any encoding transformation, like key-material -> JWK representation.

In most cases the ethereumAddress of an identifier comes from a publicKey and not from a contract.
Of course, it is possible to add the full secp256k1 key but that requires a transaction and gas, going against a first principle of did:ethr which is onboarding without gas.

Proposal

The same infrastructure(ERC1056 contract) that is now used to resolve ethr-dids could support DIDs that are based on secp256k1 public keys.
The queries to the erc1056 contract would be the same, it would be up to the resolver to compute the corresponding ethereumAddress to be able to perform the queries.

Example DID

• existing ethr-did:
  did:ethr:0xf3beac30c498d9e26865f34fcaa57dbb935b0d74
did:ethr:0x4:0xf3beac30c498d9e26865f34fcaa57dbb935b0d74
did:ethr:rinkeby:0xf3beac30c498d9e26865f34fcaa57dbb935b0d74
• proposed DID using publicKeyHex (compressed):
  • generic (mainnet)
    did:ethr:0x02b97c30de767f084ce3080168ee293053ba33b235d7116a3263d29f1450936b71
  • with chainID did:ethr:0x4:0x02b97c30de767f084ce3080168ee293053ba33b235d7116a3263d29f1450936b71
  • with network name did:ethr:rinkeby:0x02b97c30de767f084ce3080168ee293053ba33b235d7116a3263d29f1450936b71

Example default DID document

(the newer format from W3C is a separate line of work)

{
  "@context": "https://w3id.org/did/v1",
  "id": "did:ethr:0x02b97c30de767f084ce3080168ee293053ba33b235d7116a3263d29f1450936b71",
  "publicKey": [
    {
         "id": "did:ethr:0x02b97c30de767f084ce3080168ee293053ba33b235d7116a3263d29f1450936b71#owner",
         "type": "Secp256k1VerificationKey2018",
         "publicKeyHex": "0x02b97c30de767f084ce3080168ee293053ba33b235d7116a3263d29f1450936b71"
    },
    {
         "id": "did:ethr:0x02b97c30de767f084ce3080168ee293053ba33b235d7116a3263d29f1450936b71#key-1",
         "type": "Secp256k1VerificationKey2018",
         "ethereumAddress": "0xf3beac30c498d9e26865f34fcaa57dbb935b0d74"
    }
  ],
  "authentication": [
    {
         "type": "Secp256k1SignatureAuthentication2018",
         "publicKey": "did:ethr:0x02b97c30de767f084ce3080168ee293053ba33b235d7116a3263d29f1450936b71#owner"
    },
    {
         "type": "Secp256k1SignatureAuthentication2018",
         "publicKey": "did:ethr:0x02b97c30de767f084ce3080168ee293053ba33b235d7116a3263d29f1450936b71#key-1"
    }
  ]
}

Details

Owner changes

The present ERC1056 contract can only list an ethereumAddress as owner so changing owner MUST invalidate the publicKey identifier as well as the corresponding ethereumAddress from the list of publicKey and authentication sections (and any other corresponding entries that may appear in newer W3C docs).
Ownership changes that would automatically list a full public key would require changes to the contract code which is not an intent of this proposal.
If an owner needs to be changed, the assumption is that they already have access to gas, so they could first add the new publicKey as attribute and then shift ownership.

Multi-network

Multi-network support MUST NOT be affected by this change.
the format did:ethr[:<network>]:<identifier> is preserved, only the identifier can now be of 2 formats.

• 42 chars -> ethereumAddress
• 68 chars -> compressed publicKey

Steps

• resolve("did:ethr:pubKey")
  • pubKey -> uncompressed pubKey -> origAddress
  • query ERC1056 contract with origAddress to get owner, delegates and attribute history
  • if owner is origAddress, add entries for both pubKey and origAddress to the publicKey and authentication sections in the resulting DID doc, otherwise, add only the new owner address
  • if origAddress is one of the delegates, add pubKey to the publicKey section of the resulting DID doc
  • continue building the rest of the document by existing rules
• resolve("did:ethr:ethereumAddress")
  • no changes to functionality expected; resolve by existing rules

[mirceanis]

@awoie please share some feedback here if you have any

[awoie]

@mirceanis what would it take to use publicKeyJwk or publicKeyBase58 instead? publicKeyHex might get removed from the DID Core spec: w3c/did-core#236

(I will provide more feedback later this week)

[awoie]

@mirceanis we should already remove ethereumAddress from the publicKey section and just add it to the authentication section. You would then embed the whole value of the entry there.

[mirceanis]

what would it take to use publicKeyJwk or publicKeyBase58 instead? publicKeyHex might get removed from the DID Core spec: w3c/did-core#236

The identifier could be represented in other encodings. I chose publicKeyHex in compressed form as a simple mechanism to represent the key material that one can easily tell apart with a simple regex.

I considered base64 or 58 as well but then realized that future improvements to this spec are more likely to use something similar to did:key so publicKeyHex is easier to use as there is no ambiguity.

For the identifier part, JWK does not make sense.

The representation of the key in the DID document does not have to match the identifier encoding.
If needed, the key entry in the resulting DID doc can be JWK or base58. That's one of the reasons for the existence of this proposal :)

---

we should already remove ethereumAddress from the publicKey section and just add it to the authentication section. You would then embed the whole value of the entry there.

I think it is too early for that since there is no real benefit other than semantics and there is a huge amount of technical damage and a hard transition period if it is done prematurely.
I would rather wait for the DID spec to be closer to a stable form before deciding this.

[uport-automation-bot]

🎉 This issue has been resolved in version 2.4.0 🎉

The release is available on:

• npm package (@latest dist-tag)
• GitHub release

Your semantic-release bot 📦🚀