Attestation of users email address

Implementations Web
1

I was thinking about TokenScript, Token-Negotiator, Attestation.id, Authenticator last night / this morning.

My thoughts were as follows:

The end goal is to allow the use of Web 3.0 Tokens to be used as attestations / or utilities on client side applications.

The way we are approaching this is to use web 3.0 technology such as MetaMask Signature, and traditional Cryptography and technologies to provide this solution.

We want to provide two levels of attestation / ability to use the tokens:

A: Soft / or Light attestation. They most likely own the token but we cannot be sure until they have signed / done OTP etc.

B: Full attestation. They must prove they have the credentials to progress - wallet address password + OTP

Use cases:

A: To see a discount, open hidden content, lend someone a CryptoKitty (light attestation - to explore with limited permissions)

B: Full permissions (on chain / off chain transaction level permissions)

If we think about OAuth today, sign in via Facebook, Sign in to Booking.com, Twitter, Linked In, Westpac, ING, Williams Betting, Spotify….

These providers already know the end users email address - via their database, or via social auth (the users email address is given).

My thought is, should we replace Attestation.id with a simple ZKP function that Webster can use to check the email address is the same one as the one they have on record in for that user?

Using OTP via email is essentially the same - but requires more work for the end user to navigate through a modal and second tab to check their mail.

@weiwu.zhang, @foxgem, olehhrib, jot2re - please let me know your thoughts of this solution; in regards to the integrity and security towards forming the full attestation (authenticated token).

2

I am a bit unsure exactly what you mean regarding the use of a simple ZKP function. Because any user can claim that they control a certain email address, but if it has not been verified by a trusted source, then we cannot be sure of that. However, we originally handled this by having attestation.id issue an IdentifierAttestation to the user's email, but in a hidden way, such that it required knowledge of a secret to be able to prove that they knew the email address hidden in the attestation. This allows the user to construct a simple ZKP to show webster that they have an attestation to a specific email. Is this what you mean @nicktaras ?

3

Thanks @jot2re I see what you mean.

My thought above has a vulnerability - because if bad actor "Alice" has knowledge of "Bob's" email address (e.g. via a leak) they could use the attestation inside the browser + use a hacking tool to attest with "Bob's" email address.

I see the advantage of using social auth as;

  • no ui to maintain,
  • simple, trusted end user experience

From raising this, I can see attestation.id as the best option/solution for us.

Unless we were to build attestations with social auth (we host a centralised app that can auth with; facebook, twitter ... apps, they sign in with this instead of email OTP) - allowing us to reduce steps in the process for the end user.