3 ms·

There are a few reasons logins are still needed for most apps: - you want users to be able to use the service from multiple devices - (relatedly) you want use

There are a few reasons logins are still needed for most apps: - you want users to be able to use the service from multiple devices - (relatedly) you want users to be able to get a new phone without loosing their account - you want to collect an email address or other information about users before allowing them to use the service edited for formatting

seiji 14y ago
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.
harryf 14y ago
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.
- drivebyacct2 14y ago
  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.
  - harryf 14y ago
    We have looked at BrowserID and may use it to bring the same to the web. We'd already started before BrowserID was announced...
    - drivebyacct2 14y ago
      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.
  - Spearchucker 14y ago
    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.
    - drivebyacct2 14y ago
      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.

seiji 14y ago

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.

harryf 14y ago

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.

drivebyacct2 14y ago
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.
- harryf 14y ago
  We have looked at BrowserID and may use it to bring the same to the web. We'd already started before BrowserID was announced...
  - drivebyacct2 14y ago
    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.
- Spearchucker 14y ago
  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.
  - drivebyacct2 14y ago
    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.