wyc
commented
3 years ago Thanks for the feedback, indeed this improvement should go into ssi. Unfortunately, we haven't implemented the public key hex portion as you describe, but it should be straightforward to do so and we should be able to get to it shortly. The workaround you describe to route to a different resolver is also a great suggestion, and we will consider it.
did-ethr has historically had low usage due to barriers to user understanding and high gas costs, so we have been most focused on implementing did:pkh:eth to be compatible with CAIP-10 for gasless EVM-based DIDs that don't require identity wallets other than Web3 wallets like MetaMask. The trade-off is sacrificing key rotation and service endpoint publishing for zero gas costs, simplicity, and improved UX. This may be of interest to you depending on your use case.
However, I suspect did-ethr has had a recent resurgence in interest with new EVM-based L2s and its use within teams pursuing EBSI compatibility for identity. Thanks again for pointing this out, and we'll get to it soon!
clehner
The did-ethr resolver works great on etherium address DIDs (ones whose hex string is 40 chars long), but returns with
invalidDidfor public key hex DIDs (ones whose hex string is 66 chars long). The spec that it ( https://github.com/spruceid/ssi/blob/6d82e3ef4f94c7c3292b4688e36a494bbcb24a07/did-ethr/src/lib.rs#L27 ) references is https://github.com/decentralized-identity/ethr-did-resolver/blob/master/doc/did-method-spec.md -- partial support wouldn't necessarily be a problem, except that I'm unable to override the resolver (I'm usingdidkit-clior equivalentlydidkit-http) to use a custom DID resolver for did:ethr (such as universal resolver).I think this ticket belongs to both
ssianddidkitrepos, since there are resolution paths for both of them. Though obviously the better solution is to havessisupport the whole did:ethr spec.