This sounds an awful lot like OpenID (2). What makes it different? My OpenID login (aka XRI i-name) is "=chris.hills" and works on sites that support it.
Portier – An email-based, passwordless authentication service
21–30 of 89 posts
Re: Portier – An email-based, passwordless authentication service
#22Is it possible to create an email-like service that doesn't actually handle email, but only serves as an identity endpoint to be used with Portier? Like, say, I create an account that reads "me@fiatjaf.com" and implement something on my fiatjaf.com server so that I can use it to login using Portier?
Yes, it's an OIDC-compatible flow, so if fiatjaf.com implements an OIDC provider that will authenticate "me", you should be good.
Re: Portier – An email-based, passwordless authentication service
#23Is it possible to create an email-like service that doesn't actually handle email, but only serves as an identity endpoint to be used with Portier? Like, say, I create an account that reads "me@fiatjaf.com" and implement something on my fiatjaf.com server so that I can use it to login using Portier?
It will be! We're not sure what the eventual protocol will look like, but it'll probably start with webfinger, which can then point to whatever authentication gateway you want. We only need SMTP as the base case in the chain of strategies: https://github.com/portier/portier.github.io/blob/master/Des...
Re: Portier – An email-based, passwordless authentication service
#24Hi! A few of us have been hacking on this scaled-down, spiritual successor to Persona. The core idea is that you treat this (self-hostable!) microservice like a black box: email address goes in, validated proof of identity comes out. No passwords, and no secrets to store in your application’s database. The service itself is also effectively stateless: aside from caching, the longest lived key in Redis has a TTL of 15…
I read that you're not planning to integrate with Facebook[1], but what about other providers, if they allow you to request access to almost nothing? Perhaps, for example, allowing people to use @github.com would prompt them with a GitHub OAuth screen and identify them. Why not?
I see, it is not a valid email. Maybe there should be a Portier fork that implemented stuff like that, though.
[1]: https://github.com/portier/portier.github.io/blob/master/Non...
Re: Portier – An email-based, passwordless authentication service
#25Earlier quoted context omitted.
The problem with that is that it breaks a user's flow too much :/ It's a good fallback, and it has many benefits, but having to switch contexts to the mail client and wait for an email is too cumbersome for the user (although it's not too bad when paired with a long-lived session). That's why Portier supports other auth providers, so you can have the best of both worlds.
Yes, and thus the reason it hasn't caught on. It's such a better idea than 75% of the passwords being Winter2016 though.
Agreed on both counts. Given the imminent Persona shutdown, and until I can move it to Portier, I've implemented it on Pastery as a stopgap: https://www.pastery.net/login/
I think it works quite well (the session lasts until you log out).
Re: Portier – An email-based, passwordless authentication service
#26This sounds an awful lot like OpenID (2). What makes it different? My OpenID login (aka XRI i-name) is "=chris.hills" and works on sites that support it.
There's a little more discussion of that over on Lobsters: https://lobste.rs/s/fkosun/. The TL;DR is that URIs just didn't work for the mass public. You had to supplement the login form with a NASCAR-esque wall of logos, which was awful for different reasons.
Thus, Portier, and Persona before it, chose to identify users by email addresses. I talk a little bit about that at 9:05 in my PyCon 2013 talk on Persona: https://www.youtube.com/watch?v=nJff23UdNAI#t=9m05
Re: Portier – An email-based, passwordless authentication service
#27Postmark just dropped our outbound email for high bounce rates. Falling back to SendGrid :/ Try again in 5 minutes.
Edit: Ask HN: Any suggestions for solving this? Hitting the frontpage means people are spamming the login form with bogus addresses like a@a.com that bounce and cause trouble for us and the ESPs. Not ideal, but I'm not sure how to solve this for a small scale side-project. Discussion in https://github.com/portier/portier-broker/issues/96
Re: Portier – An email-based, passwordless authentication service
#28Earlier quoted context omitted.
Yes, and thus the reason it hasn't caught on. It's such a better idea than 75% of the passwords being Winter2016 though.
Agreed on both counts. Given the imminent Persona shutdown, and until I can move it to Portier, I've implemented it on Pastery as a stopgap: https://www.pastery.net/login/ I think it works quite well (the session lasts until you log out).
Did similar at Link Packets, http://linkpackets.com/ - more of a proof of concept / handy thing project.
Re: Portier – An email-based, passwordless authentication service
#29Real question here is 'why isn't auth built in to the browser'. Lack of browser support is the reason oauth is so complicated (it relies on HTTP redirect to pass information around). Imagine a web experience sans cookies and sans JS. If you take into account the economics of content, it can only happen with browser-mediated login.
Client cert support has been built into the browser for a long time.
One problem is that you basically have to build out non-cert authentication to give people certs to install. That, and there's little to no mutual trust, so every institution needs to issue and manage its own certs.
Re: Portier – An email-based, passwordless authentication service
#30Hi! A few of us have been hacking on this scaled-down, spiritual successor to Persona. The core idea is that you treat this (self-hostable!) microservice like a black box: email address goes in, validated proof of identity comes out. No passwords, and no secrets to store in your application’s database. The service itself is also effectively stateless: aside from caching, the longest lived key in Redis has a TTL of 15…
I read that you're not planning to integrate with Facebook[1], but what about other providers, if they allow you to request access to almost nothing? Perhaps, for example, allowing people to use @github.com would prompt them with a GitHub OAuth screen and identify them. Why not? I see, it is not a valid email. Maybe there should be a Portier fork that implemented stuff like that, though. [1]: https://github.com/porti…
To me, that sounds like a useful shorthand. It would probably not at all be difficult to add support for that to the broker (apart from the usual wrestling with Rust), so yeah, why not. Though I maybe miss some implications for the RP – breaking the expectation that it is just an email is bad if you use the email as an email, and if you want to have the option to easily move away from portier.
The FB thing was more, iirc, that you don't want to enter an email and then get the FB dialogue just because you used your email on FB.