<<<<<<< HEAD

Email To DID Service

The latest email to did service can be found on the official city of austin atxzero github - https://github.com/atxzero/email-to-decentralized-id

Readme in FAQ form:

I know what email is, what is a DID?

DID is short for Decentralized Identifier. A DID consists of the letters “did” then the place where the address lives such as “ethr” for the Etherium decentralized ledger, or “web” for an internet address. Finally a DID has a globally unique identifier (GUID), which is made from the public key of a public/private key pair native to the specified ledger. This {“did” : ”ledger” : ”GUID”} format is called a decentralized identifier because it creates the infrastructure such that the decentralized public key in the DID identifies the holder of the private key. For more in depth description see this https://www.w3.org/TR/did-core/ def

So what does this service do?

The emailtodid.eth ENS keeps an array of emails and associated DIDs in a text list. For every email address queried, this service returns the DID associated with it. If there is no DID associated with an email address, this service creates one and records the pair in the ENS text record.

I still don’t get it. What does this look like?

sequenceDiagram
Email --> Browser: user enters email address
Browser ->> EmailToDID: Request's DID corresponding to email
EmailToDID ->> ENS: Queries emailtodid.eth txt list for email
alt email is found
  ENS ->> EmailToDID: Returns DID
  EmailToDID ->> Browser: Returns DID
else email is not found
  Note over EmailToDID: Create new ETH Pair
  Note over EmailToDID: Create one time download link for private key
  EmailToDID ->> Browser: Return DID
  EmailToDID ->> Email: Sends One Time Link with Private Key to Email Address
  Note over Email: User clicks on link
  EmailToDID ->> ENS: Writes new [email,DID] pair to txt list 
end

Loading

Why did we make this?

Onboarding users into the web3 ecosystem is difficult, because it is a complex process, and there are no clear incentives for new users. So we start them off with something they already have, then we use the value created by web3 services to encourage them to control their own keys.

Will a bot be able to steal my identity?

Not likely, but this is a good question. Back in the day of brain wallets, bots were developed that triggered on any newly created wallet, then used brute force attacks to gain the key to people’s wallets in seconds after they were created in order to steal all deposited funds. Learning from their mistake we don’t use derived keys and we wait until the user has secured their key from the one time link before posting the email,DID pair to protect the users from such publicly available triggers.

How can I help?

This service would work best if paired with a key agent that can be used to maintain and manage the keys. Any help identifying or creating agents that can onboard keys would be great.

Also, this service only offers one form of verification: the entity in control of the DID also controls the email address it is paired with. The potential exists to validate other things in addition to email accounts such as Twitter accounts, LinkedIn accounts, GitHub accounts, and phone numbers. If folks would like to create more complex DID verification, that would be awesome. Please comment in github so we can direct folks to your service.

What else is missing:

Revocation needs to exist. Right now we haven’t come up with a good way to inform the ENS list if control over an email is lost.

=======

Email To Did Service

This service will generate a decentralized identity connected to an email and store the did and the email on ENS service.

This service can be thought of as a decentralized immutable key value pair of values for email -> did. This gains advantages in the verification space because a user can publicly see the authenticity of a signed credential via the did attached to the email.

Steps

POST /generate-email-did - Creation of new DID to email pairing.

1. Create new DID address and private key
2. Store private key in 1 hour TTL memory storage on the server
3. Generate a one time download unique link that will provide the private key. After this link has been accessed one time the private key is erased from memory.
4. Email the one time download link to associated email.
5. Once a user clicks on the link in their email the private key will be erased from memory. The only existence of this key will now be up to the user to store.
6. On the backend, after the email has been clicked, a write to the Ethereum ENS will happen associating this email with the did public key.

sequenceDiagram
Frontend ->> EmailToDidService: post /generate-email-did {email}
EmailToDidService->>EmailToDidService: Generate DID and store in memory cache
EmailToDidService->>Frontend: return did address only
EmailToDidService->>Email: Create unique link to user that can only be opened once
Email->>EmailToDidService: Once link is opened ack is sent to server
EmailToDidService->>ENS: Write Email->Did keypair to ENS.

Loading

6e1a664c776f74fb82cf239a568a82cf480fa21e