reserve did:eth in DID Registry Spec

[nickreynolds]

No description provided.

[nickreynolds]

https://www.w3.org/TR/did-spec-registries/#did-methods

[Hmac512]

What is the reason to go with did:eth over did:evm or something more general?

[strumswell]

As I said yesterday, I am also in favor of going with did:evm as it directly represents any evm chain. But I totally get that did:eth has a bigger marketing value ;)

[Hmac512]

I just want to make sure it’s a conscious decision.

I totally get did:eth would immediately have a sense of trust with someone who stumbles onto it.

I think did:evm is a bit more accurate as the name implies it’s a smart contract. If we add Account Abstraction “eth” may be limiting.

I’m still writing up my thoughts on use of the Diamond pattern. One use case for us is that we can add custom resolver facets to our contract, so it could support multiple did methods.

Can we reserve both? And just wait until all the facts are in.

[lleifermann]

@Hmac512 (btw how did you get that userhandle. As if this was not taken lol)

I am also a big did:evm fan. Fully agree to your points. I think reserving both should be OK.

After having looked at https://github.com/w3c/did-spec-registries i am actually not sure if we can 'reserve' - The spec does not mention different states of registration as far as i can tell. I believe if we wanna get our namespace we need to have a document ready. (We may just try opening a PR though with placeholder values)

[Hmac512]

@Hmac512 (btw how did you get that userhandle. As if this was not taken lol)

I’m guessing everyone else before me automatically assumed it was taken.

[Hmac512]

How about a compromise, we change the name of the project to a better version of “EVM-DID”, and did:eth is the primary method.

I’m assuming that did:eth will be specific to secpk1 ethereum addresses.

With this approach I think we should add into our mission statement that the smart contract design be agnostic to did methods. Whether it’s through governance or Diamonds magic, we can make it possible to register new methods.

I’m alright with making did:eth the primary method as that will be easiest to use for most use cases.

(long) Footnote:

https://eips.ethereum.org/EIPS/eip-2535

What I mean by Diamonds magic is that it’s possible to let anyone add a resolver module to the contract. You call a function in the contract with EVM byte code for the resolver logic, which is then registered with an identifier from a hash of the byte code.

Using the hash is important as the identifier will be the same across all deployments for the same resolver logic.

You can then use the hash identifier when interacting with your DIDs.

What remains is how to tie the resolver to a string like “did:eth”. This can be gated by governance.

It would then become possible to upgrade the did method while the previous version(s) remain available. You add a new resolver module, and point the method string at the new one.

There are a lot of details I’ve left out. Security and gas implications are the big questions.

Then did:keri isn’t a competitor, but can be used within our contract.

EDIT:

I brought up diamonds here to show that the contract can be abstracted away from just did:eth. For diamonds related questions please use this issue: #8

[Hmac512]

Fun fact, ETH 2.0 uses BLS keys for the validator nodes.

https://ethereum.stackexchange.com/questions/117993/elliptic-curves-for-eth2-keys-and-addresses

https://kb.beaconcha.in/ethereum-2-keys

The hilarious thing is they could’ve used SSI and predicate proofs to better explain how parts of the validators and beacon chain work. If only they knew.

[fermentfan]

I am liking the idea of providing a 'did:evm' and being the central place to resolve dids. Especially because of the governance aspect. At the moment the governance of did methods lies outside of the blockchains in form of de facto centralized specifications which for example dictate the addresses for different contract based methods. Building the DAO as the place to configure the "officially used" contracts would allow to extract this sensitive information of "where to lookup a did" while also making it machine readable. All then secured and hopefully democratically controlled by the public DAO entity. I guess we would then have 'did:evm:eth' and 'did:evm:ethr'? Only thing we definitely should add is chainId and networkId to the DID string then?

To me it looks like this would then be a different repository?

Btw I already secured the 'did-dao.eth' a few months ago 😎

[fermentfan]

Also one problem I see is that we add another abstraction layer in SSI. Poor people trying to understand all this 😅

[nickreynolds]

I think did:eth is a more compelling name than did:evm, but we can probably take our time with this decision. We could even go with did:e (1 letter name is very powerful, imo). I think we should understand that DIDs may be user facing, and something like did:evm could look strange to a user (if they google "evm" and see something about "virtual machines" they could be confused).

[mirceanis]

How about a compromise, we change the name of the project to a better version of “EVM-DID”, and did:eth is the primary method.

I’m assuming that did:eth will be specific to secpk1 ethereum addresses.

With this approach I think we should add into our mission statement that the smart contract design be agnostic to did methods. Whether it’s through governance or Diamonds magic, we can make it possible to register new methods.

I’m alright with making did:eth the primary method as that will be easiest to use for most use cases.

I think this point is getting overlooked and I am liking this idea more and more.
What I'm reading here is that there is a new(ish) DID method that is an upgrade to did:ethr, using the same kinds of secp256k1 based identifiers, BUT, a contract being developed (here) allows the (partial) resolution of other DID methods on chain using diamond pattern to point to other contracts that implement the resolution.

@Hmac512 please correct me if I misunderstood your point

One of these contracts it points to is one for did:eth/evm/e, and another can be for did:pkh, and another for did:key, did:ethr, etc.. It would work for any DID method that is partially resolvable on an EVM runtime.

Partial resolution on chain means answering 2 questions:

• is this a valid signature for this purpose? (sort of like ERC1271 but for DIDs and verification relationships)
• is this (key) a valid signer for this DID (in the spirit of isValidDelegate from ERC1056)

Maybe this is worth its own ERC?

[strumswell]

We could even go with did:e (1 letter name is very powerful, imo)

I wasn't even aware that a 1 letter method name is a possibility. But it definitely is and I kinda like it. https://www.w3.org/TR/did-core/#did-syntax