On 25 January 2016 at 19:21, <bryand...@gmail.com
> I looked originally at https://passwordless.net/
, which I used as
> inspiration for my own (non node-js) implementation.
> The big weakness of Passwordless that I had to overcome was the
> verification link getting clicked on a different user agent. e.g. you are
> trying to log in on your desktop browser, but click the verification link
> on your phone. This was easily solved using a websocket on the original
> page to receive a pushed token as soon as the link is clicked. I guess you
> could also use long polling. Not sure what Persona did, but they also
> solved this same issue.
> If your use case involves being able to communicate with the user via
> email, as I suspect many use cases do, then identity being bound to email
> is ideal.
I dont think this is accurate. What you are saying is you'd like to
overload email (and only email) to do 3 quite different things:
1. Be a primary identifier for verification.
2. Be a memorable string you type into a form
3. Be a message delivery system.
This is from one perspective a neat hack, but from another perspective a
horrible architectural design decision.
Overloading is always a great sugar rush as it gets something working quite
fast (as happened with persona) ... the cracks appear down the line.
Typically in programming you tie key value pairs to entities (think JSON)
and can enrich identity with say your name, your avatar, your email address
... in fact it's open ended.
>> > Note also that a small group of people is currently hacking on a new
>> > BrowserID-like protocol, here:
>> > https://github.com/letsauth/letsauth.github.io/wiki
>> > You might want to see how they fare (the group includes some people
>> > who also worked on Persona, including myself).
>> Nice idea.
>> But it suffers from the same weaknesses as Persona.
>> - Lacks slightly a clean separation of identity and and authentication
>> (verifying identity) -- I may be wrong there
>> - Is too tightly bound to email. Inevitably you'll go up against the big
>> webmail providers who will end up shutting you down. Or you'll introduce
>> central point of failure a la Persona.
>> Do we really want to repeat the same mistakes again? A much better way
>> IMHO is to allow any type of identity (ie a URI) and offer the user that
>> freedom, which OAuth does a lot better. Then allow cryptographic proofs
>> verify that identity, instead of having to remember a password for every
>> site -- or in the case of Persona two passwords per email address!
>> > Cheers,
>> > Dirkjan