Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
BrowserID trains rolling with two big features!
16 views
Skip to first unread message
Lloyd Hilaiel
Nov 18, 2011, 10:51:48 AM11/18/11
to dev-id...@lists.mozilla.org
G'Day identity watchers,
BrowserID train 2011.11.10 brings several improvements [1] went through QA without any major regressions found [2]. As previously noted, due to a partially implemented feature [3], this train will not go into production today.
Now let's talk about train 2011.11.17 (full changes available as always [4]):
* iOS5 is fixed
* A new feature has been added to let users "stay signed in" to website
* Another new feature has been added to let websites request a user login with a specific email
* As a result of the above, the BrowserID API has grown up, in a backwards compatible manner
Big Feature #1: How does "stay signed in" work and why should you care?
Currently, many websites use cookies to keep a user signed in. Duration ranges wildly from a couple hours to forever. This tradition has a couple issues:
* Users have to clear cookies to centrally logout from all of the sites they visit - which not many users understand.
* Long lived session cookies can lead to CSRF attacks. [5]
The "stay signed in" feature allows a website to opt into a new BrowserID behavior that provides a "keep me signed in" link inside the browserid dialog. When this is clicked, a preference is set that will allow sites to fetch an identity assertion in the future *without prompting the user*. So the general idea is that you can opt into this feature, and rather than setting long lived cookies, you set short duration cookies (session or shorter). When a user visits your site, you call a browserid function that tests to see if the user is "still signed in". If so, you get back an assertion, and log the user in. Users are unaware that anything is changed, only they are a bit safer. As browsers vendors build in native support for browserid, there is a very clean way to implement "log me out everywhere" in a much more user friendly manner than suggesting that they clear their cookies.
The test site http://beta.myfavoritebooze.org demonstrates how these features can be applied, have a look and offer your feedback!
And Big Feature #2: What is "requiredEmail" and why is it useful?
There are many use cases where not any identity will do. Consider:
* A user has provided an email address to a site already, and the site wishes to verify that the user owns *that specific email address*.
* A user has shared photos (or whatever) with a list of users named by email address, when those sharees arrive at the site, the site wishes to confirm their identity before showing them the photos (or whatever)
* A user purchases a web application, and the app wishes to verify that the user at the keyboard is the very same as the purchaser.
We've mocked up what the first case might look like to test this feature, and you can have a look right now on http://beta.myfavoriteshow.org
Have a look at a sketch of the new BrowserID API documentation to see how this all is exposed [6].
Wow. Monster email!
We look forward to your thoughts,
The BrowserID Team (via lloyd)
[1] https://github.com/mozilla/browserid/blob/06efa1/ChangeLog#L1-22
[2] https://bugzilla.mozilla.org/701934
[3] https://github.com/mozilla/browserid/issues/559
[4] https://github.com/mozilla/browserid/blob/77c743/ChangeLog#L1-16
[5] http://en.wikipedia.org/wiki/Csrf
[6] https://gist.github.com/1336528
BrowserID train 2011.11.10 brings several improvements [1] went through QA without any major regressions found [2]. As previously noted, due to a partially implemented feature [3], this train will not go into production today.
Now let's talk about train 2011.11.17 (full changes available as always [4]):
* iOS5 is fixed
* A new feature has been added to let users "stay signed in" to website
* Another new feature has been added to let websites request a user login with a specific email
* As a result of the above, the BrowserID API has grown up, in a backwards compatible manner
Big Feature #1: How does "stay signed in" work and why should you care?
Currently, many websites use cookies to keep a user signed in. Duration ranges wildly from a couple hours to forever. This tradition has a couple issues:
* Users have to clear cookies to centrally logout from all of the sites they visit - which not many users understand.
* Long lived session cookies can lead to CSRF attacks. [5]
The "stay signed in" feature allows a website to opt into a new BrowserID behavior that provides a "keep me signed in" link inside the browserid dialog. When this is clicked, a preference is set that will allow sites to fetch an identity assertion in the future *without prompting the user*. So the general idea is that you can opt into this feature, and rather than setting long lived cookies, you set short duration cookies (session or shorter). When a user visits your site, you call a browserid function that tests to see if the user is "still signed in". If so, you get back an assertion, and log the user in. Users are unaware that anything is changed, only they are a bit safer. As browsers vendors build in native support for browserid, there is a very clean way to implement "log me out everywhere" in a much more user friendly manner than suggesting that they clear their cookies.
The test site http://beta.myfavoritebooze.org demonstrates how these features can be applied, have a look and offer your feedback!
And Big Feature #2: What is "requiredEmail" and why is it useful?
There are many use cases where not any identity will do. Consider:
* A user has provided an email address to a site already, and the site wishes to verify that the user owns *that specific email address*.
* A user has shared photos (or whatever) with a list of users named by email address, when those sharees arrive at the site, the site wishes to confirm their identity before showing them the photos (or whatever)
* A user purchases a web application, and the app wishes to verify that the user at the keyboard is the very same as the purchaser.
We've mocked up what the first case might look like to test this feature, and you can have a look right now on http://beta.myfavoriteshow.org
Have a look at a sketch of the new BrowserID API documentation to see how this all is exposed [6].
Wow. Monster email!
We look forward to your thoughts,
The BrowserID Team (via lloyd)
[1] https://github.com/mozilla/browserid/blob/06efa1/ChangeLog#L1-22
[2] https://bugzilla.mozilla.org/701934
[3] https://github.com/mozilla/browserid/issues/559
[4] https://github.com/mozilla/browserid/blob/77c743/ChangeLog#L1-16
[5] http://en.wikipedia.org/wiki/Csrf
[6] https://gist.github.com/1336528
Eric Shtivelberg
Nov 18, 2011, 3:59:50 PM11/18/11
to Lloyd Hilaiel, dev-id...@lists.mozilla.org
I can't register to the browser ID(once I get the confirmation email and
click the link it tells me there was an error with the link).
And is there any reason of why are you using "diresworb.org"?
This has confused me because they both look exactly the same.
Regards,
Eric
click the link it tells me there was an error with the link).
And is there any reason of why are you using "diresworb.org"?
This has confused me because they both look exactly the same.
Regards,
Eric
Lloyd Hilaiel
Nov 18, 2011, 4:07:00 PM11/18/11
to Eric Shtivelberg, dev-id...@lists.mozilla.org
Hey eric!
Yikes, there was a misconfiguration in our beta environment. it's been fixed, please try again now?
diresworb is browserid backwards. This is our beta environment. Every week we push code to this environment for open testing. Anyone is welcome to test code there, and if any issues are found during testing, we react according to the severity of the issue. These features I covered are not yet in production.
very best,
lloyd
Yikes, there was a misconfiguration in our beta environment. it's been fixed, please try again now?
diresworb is browserid backwards. This is our beta environment. Every week we push code to this environment for open testing. Anyone is welcome to test code there, and if any issues are found during testing, we react according to the severity of the issue. These features I covered are not yet in production.
very best,
lloyd
0 new messages