So you halfway implemented BrowserID. In it's current incarnation (well, originally, now it's more traditional with a password), you can create an account with an email address and login via the link sent to you in email.
Unfortunately, you're also missing out on the federated and vastly potentially more secure nature of BrowserID in the rush to say that you've "done away with logins" which at the heart of it, isn't true.
BrowserID is new tech. Even if that adds any value it's not been field tested. I'm not sure whether he considered it or not, but I can tell you I wouldn't. At least not until someone's thrown some sizeable stones at it, and that doesn't make it fall over.
All of that said and done, I think there are better options out there - specifically something that supports services (active requestor profile) and not just the browser (passive). Something like Windows Azure Active Directory, for example, which has a proven pedigree, connects with anything, and above all follows the laws of identity.
I literally spit coffee out on my desk that you recommended Windows Azure Active Directory for this type of scenario.
"He's giving his users a great experience". It's almost like you're trying to be ironic.
Your comment seems borderline FUD on BrowserID, especially to smush it between "Easy to use" and "Azure AD". BrowserID is built on an older protocol and is pretty straight forward PKI. It's not hard to implement right now. At all. In fact it's a snippet of JavaScript and you're done, outside of server side validation if you want session management.
edit: For the downvoters, please note that Azure AD is less than 24 hours old. Besides the fact that it integrates into existing AD systems and really has no place at all in solving the problem being discussed in this thread. Whatsoever.
His problem has been solved. The way he solved it is the great user experience I mentioned.
Bringing BrowserID into that already solved scenario is no different to bringing anything else into it - be that OpenID, ADFS, OAuth, hand-rolled...
The fact that BrowserID takes a few lines of JavaScript to implement does not prove it's security. You're talking about consuming an identity system - I'm talking about trusting one.
>His problem has been solved. The way he solved it is the great user experience I mentioned.
Right, that exact same user experience flow is replicable with BrowserID except that it has all of the other features and optional security mechanisms I mentioned...
I wasn't saying his system + BrowserID, I was saying he could move to BrowserID and keep the same flow with all the benefits.
>The fact that BrowserID takes a few lines of JavaScript to implement does not prove it's security
No, the existing underlying protocol and very straight-forward and completely standard PKI does though. The irony is that BrowserID at the most basic invocation already has all of the security embodied by the solution outlined here... except it has another layer of backing and can also feature additional-factor authentication. It's basically only possible to get more secure via the use of BrowserID.
No offense, but this conversation would be more interesting if you knew the difference between what they're currently doing, how BrowserID works and what things like Azure AD offer.
None taken, I understand the difference quite well.
Any identity system should ideally be designed so the disclosure of identifying information is limited to parties having a necessary and justifiable place in a given identity relationship.
Neither BrowserID nor WAAD are justifiable parties.
My question relates to BrowserID regardless of the value to local.ch.
So, similarly, no offence, but saying "PKI" and "protocol" does not provide assurance. Does the BrowserID PKI implementation provide non-repudiation? Is it used to detect spoofing, tampering, to make a big secret a little secret? Does it in fact implement the protocol as specified?
I'm not saying it doesn't. I'm suggesting that until it's proven itself, BrowserID doesn't get my trust.
Cool! I'm looking at building a server to be an identity provider and wiring it up to a really simple smtp server, imap client (for pulling from gmail) and imap server to make a really stupid simple email client that provides identity services with a variety of options for security. Multifactor auth with a variety of choices in factors : SMS, phone call, OTP, time based codes, PKI, etc.
I think the federated nature and options in security along with the eventual UserAgent integration has the potential to give users and integrators a really fast, easy UX. More than OpenID ever did, certainly.
Unfortunately, you're also missing out on the federated and vastly potentially more secure nature of BrowserID in the rush to say that you've "done away with logins" which at the heart of it, isn't true.