Implement Public Key Hash (PKH)-based DID Method

[wyc]

Blockchain accounts that are represented as did:tz, did:ethr, etc. have many possible resolution steps. It is not entirely fair to say that for an Address Controller credential that Temple has signed with did:tz or Metamask has signed with did:ethr if a full resolution process has not been completed. Those methods respectively have smart contracts that dictate further changes to the verification methods, service endpoints, and further DID document contents.

Therefore, I propose we implement did:pkh (Public Key Hash) which is very similar to did:key but works on the hashed public key instead. These may be further base32/base64/etc. encoded and prefixed such as in the case of a Tezos address.

Design considerations:

• Should we use a cross-blockchain specification such as CAIP-10?
• What about non-blockchain accounts? Should there be a toggle that allows for hex, base58, etc. encoded PKH? Perhaps use multihash or multibase for this? Is PKH even used outside of a significant number of blockchain contexts?

[agropper]

@wyc For those of us concerned with notarized auditable logs and/or non-repudiable signatures, can you describe a use-case where this would make a difference.

[wyc]

@agropper this will let you use a Bitcoin/Tezos/Ethereum/Solana/etc. address to create LD-Proofs, similar to did-key in that there is no supported updates to the DID document such as in did-peer, did-tezos, or did-ethr, but different in that it's the hash of the public key and not the encoded public key itself.

This can allow for simpler dependencies for implementing a notarizer because DID resolution will be fully implicit and will not require a blockchain indexer. For example, we could allow an auditor to use Metamask to sign off and persist some event, without modification of Metamask. If we were to use did:ethr instead of did:pkh, we would require that Metamask fully implement did:ethr to sign off on an event, which does not seem to be on their product roadmap.

[agropper]

Nice! I look forward to seeing this in-context but I also have a more pedestrian issue. - As a resource owner and DID controller, I'm hoping for a zero-cost DID to start an anonymous interaction with a service provider (RS) as if I was using a FIDO2 flow. - If messaging is needed, the zero-cost DID could sit behind a mediator to prevent the RS from knowing a correlatable attribute as long as there is nothing but authentication and messaging in play for my repeated visits. - At some point, the RS might need a VC that was issued to a different DID. Would I then authenticate and swap the zero-cost DID for the one that was used in my VC?

…

On Mon, Mar 15, 2021 at 9:55 PM wyc ***@***.***> wrote: @agropper <https://github.com/agropper> this will let you use a Bitcoin/Tezos/Ethereum/Solana/etc. address to create LD-Proofs, similar to did-key in that there is no supported updates to the DID document such as in did-peer, did-tezos, or did-ethr, but different in that it's the hash of the public key and not the encoded public key itself. This can allow for simpler dependencies for implementing a notarizer because DID resolution will be fully implicit and will not require a blockchain indexer. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#123 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AABB4YKN5PZMSUPGZYOYOW3TD227HANCNFSM4ZBRGRLA> .

[wyc]

The RS could potentially accept an additional VC that specifies a sameAs relationship cross-signed between the two DIDs with caveats. This would always need to be presented alongside the VC which has the "legacy" DID as the data subject.

[awoie]

why not did:caip-xyz:blockchainAccountId?

this proposal might be similar to did:eth (not did:ethr) which is using the ethereumAddress as the identifier without going through erc1056. @mirceanis

[wyc]

We want to focus solely on the key material, whereas blockchainAccountId includes the chainId adding complexity. For now, we want to avoid extra surjective relationships from the DID to key material because it keeps the security model a lot simpler, e.g., did:caip10:0xab16a96d359ec26a11e2c2b3d8f8b8942d5bfcdb@eip155:1 and did:caip10:0xab16a96d359ec26a11e2c2b3d8f8b8942d5bfcdb@eip155:2 would map to the same keypair but it's not clear what the use case would be to have different DIDs.

Even if did:pkh:btc:... and did:pkh:tz:... have the same keypair mapping, the btc and tz tokens indicate the encoding scheme. We looked at multihash for this, but found it not descriptive enough to also describe the types of keys.

did:eth sounds great! Instead of also defining did:sol, did:btc (not did:btcr), etc. we thought it was cleaner to do it this way with less pollution in the namespace.

[awoie]

@wyc What would be the DID Doc for a did:pkh ie a truncated secp256k1 hash aka public Ethereum address, e.g., 0xb9c5714089478a327f09197987f16f9e5d936e8a?

[wyc]

Hi all, please see https://github.com/spruceid/ssi/tree/main/did-pkh