Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

One high level problem that jumps out at me is: When do we authenticate?

For web sites WebAuthn drops nicely into the existing login flow. The user knows what they're trying to do is log in, and so when they're prompted to touch the button or whatever it makes sense in that context.

But today most email apps just silently update all the time. So are we authenticating when the app starts and then re-using some credentials obtained to re-connect as necessary? Is that safe? Even if that's all we do (which might be safe) it means the user gets prompted for WebAuthn (to press the button) when the mail app starts, even if they aren't currently interested in email. If they dismiss it, when do we prompt them again? Because meanwhile they of course don't get any new email.



OAuth2 can handle this; you authenticate the mail client with an offline token that's valid for a long time. The mail client can refresh their tokens regularly and use a short-live token to authenticate their JMAP requests.

OAuth2 doesn't particularly care how the token is obtained, so it can handle any arbitrary authentication flow, including WebAuthn.

And it's a widely supported protocol; there are libs for C++, Java, Go, JS and others, so it should be easy to integrate.


Probably the same as now. Authentication with user supplied credentials grants you a long-living session for the current device and current mail application via a locally stored secret unlocked by the user logging on to his computer or unlocking his device (which too could be done via WebAuthn or a similar 2FA approach; e.g., a fingerprint on a smartphone).

It can be invalidated by exceeding an age limit or by the user logging out or otherwise retracting the access grant.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: