Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
A Plan: Landing new features and API changes in production
25 views
Skip to first unread message
Lloyd Hilaiel
Mar 27, 2012, 3:31:43 PM3/27/12
to dev-id...@lists.mozilla.org
# The Overview
For the last months we've been working on some hard and high value problems in Persona Sign-In / BrowserID. They are:
1. Signing into a site for the first time is too hard - especially after you click on the verification link in your email.
2. Making it safer for users to log into websites that use BrowserID on public terminals or shared computers.
If you look really closely at these two features, they are similar:
The solution to the first one that we've user tested and looks really promising (redirect the user directly back to the site from the email link and have them be automatically logged in), requires that BrowserID or the UA tells the site that the user has logged in while the site was not loaded.
Most solutions to the second, requires that BrowserID/the UA tells the site that the user should be logged out based on events that have occured while the site was not loaded (i.e. time expired, the user indicated they wish to be logged out everywhere, or they've stood up from the terminal).
Now to be clear, there are many ways to solve these nuanced problems. We're deeply committed to leading with UX and user research from here on out, and making small incremental steps that have a high probability of working well with real humans, rather than giant leaps based on the intuition of technical domain experts (at least for authentication via the BrowserID protocol).
So we can dig into these two UX challenges separately and I'll gladly summarize all the thinking and proposed approaches that exist on them - but this email is about the prerequisites to being able to solve these problems, and that is we need an API that allows the browser and the site negotiate login state - and this gives us a foothold to provide better convenience (sign the user in automatically) and better safety (sign the user out when we can reliably determine that that's what they want).
So how do we get there?
# The Plan
Right now on a branch we have implemented API changes to support these two features that are fully backwards compatible. Once landed, they unblock (further) user testing and implementation of actual user facing features to address these issues. Here's a proposed timeline of how we get from here to there:
1. on 2012.03.28 we merge the `issue912` branch down into dev.
2. once in dev we aggressively all known RPs against the new changes to ensure backwards compatibility, and test the snot out of the apis.
3. we air out on this list the new API and features for two weeks
4. on 2012.04.11 we branch a train including new the APIs under navigator.id. with the final proposed API, and full backwards compatibility
5. on 2012.04.25 the new API lands in production
6. based on the response we make a decision about deprecation of the old APIs.
I'll followup with a more development focused email about the state of implementation of this new API, I suspect it won't be interesting to as wide a group and don't want to muddle the high level motivations and proposed timing.
How does this sound?
very best,
lloyd
For the last months we've been working on some hard and high value problems in Persona Sign-In / BrowserID. They are:
1. Signing into a site for the first time is too hard - especially after you click on the verification link in your email.
2. Making it safer for users to log into websites that use BrowserID on public terminals or shared computers.
If you look really closely at these two features, they are similar:
The solution to the first one that we've user tested and looks really promising (redirect the user directly back to the site from the email link and have them be automatically logged in), requires that BrowserID or the UA tells the site that the user has logged in while the site was not loaded.
Most solutions to the second, requires that BrowserID/the UA tells the site that the user should be logged out based on events that have occured while the site was not loaded (i.e. time expired, the user indicated they wish to be logged out everywhere, or they've stood up from the terminal).
Now to be clear, there are many ways to solve these nuanced problems. We're deeply committed to leading with UX and user research from here on out, and making small incremental steps that have a high probability of working well with real humans, rather than giant leaps based on the intuition of technical domain experts (at least for authentication via the BrowserID protocol).
So we can dig into these two UX challenges separately and I'll gladly summarize all the thinking and proposed approaches that exist on them - but this email is about the prerequisites to being able to solve these problems, and that is we need an API that allows the browser and the site negotiate login state - and this gives us a foothold to provide better convenience (sign the user in automatically) and better safety (sign the user out when we can reliably determine that that's what they want).
So how do we get there?
# The Plan
Right now on a branch we have implemented API changes to support these two features that are fully backwards compatible. Once landed, they unblock (further) user testing and implementation of actual user facing features to address these issues. Here's a proposed timeline of how we get from here to there:
1. on 2012.03.28 we merge the `issue912` branch down into dev.
2. once in dev we aggressively all known RPs against the new changes to ensure backwards compatibility, and test the snot out of the apis.
3. we air out on this list the new API and features for two weeks
4. on 2012.04.11 we branch a train including new the APIs under navigator.id. with the final proposed API, and full backwards compatibility
5. on 2012.04.25 the new API lands in production
6. based on the response we make a decision about deprecation of the old APIs.
I'll followup with a more development focused email about the state of implementation of this new API, I suspect it won't be interesting to as wide a group and don't want to muddle the high level motivations and proposed timing.
How does this sound?
very best,
lloyd
Francois Marier
Mar 27, 2012, 6:40:06 PM3/27/12
to dev-id...@lists.mozilla.org
On 2012-03-27 at 13:31:43, Lloyd Hilaiel wrote:
> 1. on 2012.03.28 we merge the `issue912` branch down into dev.
> 2. once in dev we aggressively all known RPs against the new changes to ensure backwards compatibility, and test the snot out of the apis.
Just to make sure I understand exactly what you're proposing, I'm guessing
> 1. on 2012.03.28 we merge the `issue912` branch down into dev.
> 2. once in dev we aggressively all known RPs against the new changes to ensure backwards compatibility, and test the snot out of the apis.
the missing word here is "we aggressively _test_ all known RPs"?
And by testing you mean not switching the RPs over to the new API but rather
testing that the old API they currently use continues to work in the new dev
branch? (In other words, this change on the BID end should be a noop for all
existing RPs.)
Cheers,
Francois
--
Francois Marier identi.ca/fmarier
http://fmarier.org twitter.com/fmarier
Lloyd Hilaiel
Mar 27, 2012, 10:06:16 PM3/27/12
to Francois Marier, dev-id...@lists.mozilla.org
On Mar 27, 2012, at 4:40 PM, Francois Marier <fran...@fmarier.org> wrote:
> On 2012-03-27 at 13:31:43, Lloyd Hilaiel wrote:
>> 1. on 2012.03.28 we merge the `issue912` branch down into dev.
>> 2. once in dev we aggressively all known RPs against the new changes to ensure backwards compatibility, and test the snot out of the apis.
>
> Just to make sure I understand exactly what you're proposing, I'm guessing
> the missing word here is "we aggressively _test_ all known RPs"?
>
> And by testing you mean not switching the RPs over to the new API but rather
> testing that the old API they currently use continues to work in the new dev
> branch? (In other words, this change on the BID end should be a noop for all
> existing RPs.)
Testing back compat will require creativity and outreach...
Lloyd
> Cheers,
> Francois
>
> --
> Francois Marier identi.ca/fmarier
> http://fmarier.org twitter.com/fmarier
> dev-identity mailing list
> dev-id...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-identity
0 new messages