ENS Support

[nickreynolds]

There is a DID method called did:ens that allows ENS names to be used as the unique identifier of a DID method. I think we should consider if we can support ENS names in this DID method so that a single DID method could be used with either Ethereum addresses or ENS names as identifiers.

[ottomorac]

Absolutely we should!!

[Vid201]

@nickreynolds

I have two concerns about adding support for ENS names to the did:eth method.

Currently, ENS is supported only on the Ethereum mainnet (and testnet) and not on other L1 and L2 networks, such as Polygon and Arbitrum. Some other domain name services could prevail in the future, which could be different on different networks or even several on one network. The spec could result in having support for multiple projects and therefore have extra external dependencies (e.g., what happens if some domain service has a bug in the smart contract code).

ENS domains can be sold (or expired, and you forget to renew them). What happens to the VCs that are bound to that ENS name? When verifying VC, should the resolver return the blockchain address associated with the ENS domain at the time of the VC issuance? This could introduce some complexity to the specs.

[mirceanis]

One of the features that I'd like to keep in this new spec is the ability to version DID documents through query params pointing at a particular block. I don't know if ENS supports an inspection of past owners the same way.

[bumblefudge]

ENS itself or DID:ENS? I think ?blockHeight=XXXXXX is super important and would love to see it kept; lots of people don't think they need it.... until they do :D

[mirceanis]

I was referring to ENS itself. That also constrains the possibilities of did:ens.

In did:ethr we use ?version=<block height> to keep close to the did spec in naming the params

[bumblefudge]

?versionTime= would make sense for block height; ?versionId= would make sense if you were referring to a DID Doc by it's id or counter or UUID, or if your DID Docs don't include any of the above, you could always fallback to the version of a DID Doc by the transaction hash that published it, maybe? null for implicit DID Doc? just spitballin' here, I may not actually know what I'm talking about.

[mirceanis]

I had a typo. it's actually versionId.

I think both versionTime and versionId can be used. A DID document has the potential of being updated only once per block (even if multiple transactions make updates in the same block, only the final state is resolvable.
That's why we were using the block height as the "counter" and versionId at the same time.
If a block does not update a DID document, then that version is equivalent to the last block that did.

Since the history of events has to be considered when resolving, versionTime could also technically be used, as it would be easy to ignore the events that were published after the specified versionTime.

[bumblefudge]

i think the devil is in the details-- I would tend to think that in many use-cases, a better pattern is for did:ens to delegate to to a did:ethr or other self-updatable DID method, as outlined in Spruce's article on the subject. has anyone asked Oliver or ENS about how the DID method is actually being used in the wild? i know spruce is pretty active in the ens dao, and would likely know if anyone is working on some ENS infra that uses it for, e.g. the new ethereum "attestation service," etc.

long story short, i'm more inclined for did:ens to be a separate veramo component than a part of did:ethr, but could be convinced otherwise if there were use-cases or opportunities already out there in the wild.

[nickreynolds]

@bumblefudge that might end up being a better pattern, yes. The did-ens-spec is still in an "under development. do not use in production" state, so I hope it's not being used for anything important...

But maybe this would be a good time to restart development on that spec. And yeah I'd love to get Spruce/Oliver involved with the work on both of these specs. I'll be sure to bother them a bunch about it at ETHDenver!