11 ms·
Introducing Mozilla Persona, An Identity System for the Web
- wmf 14y agoNow if we can just get Chrome to agree on the same protocol.
- iamdave 14y agoI'm sure Google is watching this very closely, as I'm already thinking of the benefits this could have when used in the context of the Android OS
- nightpool 14y agoTechnically, this will work with chrome as-is, it just won't have a slick native interface. The basics are already implemented by Mozilla as a HTML/js library you can use on any browser.
- drivebyacct2 14y agoIt wouldn't even be that hard to have an extension scan the dom and offer the signed assertion automatically as Firefox would/could.
- rubberband 14y agoSo we have this, Open ID, Facebook, Twitter, Google, Microsoft Passport/Live ID, and probably like five other major players I'm forgetting. I apologize for being pessimistic, but this just doesn't seem like a solvable problem. I want it to be solvable, but players like Facebook benefit far too much for them to not push their particular version of "universal" login on everyone. Every player seems to think they are the One True Solution... But so far, it's all one big mess. I don't see it getting better any time soon.
- deleted 14y ago[deleted]
- cleverjake 14y agowe had dozens of search engines when google came out. someone just hasn't got it right yet.
- uptown 14y agoAnd yet some would argue that Google has begun to get search wrong. What happens when the "right" identity solution does the same?
- diffeomorph 14y agoYou get another one. There's no true stability in this world. You try your best to find an optimal solution and keep working at it.
- cleverjake 14y agoyou could argue, but statistics would show you otherwise for the foreseeable future. regardless of wether or not they are 'losing it' they clearly got it right for a very long time.
- Alex3917 14y agoI think if you look at Kim Cameron's Laws of Identity, it's clear that the research team at MS has had it right for at least a decade, it's just that none of their ideas have made it into production. http://www.identityblog.com/stories/2004/12/09/thelaws.html http://www.identityblog.com/stories/2004/12/09/thelaws.html Ballmer had both the plans and source code for an identity product that would have been 10x more advanced than Facebook, but they decided to axe the project so they could make the Zune instead.
- nl 14y agoBallmer had both the plans and source code for an identity product that would have been 10x more advanced than Facebook ANYONE can make an identity product that is 10x more advanced than Facebook. The problem is making an identity product that is 10x SIMPLER than Facebook, without relying on a single source of identity verification.
- rfk 14y agoThere is work underway to transparently proxy between several major identity providers and the BrowserID protocol that underlies Mozilla Persona: https://github.com/mozilla/browserid-bigtent
- mbrubeck 14y agoBrowserID is designed to be integrated into the browser. There are some huge usability benefits possible when your browser can log in for you. If the browser UI succeeds in reducing friction for signup and login, that could motivate sites to adopt the protocol.
- rangibaby 14y agoRandom thoughts: • The name "Persona" is odd considering something by the same name already exists in Mozilla-land, a fact they seem to be aware of. • I hope sites use this instead of forcing Facebook login!!
- mcpherrinm 14y agoThe other personas (aka "lightweight themes") are supposedly being re-branded (thought I don't remember what they're calling them). It apparently hasn't happened yet, which will surely lead to some trouble.
- shalmanese 14y agoWhy don't they call them lightweight themes?
- gamzer 14y agoThis comment sounds so innocent but it really started me thinking. When should one call things simply by their name and when should one create a new name? Would Twitter be the same if it was for short text messages? Or are Tweets so different that they deserve their own name?
- Angostura 14y agoBrands have value that can be protected with trade marks. You can't protect generics with trade marks (easily)
- mcpherrinm 14y agohttp://blog.mozilla.org/addons/2012/03/01/personas-are-joining-the-themes-family/ http://blog.mozilla.org/addons/2012/03/01/personas-are-joini... The term chosen was "background theme", since a background image is essentially all that they are. "Skin" was also under consideration.
- hinting 14y agoHonest question: As an app builder, why would you use this instead of facebook? Many more users are going to have Facebook logins already, and it provides social information that may be useful to your app. (Hoping to hear answers other than the dev-centric 'I don't like facebook')
- cleverjake 14y agowell, my first guess is more people have web browsers than have a facebook account. if this can be standardized and propagated throughout all major clients, the user base would be much larger.
- thristian 14y agoOne good reason: If Facebook goes broke, or decides to stop offering their authentication service, or anything like that, your user database is now filled with useless Facebook user IDs. If Mozilla's Persona system goes broke or gets taken offline, your user database is now filled with perfectly good, validated email addresses, so you can still contact your users and/or match up new registrations with existing accounts.
- immad 14y agoIf you ask for the permission Facebook will give you the users email address. You can additionally just ask for the users email address. Any one building a serious business using facebook auth does one of the above.
- tg3 14y agoIIRC email is one of the few pieces of information about users that you get by default, and cannot be revoked by the user (without revoking the app entirely)
- patja 14y agoIncorrect. You must request and obtain the extended permission 'email' in order to retrieve the user's email address from Facebook.
- glassx 14y agoI believe that a native implementation has been on their plans from the start, but I haven't heard much about it lately. Here's some mockups: http://people.mozilla.com/%7Efaaborg/files/projects/firefoxAccount/index.html http://people.mozilla.com/%7Efaaborg/files/projects/firefoxA... There's also some work on integrating existing e-mail providers, so you can get instant identities: http://identity.mozilla.com/post/17207734786/id-provider-support-now-live-on-browserid http://identity.mozilla.com/post/17207734786/id-provider-sup... This is probably the web-thing I'm most excited about today, even though the development is kinda slow. I really want to implement it as a sole identity provider on my websites some day. EDIT: I also began writing a Safari extension that would work like the mockup above, but gave up halfway since it was too convoluted and totally insecure... maybe I should try writing a SIMBL plugin or something like that.
- egs 14y agoA website relying on a single service to serve as a sole identity provider seems replete with risks. That sounds remarkably similar to Microsoft's Passport, an idea that was a non-starter for everyone except Microsoft.
- glassx 14y agoIt's hard to explain, but it's not much a "service" - the current implementation is just a "shim", since no browser supports it natively. Client-wise, it's just a JavaScript API. In the future, your browser will store your keys, not Mozilla. But even with the current implementation it is possible to validate the assertion in your server without contacting browserid.org, but AFAIK nobody did it yet. (I tried to find a reference for that, but they took it down from their Wiki. It used to say "You may choose to validate assertions on your own server": https://github.com/mozilla/browserid/wiki/How-to-Use-BrowserID-on-Your-Site/5a1abdd205221e39621c17d7cc3050b3f3b97eed https://github.com/mozilla/browserid/wiki/How-to-Use-Browser... - the verification code is still online, though)
- callahad 14y agoYour browser already stores your keys, even with the shim. :) Faaborg's mockups are awesome, but they're well over a year old and not really guiding our current work. Still, definitely take a look at them, if nothing else than for the cool way of doing mockups! You can definitely do your own verification without having us in the loop, but we'd urge you to hold off until this fall; the IETF is still standardizing some of the data formats we're using, so the exact serialization of keys and assertions might change between now and then. By using our verifier, you're certain to be up to date. The easiest way to verify-it-yourself is to just run our code locally; it's all open source, after all :) https://github.com/mozilla/browserid https://github.com/mozilla/browserid (PS: The docs are now on MDN, instead of the GitHub wiki: https://developer.mozilla.org/en/BrowserID https://developer.mozilla.org/en/BrowserID )
- drivebyacct2 14y agoI really, really like Persona. It's federated and it gives the identity provider a vast amount of control over the security protecting accounts. Want to use SSH keys for auth? Okay. You can do that.
- alberich 14y agoDo you have any links to specifications on it? I'm very interested on identity federation. But the post doesn't give away much info on persona's capabilities.
- callahad 14y agohttps://github.com/mozilla/id-specs/ https://github.com/mozilla/id-specs/ Pull requests and new issues welcome :)
- nnethercote 14y agoThat link is to a very high level, non-technical overview, which is not a good link for HN. Try these links, which go into much more detail, answering the "why bother" questions. https://developer.mozilla.org/en/BrowserID/Why_BrowserID https://developer.mozilla.org/en/BrowserID/Why_BrowserID http://identity.mozilla.com/post/7899984443/privacy-and-browserid http://identity.mozilla.com/post/7899984443/privacy-and-brow... http://lloyd.io/how-browserid-works http://lloyd.io/how-browserid-works Note that BrowserID was the old working name for the project.
- greggman 14y agoI know this probably fits only me but I never use my email address as id. Every company and every account I sign up for I give a different email address. I'm not about to use a single one for my ID. Especially when they are easy to spoof (any one can send mail as you@there.com) and they are easy to spam and abuse. I had an email address that got 3000 spams a day. That's why I never give use email as ID because I want to be able to disable any email address that's giving me trouble. So, not interested in BrowserID I think. Or maybe I didn't grok it.
- mbrubeck 14y agoBrowserID lets you use any number of email addresses and choose which one to use for a given site (though I think the current UI might get a bit cumbersome if you have dozens attached to one Persona account).
- rfk 14y agoThere is a lot of scope for one-time emails, pseudonymous emails and other kinds of not-my-primary-email authentication systems within Persona. One simple example of how this might work is MockMyID: https://mockmyid.com/ Try logging into a Persona-enabled website with anything@mockmyid.com - you will be able to authenticate without entering any password or giving away any personal information. Of course, so can anyone else, but it might give you an idea of the possibilities in this space.
- eps 14y agoBut what is being authenticated exactly in this case? My understanding of Browser ID is that it's a way to provide an email address to a site operator that doesn't need to be confirmed. It's a single-step subscribe/account creation, rather than an authentication per se.
- rfk 14y agoBrowserID provides a way to say to a site "I own this email address", as well as a protocol for the site to verify such an assertion. What the site chooses to do with the information is up to them. It can be used for account creation or signup, but works equally well for authentication to an existing account. In the mockmyid case, you are saying "I own the address xyz@mockmyid.com". But the MockMyID server will happily let anyone make such an assertion, so you get a simple kind of mock identity. Of course, you shouldn't use that as your identity on any sites that you care about. Mail to anything@mockmyid.com doesn't go anywhere, and there's nothing to prevent other people from using the same @mockmyid.com address. But it's a neat example of the sort of thing that is possible.
- nostromo 14y agoOne of the reasons FB and Twitter OAuth became so popular is because they solved a problem for the user (remembering passwords) and also gave the site owner a big carrot (social growth mechanics, more user data). This seems much more one sided -- it's good for the user that doesn't use FB or Twitter but 'meh' for the website. I'm not sure we'll see fast adoption like we have for OAuth.
- alberich 14y agoMore power to the user is good. Current IdM solutions leak too much data to the service providers/relying parties. What really sucks about all solutions is that once the data has leaked, you gotta trust the service providers not to sell or give your data away.
- richardw 14y agoI've wondered about "data-renting" setups before. For example, rather than giving a company my postal address, give them a token they can send to, and a post fulfilment company delivers to the actual address. If the address moves, the token follows. If I decided to revoke the token, they can't send me mail. Can't do that with all digital data, but you could with e.g. email addresses, cc's, addresses, maybe phone numbers.
- icebraining 14y agoThat's been possible with email addresses for decades. "Free email forwarding" returns plenty of services which give you an address that forwards to your own, and which you can revoke at any time. Personally, I just use a catch-all on my domain, but that requires you to have one. Same with credit cards: my bank offers a free service where I can set up as many virtual CCs as I want. Until recently they were single payment only, but now you can choose if it's single or multiple. Forwarding (physical) address exist too, 'though they seem to be mainly targeted at people outside the US who want a address there, and they cost you an extra shipping fee, of course.
- callahad 14y ago
- rtyrtyrtyrty 14y agoEPIC FAIL: http://www.freeimagehosting.net/us75p http://www.freeimagehosting.net/us75p This buq with webfonts are reporter year ego and stili NGASF on Windows xp Firefox 13.01 its start on Firefox 4
- nnethercote 14y agoI think you're in the wrong thread.
- andyfleming 14y agohttp://mootools.net/forge/p/browserid http://mootools.net/forge/p/browserid ^ adapted from this?
- ubernostrum 14y agoThat is an implementation of BrowserID :)
- Of_Prometheus 14y agoIs there a list of all the sites, besides Open Photo, that have already enabled BrowserID?
- zerostar07 14y agoI don't think there's an official list, here's two: * http://noteplz.com/ http://noteplz.com/ * http://textchannels.com http://textchannels.com
- callahad 14y agoMozilla has tons of stuff in production running Persona, so we're totally dogfooding with Bugzilla, Mozpad, MDN, Add-ons Builder, Firefox Affiliates, Firefox Flicks, Mozilla Marketplace, and Mozillians. Voo.st, OpenPhoto.me, Crossword.TheTimes.co.uk, 5apps.com, Haskellers.com, etc. We're also working to get Persona working with some larger sites, but most of those are waiting to go live until after we formally announce API stability next month.
- zaroth 14y agoI read a comment that the email provider can allow anyone to log into your accounts because they can sign any public key they want to say it's valid. This seems to be true from my 10 minutes reading the spec. I know a password reset function that uses only email is basically the same level of trust in the email provider, and I'm no fan of email based password reset, but this feels even worse -- literally abdicating your security entirely into your email providers hands? Gmail is great because it's free, but I didn't join gmail with the idea of giving them the keys to my life. Another thing I don't fully grok yet is the 'issued-by' concept. Does this mean that 'Relying Parties' need to whitelist all the secondaries they are willing to trust? How can that possibly fly? Finally, in a native implementation, how is the keyring persisted on disk kept safe from malware extracting your private keys? If the browser can decrypt the keyring, so can malware. Ok I lied, one more thing... Is there a password prompt when you first sit down at the native BrowserID implementation? Or does it just assume that your browser means its you sitting there?! Then of course the next question is, how do you tell your browser you are walking away (akin to logout) and is it going to expire all sessions that were tied to your identity when that happens? So much to worry about...
- callahad 14y ago> I didn't join gmail with the idea of giving them the keys to my life. Nor did I, but as you acknowledged, that sort of control has entered the status quo. Anyone who can break into your email account can trivially reset your password on many sites, at which point, per-site passwords just become another liability. We get rid of those, and empower you to independently decide who to trust with your identity. > Does this mean that 'Relying Parties' need to whitelist all the secondaries they are willing to trust? How can that possibly fly? The idea of a secondary (or fallback) isn't central to the BrowserID protocol; it's just a convenience so that we can actually bootstrap a fully decentralized system. In practice, all libraries trust Mozilla's fallback Identity Provider by default. As email providers add native support for the BrowserID protocol less and less traffic passes through our fallback until it simply and automatically drops out of existence. > If the browser can decrypt the keyring, so can malware. Yep, that's true. Same with your password manager, though we are trying to mitigate this by making the certificate itself relatively short-lived. To wit, each client has its own ephemeral keypair with certificates that expire regularly, requiring a silent renewal with the Identity Provider. This creates an opportunity for the Identity Provider to refuse to renew a certificate, should one of your machines become compromised. > Is there a password prompt when you first sit down at the native BrowserID implementation? Or does it just assume that your browser means its you sitting there?! If you have a valid, unexpired certificate available, you'll be able to log in to things straight away. If not, you'll need to authenticate with your identity provider to get a fresh cert. Native clients are, of course, free to implement additional security measures before allowing access to the keystore.
- qznc 14y agoI tried the OpenPhoto example. One thing that introduces friction compared to username-password: The first time, I have to create a Persona account. Unfortunatelly, I'm not logged in afterwards. Most sites nowadays log you in right after account creation and just wait for email-verification later. Is that even possible with Persona?
- callahad 14y agoYeah, that totally sucks, and we're working on it. OpenPhoto is still using our old API, which can't handle post-verification redirects. Our new API does this automatically. Grab a mailinator account and try signing in to http://123done.org http://123done.org. As for creating a Persona account, we're trying to fix that, too. Next month we'll be turning on a feature (codenamed "bigtent") that verifies Gmail, Hotmail, and Yahoo users by sending them through their respective provider's OpenID or Oauth endpoints. No more new account creation. No more email verification loop. Just three clicks and you're done.
- Flimm 14y agoThe webpage should suggest a website other than OpenPhoto, then. First impressions count. (I say this as someone who's really excited by Persona and who wants it to spread as quickly as possible.)
- five_star 14y agoThough this is something helpful, I find Mozilla a little slower than google chrome.
- carlesfe 14y agoOkay, I have read the specs, the FAQ, the diagrams, and tried some examples, but I can't really understand how it works. Could somebody do a quick summary for me? I would appreciate it very much.
- callahad 14y agoI really, really need to post something like this on our blog soon. Watch http://identity.mozilla.com/ http://identity.mozilla.com/ for something more polished next week or so. I'd also strongly urge you to just try implementing it on a site. It'll literally take less than 30 lines each of javascript on the frontend and python on the backend, and it'll really demystify the flow between the site and the user. As an analogy, we work really similarlu to showing a bouncer your ID. The ID has identifying information on it, and it has features that allow you to know that it's authentic and hasn't been tampered with. The bouncer can learn how to validate IDs issued by many different authorities, and can remember this when he sees other IDs from that same authority. Our IDs are personal public/private keypairs, signed by the email provider. So, quick and dirty, here's how we work: I want to log in to 123done.org as foobar@eyedee.me, but to do that, I need an ID with eyedee.me's digital signature on it. So in a popup, my browser sends me over to eyedee.me to ask for that signature. Before eyedee.me will sign a public key with my name on it, I have to prove that I really am who I say I am. It's just between the two of us, so I can prove my identity however eyedee.me wants. It could be a password, an RSA keyfob, or entering a code from a text message. Whatever it is, eyedee.me is happy that I am who I say I am, and they sign my key and hand it back. I want to show this to 123done.org, but it's not enough for it to be valid, since we have to prevent malicious websites or phishers from copying it and masquerading as other people. For my ID to be a valid login token, I have to add two more things: what site I'm logging in to, and a timestamp so it expires soon after I hand it over. I then sign that with my private key. I then take that whole bundle and hand it off to 123done.org. 123done verifies it by asking for eyedee.me's public key (which can be cached), and seeing if that matches the first signature on the ID. If it does, then 123done pulls out the validly signed public key, and checks if it matches the second signature on the ID. If that matches, then the whole package is valid, and 123done knows that I really am foobar@eyedee.me. Does that make sense? It really just revolves around a document with two signatures: An email provider's which says "This key is associated with this account," and a user's which says "I am associated with that key."
- dendory 14y agoFor most people, it goes like this: click on the Facebook login button, done. OR, click on personaID, have a new window open, enter email, enter password, go through setup, get back to site. This will be hard for most web users to adopt.
- huragok 14y agoYeah but once the registration hurdle is jumped, it's click, password, go. Some of us do prefer passwords and multiple identities in this age of homogenized identity.
- isaacaggrey 14y agoThat's not entirely fair. If you're not logged into Facebook, you still have to log in there as well. As huragok said, once you're past set up, it is just click, password, and go as far as I can tell. However, I'm not arguing against that a lot of people probably _are_ already logged into Facebook.
- Angostura 14y agoFor other people it goes 'click the Facebook login button' - What? This POS uses Facebook? What access does it get to my Facebook account? Is it one of those weird things that posts all over my Facebook wall? [cancel]
- 27182818284 14y agoGenerally I've noticed people are fine with FB login as long as you add "Don't worry we won't spam your friends without your permission" or "We won't spam your feed, we just want to know it's you." or something like that
- stickfigure 14y agoMy company is one of the early adopters of Persona/BrowserID. You can see our dual-auth (with Facebook) system here: https://www.voo.st/ https://www.voo.st/ We've been live for several months now in the Real World - our userbase (amateur athletes) is primarily nontechnical. About half of our users choose Persona/BrowserID and half choose Facebook. We were initially concerned about the BID login flow (in particular, the immediate email roundtrip) but it hasn't been a problem and the UX has been refined quite a lot over the last month or two. For a mass-consumer audience, the combined FB/Persona solution is excellent: * Facebook unquestionably has the slickest auth experience, even eliminating the followup name/sex/bday questions. However, a significant percentage of the world (possibly > 25%) either Hates Facebook or wants to keep their Facebook account isolated. This is unlikely to change in the near future and could even get worse depending on what sleeping dogs Zuckerberg decides to kick next week. We don't have the option of alienating the FB haters and we wouldn't want to anyways. * The Persona UX is good and rapidly getting better. BigTent integration with gmail, yahoo, hotmail will bring one-click login to those users. A native experience is being built into browser chrome. All this is coming without me having to write code. It may not be as slick as Facebook, but I like where this train is headed. * Integration is simple compared to writing a username/password system. The API is incredibly easy to work with. Dual-auth with Facebook is a little more complicated, but a complete Persona-based auth system is a question of hours, not days. * The fact that identity is just an email address makes it easier to integrate with existing login systems. In our system, you can log into the same account with both Facebook and Persona as long as the emails match. No, email is not a perfect identifier, but even nontechnical users understand it immediately and really - what other option is there? "What email address did I use?" is a lot better than "What weird combination of letters and numbers did I use as a login name?" * Support on the Mozilla dev-identity list has been fantastic. We're pretty happy. Honestly, I don't ever see myself writing another username/password login system ever again. Persona is less work for a better UX.
- dabeeeenster 14y agoOK so I tried to sign up to your site with BID and am pretty confused: I'm using Chrome. Don't know if that affects things. Anyway. Hit Browser ID, asks me for my email address. OK fine, add that in. It then says (quickly, and temporarily as it's an AJAX load), that it's looking up my email provider (Google Apps). It then asks me for my password. So now I'm totally confused. I've not signed up with your site or BID before, so I dont know if it wants my GAPPS password or a new password. I don't feel like I want to put in my GApps password, as there is no Google branding anywhere and the URL is not Google. So I try putting in my GAPPS password, because I use 2 factor, and it doesn't work. Most likely because I use 2 factor, and I can't authenticate with just my standard GAPPS password. So it failed. I guess I'm an edge case as most people don't enable 2-factor on their Google account, but I was still really confused when it asked for my email password. EDIT: Same thing happened with Firefox version whatever the latest one is. I'd say it's completely confusing, all in all.
- sebastianmck 14y agoWas picking the name Persona such a good idea when it's so close to Personas, another Mozilla product?
- znq 14y agoWhat about native mobile apps? Is it possible to easily use Browser ID for native iOS and Android apps? Or is it just too much of a hassle getting the information out of the web view?
- znq 14y agoI just found this https://github.com/mozilla/browserid-ios https://github.com/mozilla/browserid-ios however haven't tried it out, yet.
- st3fan 14y agoLet me know if you need help with that code or if I can answer any questions in general about Persona integration on iOS. You can contact me through Github or through the project's issue tracker.
- Flimm 14y agoMozilla Persona (AKA BrowserID) is exciting stuff. However, it doesn't seem to have changed much since the last time it hit Hacker News [0]. There are websites that have chosen Persona as an authentication method. We now need to see the following two pieces implemented: - It needs to be implemented in the browser's GUI, like in this old screenshot [1]. People will be able to see the usability and security benefits of having a standardised way to log in that's built-in into the browser. Could we at least have a Firefox extension or a nightly build of Firefox that does this? - At least one email provider needs to be a Persona "ID provider", which would eliminate the need to create a Persona password and to click on a link in an email. My guess is that getting Gmail to support this would be slow work, why not try persuading smaller email providers like Fastmail to be the first to openly support Persona? Fortunately, Persona does work even without these two pieces, using fall-back servers and a shim. But most of the benefits of Persona are only valid once the browser and the email provider deliberately support it. [0] - https://news.ycombinator.com/item?id=2764824 https://news.ycombinator.com/item?id=2764824 [1] - http://i50.tinypic.com/2ptyv80.jpg http://i50.tinypic.com/2ptyv80.jpg
- Flimm 14y agoAs explained in another comment, the second item is already part way there through another workaround. Ctrl-F "bigtent".
- callahad 14y agoMuch has changed, but we haven't written about it yet. We're working on it. This post to HN caught me by surprise. The new design went live, but we weren't planning on announcing things until early next month. Trying to stabilize and polish the new APIs, etc. Native support should be coming in Firefox 17, albeit off-by-default. Native support will be enabled on phones running Boot2Gecko, which ship in Q1 next year.
- jackalope 14y agoAs an email provider for multiple domains, I have a hard time seeing what this actually has to do with current email infrastructure. It seems the only time the email address is used is to support a fallback notification, in which case many of the claimed benefits of BrowserID are lost (as you've fallen back to a single centralized identity provider). Correct me if I'm wrong, but BrowserID/Persona assumes that for a user@example.org identifier there is a corresponding https://example.org https://example.org. That's not true for most of the domains I support. In many cases, example.org doesn't even resolve to to an IP address and web servers are only run on subdomains (and not all subdomains have HTTP servers). Does BrowserID/Persona support a DNS mechanism to discover the location of the required HTTPS web server, similar to an MX record? The opposite problem is where a user has a single email account with multiple valid addresses at multiple domains, such as user@example.org, user@foo.example.org, user@bar.example.org, etc. I work for an organization approaching a million users where this is the case and isn't going to change anytime soon. Once again, you can't assume there is an identity provider running on a web server at all of these domains. Is there a DNS-based method of discovery to solve this problem? Does BrowserID/Persona allow users to authenticate against the same system they use when accessing email? If so, why does the OpenPhoto example ask for a password? I thought the whole point was that users avoid sharing credentials with sites. That implementation is very confusing and looks like a scary phishing attack. Finally, it's not very clear what I should expect in the way of connections from other computers, whether I'm running an identity provider or not. This is crucial information to avoid tripping an intrusion detection system (IDS) during unexpected connections, especially from my own users.
- Lockyy 14y agoI've been sitting around thinking about implementing a user system on my current (and first) website to try and keep people returning to the site to see people responding to their stories etc. Now I'm wondering whether to use Persona or build it myself from scratch.
- allenap 14y agoFirst reaction: the bland beige looks terrible (maybe that's because I'm not American; I always notice that 1/2 of everything is beige when I'm in the US). Combine that with the name and I'm reminded of the Persona contraceptive device.
- SCdF 14y agoOne thing that I don't get about BrowserID is how it's supposed to work on shared systems / web cafes. There doesn't seem to be any obvious way to log out. The best you can do is 'log me out after an hour', which is crap.