Suggestion: Make did:pkh completely based on new caip10 spec

[oed]

So this is mostly just an idea that I think would simplify things, however the caip10 spec is not yet settled.

Suggestion: make the DID PKH be represented as:

did:pkh:<caip-10-account-id>

This would mean that we always include the chainId, so it may break existing identifiers, but it would make the PKH spec much more clear!

Examples

// ethereum mainnet
did:pkh:evm:1:0xab16a96d359ec26a11e2c2b3d8f8b8942d5bfcdb

A benefit of using this approach is that we automatically can support new blockchains that are added to the CAIP repo without having to change the PKH spec at all.

Note, this is based on the discussion taking place here: ChainAgnostic/CAIPs#51

[wyc]

Great suggestion. I think we can perhaps add :caip10: as a submethod....or perhaps default to caip10 methods if not explicitly defined in did-pkh. This would allow the specification some flexibility to work with non-CAIP/non-blockchain PKH reprs, such as GPG fingerprints.

# explicitly mention CAIP-10
did:pkh:caip10:evm:1:0xab16a96d359ec26a11e2c2b3d8f8b8942d5bfcdb
# fallback to CAIP-10
did:pkh:evm:1:0xab16a96d359ec26a11e2c2b3d8f8b8942d5bfcdb
# new CAIP DID method
did:caip10:evm:1:0xab16a96d359ec26a11e2c2b3d8f8b8942d5bfcdb
did:blockchain:evm:1:0xab16a96d359ec26a11e2c2b3d8f8b8942d5bfcdb

I'm okay with a lot of these, but prefer explicitness where possible.

[oed]

I would prefer if we don't end up with a lot of different ways to represent a single account-id. Imo we should select one of these options and stick with it!

See your point on non-CAIP PKHs though. In theory we could create caip10 specs for these as well. This is the case for Radicle which is not a blockchain id. If we could converge between caip10 and did:pkh it would be awesome since it seems we are trying to achieve a lot of similar things.

[wyc]

Agreed! I like the idea that we accept CAIP-10 registration as a top-level submethod, e.g., did:pkh:evm:1:... but we should accept that the same priv key for a bitcoin address e.g. can be used for Ethereum due do both using the secp256k1 curve.

+1 to convergence

[bumblefudge]

Closed by #252

[oed]

@bumblefudge This should not be closed by #252! The main thing that needs to be update in the spec is how DIDs are represented.

[bumblefudge]

My mistake! Will update the spec ASAP to reflect the code as soon as the changes have been fully integrated

[oed]

Thanks :)

[wyc]

Let's try to get this next week. cc @bumblefudge