I'm not currently proposing anything but it's an interesting conversation. It's true many sites require email but I, as a user, at least would like to have a choice and not being forced to.
It is also true though that an average user "host" their emails somewhere like Google, Yahoo!, Windows Live, whatever. Not only that, they also use their emails under the TOS of those providers. That's, for one, a reason why I don't believe email is the answer, but I do favor the fact that Persona exists because I think it might bring some new ideas in the future. I remember seeing lots of t-shirts with Twitter @handlers. I recall people going crazy when Facebook started introducing vanity URLs. I also remember everybody sticking QR codes on every corner at some point. Those are just a couple examples of identities probably as good as your [email protected] ID. Identity is a huge and interesting topic, but not for this forum. BTW, authentication is one of the things OAuth kinda does address. Check out the RFCs, I'm sure you'll find lots of interesting info. On Wed, Oct 17, 2012 at 8:55 PM, Jeff Schnitzer <[email protected]> wrote: > You can want whatever you want as a user, but 99% of websites > (including mine) require an email address. Most users don't > understand "identity" as anything other than an email address. > > What else are you proposing to use as an identity? An arbitrary > screen name? A URL? We have decades of experience showing why these > are horrible ids. Whether you like it or not, email address is the > *only* widely adopted, widely understood, distributed identity > mechanism available. > > OAuth does not address identity or authentication. > > Jeff > > On Wed, Oct 17, 2012 at 1:07 PM, alex <[email protected]> wrote: >> That very fact of the email requirement is one of the reasons I don't >> like Persona and will probably never employ it as a login/authz >> mechanism. Far from every website/app/service really needs my email >> address. >> >> Probably the only good point is the "no information leak". On the >> other hand, I don't want my email address to be "leaked" every time I >> sign up. Personally, I'd prefer my provider to know where I'm signing >> in then being forced to give up my email, because I kinda trust my >> provider more than a new site I'm signing up to. >> >> If Persona goes away, a fallback to a random password actually seems >> pretty ridiculous living almost in 2013. I haven't registered with a >> new password for about a year now. A registration/signup form with a >> password field makes me go away. >> >> It's a good thing OAuth 2.0 has finally become an RFC, actually two. >> >> -- alex >> >> >> On Wed, Oct 17, 2012 at 5:48 PM, Jeff Schnitzer <[email protected]> wrote: >>> On Wed, Oct 17, 2012 at 1:32 AM, Tim Niblett <[email protected]> wrote: >>>> Jon, >>>> >>>> We're talking about identity, which is pretty catastrophic if its wrong, so >>>> I'm operating with an abundanceof caution. >>>> >>>> I love the idea of Persona, but don't know much about it, so please fill me >>>> in if you have answers to my questions/concerns. >>> >>> I'm the other half of Voost - answers inline: >>> >>>> Persona has only just gone into beta, and is under active development. I >>>> know Google has stretched our ideas of using Beta software in production, >>>> but still... >>> >>> There are really two "halves" of Persona - the user-facing login >>> system, and the primary IdP system. The primary IdP system just went >>> live, but the user-facing login system has been live with Mozilla's >>> secondary (email verification) IdP for over a year. We've been using >>> it most of that time. It's solid. >>> >>>> Persona is distributed, but there aren't any (major) IdPs signed up yet. >>>> What happens if no-one signs up? Do I have to worry about the service just >>>> stopping in a couple of years? >>> >>> Even if no primary IdPs sign up, the secondary (email verification) >>> backup IdP is a better experience than almost every username/password >>> system in existence. So even the worst case scenario is still pretty >>> good. However, Mozilla is working on a proxy IdP called "BigTent" >>> which will leverage the OpenID mechanisms of Gmail, Yahoo, and >>> Hotmail. So those users will still get a seamless experience, even if >>> the three never officially become primary IdPs for Persona. That >>> covers something like 90% of all users. >>> >>> What happens if Persona goes away? Persona logins are keyed by email >>> address. Removing Persona from your system is fairly trivial - add a >>> conventional email/pw/forgot login form, assign random passwords to >>> all your users, and give them a note letting them know of the change. >>> >>>> I use 2-factor authentication on my Google account. How will this work? >>> >>> If Google adds primary IdP support, they control the login process. >>> Even if they don't, BigTent will run the user through the standard >>> openid Google auth process. Currently (with the backup IdP) it >>> requires an email roundtrip. So 2-factor auth is accounted for. >>> >>>> In my tests Persona can be pretty slow. What are Mozilla doing about >>>> provisioning, load spikes, etc? >>> >>> I suspect the slow part ("We're sorry, this is taking a loooong time") >>> is the public key cryptography being run in javascript on the client. >>> They're balancing the need for sufficiently strong encryption with the >>> need for something that runs fast enough in javascript on crappy >>> hardware. After the first login to a new site I don't find this to be >>> an issue. Also: The protocol is designed to be implemented natively >>> in the browser, so the javascript shim is just a bootstrapping tool. >>> When browser support becomes ubiquitous (Firefox support is coming >>> soon) speed will not be an issue. >>> >>> FWIW, there is much talk of performance on the identity-dev mailing >>> list. If you have questions, it's a good place to ask. I know they >>> have significant server capacity and have put a lot of thought into >>> reliability and operational processes. >>> >>>> I've had some issues with the popup being suppressed sometimes on iOS. >>>> Don't know why, but its a no-no if users can't log in. Also, its easy to >>>> spoof the popup, as it has a weird address in the address bar anyway. >>> >>> If you see issues on iOS, please report them as bugs. I have not >>> heard reports from iOS users about not being able to log in, and we >>> have many such users. >>> >>> I also don't know what you mean about the weird address. The popup >>> address in the URL bar is https://login.persona.org/sign_in. >>> >>>> During my (very limited) testing I used 2 Google Accounts. Could easily be >>>> 2 users of the one machine. When a session expired I'd log in to account A >>>> with a password, and after logging off and in again account B was available >>>> _without_ a password which I didn't like. Not that this is any worse than >>>> other providers, we've had nasty incidents with Google login cookies. >>> >>> Persona is fairly particular about "Is this a shared machine?" >>> Inherent in the distributed nature is the fact that the primary IdP is >>> not consulted every time a user logs in; this would leak information >>> to the primary IdP. Right now when you use Facebook auth on a site, >>> Facebook knows that you logged into that site. This is a major >>> privacy issue that Persona addresses. >>> >>>> If you use Facebook as identity provider (or Google to a lesser extent) you >>>> get told about failed login attempts and other stats to help protect your >>>> account. Does/will Persona off such facilities? Will the IdPs be able to? >>> >>> I believe you are confusing the IdP with the account owner. Facebook >>> notifies the _account owner_ about failed logins, but not the relying >>> party. There's no reason why primary IdPs could not continue to >>> notify account owners of hack attempts - although you won't know what >>> specific site is being attacked, because primary IdPs don't get that >>> information (an information leak). But it's pretty irrelevant - if >>> your email password is being attacked, the solution is to make sure >>> your email password is strong. >>> >>> Jeff >>> >>> -- >>> You received this message because you are subscribed to the Google Groups >>> "Google App Engine" group. >>> To post to this group, send email to [email protected]. >>> To unsubscribe from this group, send email to >>> [email protected]. >>> For more options, visit this group at >>> http://groups.google.com/group/google-appengine?hl=en. >>> >> >> -- >> You received this message because you are subscribed to the Google Groups >> "Google App Engine" group. >> To post to this group, send email to [email protected]. >> To unsubscribe from this group, send email to >> [email protected]. >> For more options, visit this group at >> http://groups.google.com/group/google-appengine?hl=en. >> > > -- > You received this message because you are subscribed to the Google Groups > "Google App Engine" group. > To post to this group, send email to [email protected]. > To unsubscribe from this group, send email to > [email protected]. > For more options, visit this group at > http://groups.google.com/group/google-appengine?hl=en. > -- You received this message because you are subscribed to the Google Groups "Google App Engine" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/google-appengine?hl=en.
