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