Changing your order as it makes it easier to answer...

> - you want to collect an email address or other information about users before allowing them to use the service

That's correct. Actually our process begins with a signup form where the email and phone number is provided. It's actually our sales that complete this form but it could probably be done on the web. But an E-Mail is pre-requisite - that was I was alluding to with the whole "What would Steve do?" section.

> - you want users to be able to use the service from multiple devices

This we handle. We've already created a customer record (based on the E-Mail) and we allow the activation message to be re-used by multiple devices so it's just a many to one relationship.

> - (relatedly) you want users to be able to get a new phone without loosing their account

This we're in the process of solving via the iCloud - not there yet though so we have to support customers manually and Android and others still to be figured out.

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.

Actually I think he did the right thing. He:

a). Isn't doing security for security's sake, and

b). He's giving his users a great experience.

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.

My post wasn't very clear. I'm sorry.

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.

We have looked at BrowserID and may use it to bring the same to the web. We'd already started before BrowserID was announced...

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.

Quoth the article: We send you a link by SMS or E-Mail containing a link comprised of an activation code. Tapping on the link results in our app being launched in "activation mode". The app then "phones home" passing back the activation code and some unique identifier for the device. That's it.