can't see it taking off only because it solves a problem that 99% of internet users do not know exists. I have never had a regular, average, non-tech internet user say to me 'you know what is a real pain in the ass - signing up for web applications'. Most of those users only ever signup for a handful of applications, and are using oauth for everything else (twitpic etc.)
Introducing BrowserID: A better way to sign in
171–180 of 188 posts
Re: Introducing BrowserID: A better way to sign in
#172Earlier quoted context omitted.
You can have fully decentralized identities quite trivially: just create a public/private key. No consensus algorithms required. With browsers now supporting synchronization features to connect the browsers on all systems used by a single user, such a system could actually work quite well now, without the usability issues it would once have had.
This is a variety of SPKI[1], right? I was thinking of a conventional PKI approach, with an adapted web of trust to verify identities [2]. You are right - theoretically this could work. But it would pretty much take a "boil the ocean" approach to make it work. Browsers would need to implement a secure (private) keystore, and presumably some way to sync that to other browsers. A whole new standardized authentication f…
"boil the ocean"
This particular ocean should be fairly easy to boil with a browser extension for all popular browsers.
Re: Introducing BrowserID: A better way to sign in
#173They seriously need to work on their communication skills. It took me a good 15min to figure out what this thing actually does. And I'm still not sure I got it right. OpenID failed because it was too complicated for mere mortals. This, I fear, may be too confusing. At least form the way it's presented. After reading the protocol spec, I have a somewhat better understanding of this. If I got this right, this is basica…
How did OpenID fail (it's widely used)? How is it complicated for the user? Properly implemented, OpenID looks like this to the user: http://springpadit.com/login And something like this for the average developer: https://github.com/omab/django-social-auth
I don't think it's widely used. The average site that doesn't want to provide their own username is using Facebook nowadays. Stack Overflow etc. seems to be the only bigger site that uses it, and it's kind of a mess over there.
Re: Introducing BrowserID: A better way to sign in
#174Earlier quoted context omitted.
How did OpenID fail (it's widely used)? How is it complicated for the user? Properly implemented, OpenID looks like this to the user: http://springpadit.com/login And something like this for the average developer: https://github.com/omab/django-social-auth
That site fails terribly at supporting OpenID: it only supports four authentication providers, and doesn't allow a user to enter an arbitrary OpenID URL. "Properly implemented", OpenID looks like http://ikiwiki.info/ikiwiki.cgi?page=index&do=edit : a choice of common OpenID providers to help users who don't understand OpenID, an option to use an arbitrary OpenID, and an option to use a username and password. Properly…
Why do you think a "properly implemented" OpenID site should allow the user to use any authentication provider? The relying party site is trusting the OpenID provider to authenticate its users. Wouldn't sites with real security requirements want to vet providers before trusting them?
Re: Introducing BrowserID: A better way to sign in
#175They seriously need to work on their communication skills. It took me a good 15min to figure out what this thing actually does. And I'm still not sure I got it right. OpenID failed because it was too complicated for mere mortals. This, I fear, may be too confusing. At least form the way it's presented. After reading the protocol spec, I have a somewhat better understanding of this. If I got this right, this is basica…
How did OpenID fail (it's widely used)? How is it complicated for the user? Properly implemented, OpenID looks like this to the user: http://springpadit.com/login And something like this for the average developer: https://github.com/omab/django-social-auth
I don't see the OpenID here. I see them restricting me to only 4 third-party sites. Since there doing that, using OpenID or using each third party's system makes no difference. OpenID's supposed to be decentralized, but how do I log in with http://stevearm.com?
Re: Introducing BrowserID: A better way to sign in
#176Am I the only one who kind of wishes we never went down this "let's fix authentication!" rabbit hole? It feels like we've just replaced one problem with another. Now, instead of simply having to remember what username/password combination I used, I have to remember which (if any) OpenID provider I used, how much information about myself does said provider expose, and how to merge my accounts when I inevitably end up…
I like this approach specifically because it doesn't have to replace the traditional sign-in process. A BrowserID sign-in button can be added to a traditional sign-in form without any fuss, and users can either use it or ignore it. And if the BrowserID sign-in is broken, then no worries, the traditional sign-in form works anyway.
Re: Introducing BrowserID: A better way to sign in
#177Earlier quoted context omitted.
That site fails terribly at supporting OpenID: it only supports four authentication providers, and doesn't allow a user to enter an arbitrary OpenID URL. "Properly implemented", OpenID looks like http://ikiwiki.info/ikiwiki.cgi?page=index&do=edit : a choice of common OpenID providers to help users who don't understand OpenID, an option to use an arbitrary OpenID, and an option to use a username and password. Properly…
Why do you think a "properly implemented" OpenID site should allow the user to use any authentication provider? The relying party site is trusting the OpenID provider to authenticate its users. Wouldn't sites with real security requirements want to vet providers before trusting them?
Exactly right.
And all OpenID providers have different attribute exchange protocol extensions. If you use them, you can effectively allow only those you have tested.
Re: Introducing BrowserID: A better way to sign in
#178By what mechanism does BrowserID require RPs to respect the valid-until field?
Re: Introducing BrowserID: A better way to sign in
#179Earlier quoted context omitted.
You can have fully decentralized identities quite trivially: just create a public/private key. No consensus algorithms required. With browsers now supporting synchronization features to connect the browsers on all systems used by a single user, such a system could actually work quite well now, without the usability issues it would once have had.
This is a variety of SPKI[1], right? I was thinking of a conventional PKI approach, with an adapted web of trust to verify identities [2]. You are right - theoretically this could work. But it would pretty much take a "boil the ocean" approach to make it work. Browsers would need to implement a secure (private) keystore, and presumably some way to sync that to other browsers. A whole new standardized authentication f…
Huh? Browsers support client SSL certs today, but for some reason nobody uses them except intranets.
Re: Introducing BrowserID: A better way to sign in
#180Earlier quoted context omitted.
How did OpenID fail (it's widely used)? How is it complicated for the user? Properly implemented, OpenID looks like this to the user: http://springpadit.com/login And something like this for the average developer: https://github.com/omab/django-social-auth
That site fails terribly at supporting OpenID: it only supports four authentication providers, and doesn't allow a user to enter an arbitrary OpenID URL. "Properly implemented", OpenID looks like http://ikiwiki.info/ikiwiki.cgi?page=index&do=edit : a choice of common OpenID providers to help users who don't understand OpenID, an option to use an arbitrary OpenID, and an option to use a username and password. Properly…
There are legitimate reasons to whitelist OpenID providers, especially if you are dealing with $$ or want to minimize support costs.