111–120 of 151 posts
Check this profile for the email if you wanna ask for more info or get updates.
Make everything what works complicated. There is no advantage. "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." Every web application nowadays send you a welcome, onboarding, reminder after the verification. (No user privacy enhancement) So we get a new process that solves nothing, but makes everything complicated. (And comp…
The convenience advantage is significant, and it goes farther than convenience, since it’s very common for services to have their verification mail blocked or sent to spam. (Bonus pain: there’s no user-visible difference between delayed and blocked mail.) The privacy advantage is also significant and real: no, not every web app sends an onboarding reminder, and the current state of web apps came to be without this fu…
So instead, there’s no verification mail and it’s the next message, the one that you actually wanted, that gets blocked or sent to spam.
The “privacy advantage” that the issuer can’t learn the identity of the application that wants to send mail seems to me to be a significant functional liability. If it instead produced a token that said to the email service provider “see, the message was invited”, now that would be useful. (It would raise concerns of its own, but it would at least be useful.)
Earlier quoted context omitted.
One other problem is there isn't a way to definitely know that a given OIDC provider is authoritive for a given email. Although, this spec could probably be simplified by just having a dns record that specifies the domain to use for oidc for emails on that domain. Another is that there is a lot of variance in OIDC and OAuth implementations, so getting login to work with any arbitrary identity provider is quite diffic…
> a dns record that specifies the domain to use for oidc for emails on that domain. Oooh I like this idea!
Make everything what works complicated. There is no advantage. "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." Every web application nowadays send you a welcome, onboarding, reminder after the verification. (No user privacy enhancement) So we get a new process that solves nothing, but makes everything complicated. (And comp…
> There is no advantage. I can't tell you how many times email verification context switches made me completely lose track of what I was doing. There's literally no worse context switch than having to go into your inbox, wait for an email, then come back to the appropriate tab to complete registration or login. There are probably dozens, maybe hundreds, of services I never finished registering for all on account of t…
Then it's something maybe the customer isn't interested in the first place. Most of the time mail just works for me only issues are sometimes greylisting and it takes hours.
I can understand it from the company side, but not sure how well it really works when someone use a mail app on mobile and on desktop not even logged into the mail account.
Why must apps require email? Why not only username and password?
Most people want a way to recover their account if they lose those creds, especially when you ask them once they’ve lost their creds. It’s also a rudimentary PoW system against bots. And people who don’t want to share their email can use a temp email service, so it’s no skin off their back.
That seems to be a better option for bots than for actual users: if you care about the account, you probably would not want to make its password resettable via a service like that. Or even via a regular email provider you do not trust, and those could easily be the only kind available.
I like the idea in general - an OIDC-like flow without needing any a priori setup. But, the RP has only a signed token with the pubkey in DNS, so this doesn't prove anything about the user unless the RP also verifies against some trusted and known email providers. This is absolutely awful for the Internet and makes sure power stays concentrated. PLEASE don't let this become a thing.
Second, this doesn't improve privacy. Most RPs will send an email right at signup, or soon thereafter. Thus the email provider does learn of the individual's association with that web application.
A last issue that's immediately obvious, is that you have to use a webmail interface.
Make everything what works complicated. There is no advantage. "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." Every web application nowadays send you a welcome, onboarding, reminder after the verification. (No user privacy enhancement) So we get a new process that solves nothing, but makes everything complicated. (And comp…
The convenience advantage is significant, and it goes farther than convenience, since it’s very common for services to have their verification mail blocked or sent to spam. (Bonus pain: there’s no user-visible difference between delayed and blocked mail.) The privacy advantage is also significant and real: no, not every web app sends an onboarding reminder, and the current state of web apps came to be without this fu…
Depending which privacy, currently if I input a email into xyz noone can trust that this email belongs to me. In the future every email input can verify if the mail belongs to me, that scream abuse and more new things that try to fix the old.
Make everything what works complicated. There is no advantage. "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." Every web application nowadays send you a welcome, onboarding, reminder after the verification. (No user privacy enhancement) So we get a new process that solves nothing, but makes everything complicated. (And comp…
> There is no advantage. I can't tell you how many times email verification context switches made me completely lose track of what I was doing. There's literally no worse context switch than having to go into your inbox, wait for an email, then come back to the appropriate tab to complete registration or login. There are probably dozens, maybe hundreds, of services I never finished registering for all on account of t…
Sounds like a useful and very effective filter to not create accounts for things that do not really matters to you.
Is there a nonce relay vulnerability here? You try to verify your email with site A. Site A starts an email verification with site B. Site B sends a nonce to A, A relays the nonce to the user. The user generates the proof, sends it to A. Then A sends it to B.
Earlier quoted context omitted.
The new standard relies on some possibly third party (at least that seems somewhat implied here) which has a database of email addresses which it can attest exist and which is tied to some user authentication. If the email address isn't yet known to this third party (or, you are not logged in), there _will_ be a context switch which in my example case will occur for every registration since I use a per-entity email a…
Agree with you, though potentially easily remediated if that third party provisioned for the “+” convention.
-site-@ go to my personal mailbox
-app-@ go to my partner's mailbox
-account-@ go to my daughter's account
Sure you could in theory set up the server side verification mecanism for these pattern too. I am just stating that the +suffix stuff is not the only way used.