New text record type proposal -- vnd.everid

#1

Everest.org received a grant from the Ethereum Foundation to work on EIP-725/735 and this proposal is an ‘extension’ of that work.

EIP xxx: EverID ENS Text Record Type

Author [Mike D. Kail](mailto: [email protected])
Status Draft
Type Standards Track
Category ERC
Created 2019-11-26

Abstract

This EIP defines a text record key for ENS that returns the ERC-725 Identity Contract Address. This allows ENS name holders to associate their unique Digital Identity with multiple wallets

Motivation

Digital Identity should be a first-class citizen and is the initial route to achieving proper financial regulatory status, including KYC/AML processes. It should also be easy to remember a person’s Digital Identity using an ENS name instead of trying to memorize Smart Contract addresses

Specification

This EIP is a K/V addition to the existing ENS Resolver

Resolver Profile

The resolver interface consists of the following method:

function text(bytes32 node, string key) constant returns (string text);

The proposed key addition is:

vnd.everid - an ENS name such as mdkail.everid.eth

And the value returned is the ERC-725 Identity Contract address associated with the ENS name

Rationale

Identity Verification (IDV) and the KYC/AML processes only make sense in the context of a unique, live human identity, not a wallet. This key/value type allows the association of multiple wallets to a single Digital Identity as well as any ERC-735 attestations that may have been performed. Financial Regulatory compliance is extremely important, and is only going to become more stringent in this age of digital transformation. We want to solve for that now.

Backwards Compatibility

Not Applicable

Test Cases

TBD

Implementation

None Yet

#2

If you have an ERC725 identity, why wouldn’t you “just” have an ENS name point to this proxy using the regular addr(node) method? You always check that this address implements an ERC712 interface using ERC165.

I think it’s not likely, and dangerous, that people will have their ens name point to 2 different address.

Also, why the f*** would you return an ethereum address as a string. Thats a terrible idea!

#3

First, the return type ‘string’ was simply a cut-and-paste error on my part, and it returns an address

Second, there are longer term reasons for this proposed approach that aren’t best discussed in this forum

#4

Can you provide any pointer to these discussions?

#5

Can I suggest using an EIP-1844 interface ID instead of a text record? 1844 is already designed to return addresses, so there’s no need to do hex encoding/decoding of addresses, or suffer the extra overhead of storing it as a string.

1 Like