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.
"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.