Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Email verification protocol

github.com

Post reply on HN
Print view View original

71–80 of 151 posts

Re: Email verification protocol

#71

Post by callahad »

philipwhiuk wrote: post #3

> User privacy is enhanced as the issuer does not learn which web application is making the request as the request is mediated by the browser. This seems extremely marginal. The point of verifying an email address is to subsequently use it to send email.

I largely agree, but I still think there's a compelling argument that blinding the issuer implicitly precludes API gatekeeping or censorship. Sites wouldn't need to pre-register with any issuer, nor could the issuer refuse to provide tokens on the basis of where they'll be used.

Re: Email verification protocol

#72

Post by thayne »

kbaker wrote: post #63
phyzome wrote: post #31

I don't know if this is the solution, but we desperately need one. It's to the point where "email bombing" is forcing service providers to add captchas to login and registration because those forms are being abused as mail-flooders.

Why is the solution not OAuth/OIDC? Or maybe creating some sort of reduced OAuth "Anonymous-Site-Verifying-Your-Email-Exists" flow?

Not everyone uses an email provider that is also also an OIDC provider.

Re: Email verification protocol

#73

Post by kbaker »

callahad wrote: post #70
Etheryte wrote: post #64

I haven't managed to formulate the exact issue yet, but if I squint, I swear there's a path to track and/or deanonymize someone visiting your site. If you have any kind of previous information about the user, such as Meta, or Google or etc, you could easily try and see if the user holds any number of emails you think they might hold. From there on out we're practically back to third party cookie tracking.

The key mitigation is that the protocol - as envisioned - is mediated by the user agent; you as a website cannot silently fire off probes that tell you anything.

This section

https://github.com/WICG/email-verification-protocol/blob/mai...

could easily be done by malicious JS, an ad script, or the website itself, and then as the RP gets the output of 6.4) email and email_verified claims.

I'm guessing that this proposal requires new custom browser (user-agent) code just to handle this protocol?

Like a secure element that makes sure there is some user input required to select a saved one, and that the value only goes to the actual server the user wants, that cannot be replaced by malicious JS.

Re: Email verification protocol

#74

Post by kbaker »

thayne wrote: post #72
kbaker wrote: post #63

Earlier quoted context omitted.

Why is the solution not OAuth/OIDC? Or maybe creating some sort of reduced OAuth "Anonymous-Site-Verifying-Your-Email-Exists" flow?

Not everyone uses an email provider that is also also an OIDC provider.

But not every email provider would support this new (from scratch) protocol either?

Just don't see the need to reinvent OAuth but with a reduced scope for just email validation. Just add a happy path for this into OAuth itself?

Re: Email verification protocol

#75

Post by 9dev »

gethly wrote: post #56
kogir wrote: post #22

Earlier quoted context omitted.

OIDC is usually limited to a small selection of providers.

Well the problem is simply user base. There is no point in being provider if you have 100 users. On the other hand, despite OIDC being standardised, there are way too many ways of implementing it. It is essentially impossible to have a "wildcard" support for OIDC providers. How do I know? I just implemented one myself. For example, providers usually support only one or very few authorisation flows, so in reality you…

I have just added OIDC support for bring-your-own-SSO to our application, and it wasn’t as bad as you make it sound: As long as the identity provider exposes a well-known OpenID configuration endpoint, you can figure it out (including whether PKCE is required or supported, by the way!)

The only relevant flow is authorisation code with PKCE now (plus client credentials if you do server-to-server), and I haven’t found an identity provider yet that wouldn’t support that. Yes, that protocol has way too many knobs providers can fiddle with. But it’s absolutely doable.

Re: Email verification protocol

#76

Post by Roguelazer »

cyberax wrote: post #61
kogir wrote: post #22

Earlier quoted context omitted.

OIDC is usually limited to a small selection of providers.

With DCR (dynamic client registration) you can have an unlimited number of providers. Basically, just query the well-known endpoint and then use regular OAuth with a random secret. There's also a proposal to add stateless ephemeral clients.

DCR is cool, but I haven't seen anyone roll it out. I know it has to be enabled per-tenant in Okta and Azure (which nobody does), and I don't think Google Workspace supports it at all yet. It's a shame that OIDC spent so long and got so much market-share tied to OAuth client secrets, especially since classic OpenID had no such configuration step.

Re: Email verification protocol

#77

Post by callahad »

kbaker wrote: post #73
callahad wrote: post #70

Earlier quoted context omitted.

The key mitigation is that the protocol - as envisioned - is mediated by the user agent; you as a website cannot silently fire off probes that tell you anything.

This section https://github.com/WICG/email-verification-protocol/blob/mai... could easily be done by malicious JS, an ad script, or the website itself, and then as the RP gets the output of 6.4) email and email_verified claims. I'm guessing that this proposal requires new custom browser (user-agent) code just to handle this protocol? Like a secure element that makes sure there is some user input required to select a…

> This section could easily be done by [...]

Less easily than you'd think.

You'd have to make an authenticated cross-origin request to the issuer, which would be equivalent to mounting a Cross-Site Request Forgery (CSRF) attack against the target email providers.

Even if you could send an authenticated request, the Same Origin Policy means your site won't be able to read the result unless the issuer explicitly returns appropriate CORS headers including `Access-Control-Allow-Origin: ` and `Access-Control-Allow-Credentials: true` in its response.

Browsers can exempt themselves from these constraints when making requests for their own purposes, but that's not an option available to web content.

> I'm guessing that this proposal requires new custom browser (user-agent) code just to handle this protocol?

Correct; which is going to be the main challenge for this to gain traction. We called it the "three-way cold start" in Persona: sites, issuers, and browsers are all stuck waiting for the other two to reach critical mass before it makes sense for them to adopt the protocol.

Google could probably sidestep that problem by abusing their market dominance in both the browser and issuer space, but I don't see the incentive nor do I see it being feasible for anyone else.

Re: Email verification protocol

#78

Post by dcm360 »

nine_k wrote: post #60

This is sort of missing the point of email verification. It's to test that the email from this particular site is deliverable and visible to the user , not just that it's a legitimate address known to work by some third party. A user may make a typo in the email, and that email might still be a valid email know to work (but for another, unrelated person). The user's email agent (such as GMail or Outlook) can mark the…

> A user may make a typo in the email, and that email might still be a valid email know to work (but for another, unrelated person).

That won't verify. The issuer should check if the request has valid session cookies for the e-mail-address that should be verified. This also implies that it just won't work for any service that uses sessions with a short timeout.

Re: Email verification protocol

#79

Post by thayne »

turnsout wrote: post #29

This is sorta interesting, but it fails on several levels. First, email verification as it exists currently is fairly simple, there are a lot of different ways to do it, and it works universally for all email addresses (as long as you don't expire codes too fast for servers that use greylisting). This protocol solves a pretty contrived problem ("By sending the email verification code, the inbox provider knows the use…

> This protocol solves a pretty contrived problem ("By sending the email verification code, the inbox provider knows the user is using that service!")

I agree with a lot of what you are saying, but I think the main motivation is actually trying to reduce friction for the user to verify their email, which is good for the user, because it makes registration easier, and good for the company, because less users bounce at the email registration step.

But yeah, this is quite complicated, and there isn't a lot of motivation for email providers to implement it.

Re: Email verification protocol

#80

Post by Arch-TK »

hirako2000 wrote: post #69
Arch-TK wrote: post #46

Cool, so if I want to use myname+yourdomainname.here@myemail.com to register on your application I now first have to go to some third party(?*) to verify that myname+yourdomainname.here@myemail.com is valid**. And then, once I've gone through the hassle of that, I have to go back to your website to use the third party service to verify my email. Thanks I guess... * It's not clear if this service would be provided by…

You are using a workaround for your privacy, and to prevent spam (not solid at either). The protocol proposes to alleviate a UX burden. The back and forth. it would need Google (and other email provider supporting the + trick) to allow you to certify your ownership of a wild card set of email addresses, i.e anything matching what's before the + and the protocol would work just the same. Absolutely reducing some frict…

> You are using a workaround for your privacy, and to prevent spam (not solid at either).

Neither, I do it so I can track which companies sold my email address on without my permission so I can put them on my shit list / report them to my government / shame them on the internet / whatever.

> The protocol proposes to alleviate a UX burden. The back and forth.

That seems to be _one_ aspect but that assumes you're logged into whatever email verification provider is in use.

> it would need Google (and other email provider supporting the + trick) to allow you to certify your ownership of a wild card set of email addresses, i.e anything matching what's before the + and the protocol would work just the same. Absolutely reducing some friction without adding you the extra burden your trick currently involves.

You assume that it's the email provider which has to implement this, which isn't so clear to me.

Only the email provider can attest that + addressing is in place, if a third party is involved, they can only explicitly match on full email addresses.

Like I said in my original comment, if it's the email provider that has to implement this, then the bulk of my issue is gone. Aside from the fact that now, as my own email provider, I have to implement this protocol somehow (easier said than done given my current infrastructure approach is aimed towards moving as many things into a non internet facing network).

Post reply on HN