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.
