A new experimental API for Persona

[Lloyd Hilaiel]

For a while now we've wanted to introduce a new JavaScript API for Persona that would allow us to improve the first-run sign in flow, improve user safety while using public terminals or shared computers, and easier user facing logout.

Further context around why we're changing the API is available in a previous mail:http://groups.google.com/group/mozilla.dev.identity/browse_thread/thread/7cdbe4a82c15b5e8/d6a7978407c57356?lnk=gst&q=api#d6a7978407c57356

So as of now a proposal for this new API is complete, and is available in "experimental" status in our development branch. The plan is to land this experimental feature in beta on wednesday (4.11), and then bring it to production (still "experimental") two weeks subsequently.

Documentation for the new API is sketched here: https://gist.github.com/2287552

And a new sample app has been written against it (a work in progress) - http://123done.org

By releasing this as "experimental" the goal is to air out the API and give everyone an opportunity to evaluate it. And you shouldn't migrate to the API in production systems until it's final. To test out the new APIs, you'd have to use include.js from `https://dev.diresworb.org/include.js` and reach under `navigator.id.experimental`, perhaps with code that looks like this:

https://github.com/lloyd/123done/blob/bd667301f14ed1c7d092591758025e74a0756f26/static/123done.js#L1-5

Equally as important as testing the new experimental APIs, is ensuring that we're 100% backwards compatible and no existing sites will be broken.

Note, the design of this API is *heavily* motivated by feedback that was offered on this list by all of you - so thanks, and I we forward to more.

curiously,
lloyd

[Dan Mills]

Very nice!

One nit: maybe the "email" property should be "currentEmail" or "currentUser" or something like that? Otherwise it reads like you are watching for that email.

I'm not sure I get what onready is useful for. Do you have an example?

Dan

> _______________________________________________
> dev-identity mailing list
> dev-id...@lists.mozilla.org (mailto:dev-id...@lists.mozilla.org)
> https://lists.mozilla.org/listinfo/dev-identity
>
>

[Lloyd Hilaiel]

On Apr 9, 2012, at 11:44 AM, Dan Mills wrote:

> Very nice!
>
> One nit: maybe the "email" property should be "currentEmail" or "currentUser" or something like that? Otherwise it reads like you are watching for that email.

Good idea. How does loggedInEmail grab you?

> I'm not sure I get what onready is useful for. Do you have an example?

At the time onready fires the identity stuff has been loaded and it's safe to display login status to the user. 'onlogin' or 'onlogout' callbacks will have been invoked by this time if needed.

This is related to the "flicker free signin" discussion in this thread:
http://groups.google.com/group/mozilla.dev.identity/browse_thread/thread/e9bd66fdaad53fd8/09a657be5c011b7e

Make sense?

lloyd

> Dan
>
> On Monday, April 9, 2012 at 10:18 AM, Lloyd Hilaiel wrote:
>
>> For a while now we've wanted to introduce a new JavaScript API for Persona that would allow us to improve the first-run sign in flow, improve user safety while using public terminals or shared computers, and easier user facing logout.
>>
>> Further context around why we're changing the API is available in a previous mail:http://groups.google.com/group/mozilla.dev.identity/browse_thread/thread/7cdbe4a82c15b5e8/d6a7978407c57356?lnk=gst&q=api#d6a7978407c57356
>>
>> So as of now a proposal for this new API is complete, and is available in "experimental" status in our development branch. The plan is to land this experimental feature in beta on wednesday (4.11), and then bring it to production (still "experimental") two weeks subsequently.
>>
>> Documentation for the new API is sketched here: https://gist.github.com/2287552
>>
>> And a new sample app has been written against it (a work in progress) - http://123done.org
>>
>> By releasing this as "experimental" the goal is to air out the API and give everyone an opportunity to evaluate it. And you shouldn't migrate to the API in production systems until it's final. To test out the new APIs, you'd have to use include.js from `https://dev.diresworb.org/include.js` and reach under `navigator.id.experimental`, perhaps with code that looks like this:
>>
>> https://github.com/lloyd/123done/blob/bd667301f14ed1c7d092591758025e74a0756f26/static/123done.js#L1-5
>>
>> Equally as important as testing the new experimental APIs, is ensuring that we're 100% backwards compatible and no existing sites will be broken.
>>
>> Note, the design of this API is *heavily* motivated by feedback that was offered on this list by all of you - so thanks, and I we forward to more.
>>
>> curiously,
>> lloyd
>>
>> _______________________________________________
>> dev-identity mailing list
>> dev-id...@lists.mozilla.org

>> https://lists.mozilla.org/listinfo/dev-identity
>

[Dan Mills]

On Monday, April 9, 2012 at 11:04 AM, Lloyd Hilaiel wrote:
> > One nit: maybe the "email" property should be "currentEmail" or "currentUser" or something like that? Otherwise it reads like you are watching for that email.
> >
>
>
> Good idea. How does loggedInEmail grab you?

Better than "email" for sure. Maybe currentUserEmail ?

> At the time onready fires the identity stuff has been loaded and it's safe to display login status to the user. 'onlogin' or 'onlogout' callbacks will have been invoked by this time if needed.
>
> This is related to the "flicker free signin" discussion in this thread:
> http://groups.google.com/group/mozilla.dev.identity/browse_thread/thread/e9bd66fdaad53fd8/09a657be5c011b7e
>
> Make sense?

Hmm so, it's not safe before that? We might fire multiple callbacks?

Dan

[Lloyd Hilaiel]

On Apr 9, 2012, at 12:12 PM, Dan Mills wrote:
>
>> At the time onready fires the identity stuff has been loaded and it's safe to display login status to the user. 'onlogin' or 'onlogout' callbacks will have been invoked by this time if needed.
>>
>> This is related to the "flicker free signin" discussion in this thread:
>> http://groups.google.com/group/mozilla.dev.identity/browse_thread/thread/e9bd66fdaad53fd8/09a657be5c011b7e
>>
>> Make sense?
>
> Hmm so, it's not safe before that? We might fire multiple callbacks?

No, you should never get multiple callbacks. Here's are the possibilities:

1. your onlogout callback is invoked (i.e. user has a session with the website, but has told persona to "sign me out everywhere")
2. your onlogin callback is invoked (i.e. user just completed persona sign up and can be automatically signed in)
3. no callbacks will be invoked because 'loggedInUser' is still logged in with persona.

In all cases if you wait to render user specific content until onready, then you have no flicker.

Now you could, in case #1 and case #2 immediately render login state, and it would work fine. But then you'd still need to listen for onready to handle case #3.

I'll try to update the API docs to make this clearer... Suggestions?

lloyd

> Dan

[Dan Mills]

On Monday, April 9, 2012 at 11:25 AM, Lloyd Hilaiel wrote:
> No, you should never get multiple callbacks. Here's are the possibilities:
>
> 1. your onlogout callback is invoked (i.e. user has a session with the website, but has told persona to "sign me out everywhere")
> 2. your onlogin callback is invoked (i.e. user just completed persona sign up and can be automatically signed in)
> 3. no callbacks will be invoked because 'loggedInUser' is still logged in with persona.
>
> In all cases if you wait to render user specific content until onready, then you have no flicker.
>
> Now you could, in case #1 and case #2 immediately render login state, and it would work fine. But then you'd still need to listen for onready to handle case #3.
>
> I'll try to update the API docs to make this clearer... Suggestions?

This explains it to me 100%, thanks!

Not sure how to make it clear in the docs. Maybe:

onready (optional) - A callback that will always be called once the navigator.id service is initialized (after onlogin or onlogout have been called). This allows for UI to be rendered only once to avoid flickering, whether a new session is being created, an existing session is being terminated, or there is no change to the user's signed-in state.

Dan

[Mike G]

What exactly is new?

[Lloyd Hilaiel]

On Apr 9, 2012, at 4:12 PM, Mike G wrote:

> What exactly is new?

rather than calling navigator.id.get(), you call navigator.id.watch(), followed by navigator.id.request(). Give it a read: https://gist.github.com/2287552

lloyd

[Lloyd Hilaiel]

On Apr 9, 2012, at 4:32 PM, Mike G wrote:

> Oh ok, the other improvements did make it through? Eg. first time registering, etc.

Yes and No: In order to get those other improvements, we have to first agree on a new api, and get folks migrated over to it.

One place where we can shortcut that is in the first time registration flow - we can detect that the new API is in use, and upgrade the flow, before we have 100% adoption of the new api.

The new API is a prerequisite to the features. Make sense?
lloyd

[Mike G]

Cool, please publish a migration guide once the api is live.

Thanks,
Mike

[Francois Marier]

Hi Lloyd,

On 2012-04-09 at 11:18:17, Lloyd Hilaiel wrote:
> Documentation for the new API is sketched here: https://gist.github.com/2287552

Not sure if you want feedback on the API documentation at this stage, but
from the point of view of an RP, the two things I found (midly) confusing
were:

- The watch() function looks like it's optional (because all of the options
are marked as optional), but as far as I can tell from the documentation
and your example implementation, onlogin is the only way to get an
assertion.

- The onclose callback in request() should probably make it clear that its a
callback without an argument and that it won't return the assertion for
example. In other words, that's not the way to migrate from get() or
getVerifiedEmail().

Cheers,
Francois

--
Francois Marier identi.ca/fmarier
http://fmarier.org twitter.com/fmarier

[Johnny Stenback]

On 04/09/2012 10:18 AM, Lloyd Hilaiel wrote:
[...]

> Documentation for the new API is sketched here: https://gist.github.com/2287552

Looking at the watch() function and how it's defined it seems to me that
calling that method w/o an onlogin callback is not really ever going to
be what the caller wants, so that should probably be a required
"option". Likewise, for onlogout we really really really want callers of
this method to pass in an onlogout callback, to the extent that it might
even make sense for this method to throw an exception if one is not
provided. That way we force callers to at least make a concious decision
about whether or not to pass that in, and if they want to make it an
empty function then they can shoot themselves in the foot by doing that,
but at least we make them think about it a bit.

--
jst

[Daniel Mills]

Very good points indeed. I remember these points being discussed before, were there conscious decisions to make these optional?

Dan

[Mounir Lamouri]

On 04/09/2012 07:18 PM, Lloyd Hilaiel wrote:
> Documentation for the new API is sketched here: https://gist.github.com/2287552

Hi,

I think we could make use of the DOMRequest object here. For
information, most of the new APIs made from the WebAPI effort are using
a pattern like this for async calls:
DOMRequest method(argument);

You can find the DOMRequest interface here:
https://mxr.mozilla.org/mozilla-central/source/dom/base/nsIDOMDOMRequest.idl

For example, the request() method (that I would name login()) could
return a DOMRequest object and a 'success' event would fire if the login
succeeded or an 'error' event otherwise like:

var request = navigator.id.login(null, null, null);
request.onsuccess = function() { alert("successfully logged in!"); };
request.onerror = function() { alert("failed to login..."); };

The same idea could be used for navigator.id.logout().

In addition, IMO, navigator.id.watch() isn't very webby. We could
probably use the good old event listeners here instead.
That would create 3 events named 'login', 'logout' and 'ready' and three
event handlers name id.onlogin, id.onlogout and id.onready.
It's not clear to me what the |email| parameter is for in |watch|. If
the only idea is to filter events, we could allow web developers to do
that by themselves.

Which actually leads to another question: how an API consumer knows the
currently logged in user with that API? Is that hidden on purpose?
Otherwise, should we expose this in navigator.id.something or add an
attribute to the event object sent with login/logout events?

Cheers,
--
Mounir

[Peter Williams]

If I have sessions on 5 to sites, 2 of which their own verifier and 1 of which is experiencing slowness, what happens on logout? For fun day, ive used 1 name/cert for some 4, and another named cert (swt form of cert remember, not x509)

Must all confirm logout?

Can anyone refuse (possibly silently)

Does the pending transaction get aborted?

Is their a saml designers chain (such that failure of node n to participate for any reason prevents the remaining chain of rps to even participate?

perhaps logout merely disables assertion making for a particular certified name (armed by a ping against its primary, earlier).

[Lloyd Hilaiel]

Hey Francois! thanks for the early feedback, and sorry for my late response.

On Apr 11, 2012, at 12:03 AM, Francois Marier wrote:

> Hi Lloyd,
>

> On 2012-04-09 at 11:18:17, Lloyd Hilaiel wrote:
>> Documentation for the new API is sketched here: https://gist.github.com/2287552
>

> Not sure if you want feedback on the API documentation at this stage, but
> from the point of view of an RP, the two things I found (midly) confusing
> were:
>
> - The watch() function looks like it's optional (because all of the options
> are marked as optional), but as far as I can tell from the documentation
> and your example implementation, onlogin is the only way to get an
> assertion.

Two people have brought this up. It's a great point. I'll followup today.

> - The onclose callback in request() should probably make it clear that its a
> callback without an argument and that it won't return the assertion for
> example. In other words, that's not the way to migrate from get() or
> getVerifiedEmail().

I agree. I'll update the documentation today.

lloyd

> Cheers,
> Francois
>
> --
> Francois Marier identi.ca/fmarier
> http://fmarier.org twitter.com/fmarier

[Lloyd Hilaiel]

On Apr 13, 2012, at 9:28 PM, Daniel Mills wrote:

> On Apr 13, 2012, at 6:01 PM, Johnny Stenback <j...@mozilla.com> wrote:
>

> Very good points indeed. I remember these points being discussed before, were there conscious decisions to make these optional?

I too think this is a great point. I like making both required and will do this in today's pass.

lloyd

[Lloyd Hilaiel]

Hey Mounir! Thank you for the careful feedback!

On Apr 16, 2012, at 8:56 AM, Mounir Lamouri wrote:

> On 04/09/2012 07:18 PM, Lloyd Hilaiel wrote:

>> Documentation for the new API is sketched here: https://gist.github.com/2287552
>

> Hi,
>
> I think we could make use of the DOMRequest object here. For
> information, most of the new APIs made from the WebAPI effort are using
> a pattern like this for async calls:
> DOMRequest method(argument);
>
> You can find the DOMRequest interface here:
> https://mxr.mozilla.org/mozilla-central/source/dom/base/nsIDOMDOMRequest.idl
>
> For example, the request() method (that I would name login()) could
> return a DOMRequest object and a 'success' event would fire if the login
> succeeded or an 'error' event otherwise like:
>
> var request = navigator.id.login(null, null, null);
> request.onsuccess = function() { alert("successfully logged in!"); };
> request.onerror = function() { alert("failed to login..."); };

I read several of the proposed APIs built on top of DOMRequest, and really appreciate
the attempt to apply a concrete pattern to asynchronous requests in these emerging APIs
(oh yeah, and can't *wait* till we can play with this stuff in apps).

That said, I'm having trouble seeing that this is the most intuitive interface for persona.

One key reason I don't feel that it fits here is that "login" can happen multiple times
while the page is loaded - and it can happen as a result of the page requesting it
(page can request an id from the user), or can occur out of band (user signs up for persona and
simultaneously logs into the site, but not while the site is loaded).

This pattern seems to apply best to a asynchronous request. (like navigator.contacts.save(),
or WiFiManager.getNetworks() for instance).

> The same idea could be used for navigator.id.logout().
>
> In addition, IMO, navigator.id.watch() isn't very webby. We could
> probably use the good old event listeners here instead.
> That would create 3 events named 'login', 'logout' and 'ready' and three
> event handlers name id.onlogin, id.onlogout and id.onready.

Yeah! We actually started with an "eventy" API, however several things don't
really fit:
* there isn't really a 1-1 correspondence between an event occurring, and the client
getting notified. if we used events, the raised events wouldn't temporally correspond to the
event occurring - which is weird and I can't find any precedent for this.
* assertion generation (for the login event) can have a significant cost (computation and
network requests), and is only necessary *sometimes*, not at every page load. Every attempt
to plug this hole led to a clumsy API that was harder to explain. (we would probably end up
forcing pages to do something unnatural to tell us who the currently logged in user is -
requiring they do server side substitution and serve non-cachable resources).

Here's the (presently aborted) attempt at a more event based api: http://lloyd.io/a-new-api-for-browserid

> It's not clear to me what the |email| parameter is for in |watch|. If
> the only idea is to filter events, we could allow web developers to do
> that by themselves.

I will try to make this much clearer in the next pass of API docs (to be completed today),
and we've already decided to rename this parameter. Maybe you're a perfect guinea pig, if
the parameter was named 'loggedInUser' and you knew the site provided it, would the intent
be clearer?

The idea is because there's a non-trivial cost to generating a "login" event every time,
it's worth surfacing the "filtering" parameter in the API. Further, because even though
webdevs could filter at a later point, this would not allow them to avoid the cost at
page load time.

Generally, however, I strongly prefer leaving filtering up to the site, and for certain features
(like websites that require an email address from a certain domain to log in), I think this
is the right approach.

> Which actually leads to another question: how an API consumer knows the
> currently logged in user with that API? Is that hidden on purpose?
> Otherwise, should we expose this in navigator.id.something or add an
> attribute to the event object sent with login/logout events?

Historically we've hidden it because we have been scared that websites would just
*trust* an email address handed back by browserid. Previous discussions have focused
more on the fact that our callbacks never return bare emails and instead return
assertions that the client must verify on their server. Here's a long thread on the
topic:

https://groups.google.com/group/mozilla.dev.identity/browse_thread/thread/bc2e047281ccc80b/de3c6d729791fcc7?lnk=gst&q=email+from+assertion#de3c6d729791fcc7

In this case though, I'm most concerned that the api itself makes the following clear:

1. you must handle out of band login/logout events (which occur when your page is not loaded)
2. you should tell the api what email you think is logged in so you're not generating assertions
every page load.

Do these motivations make sense to you?

lloyd

> Cheers,
> --
> Mounir

[Lloyd Hilaiel]

Thanks for your thoughts, peter!

On Apr 16, 2012, at 9:25 AM, Peter Williams wrote:

> If I have sessions on 5 to sites, 2 of which their own verifier and 1 of which is experiencing slowness, what happens on logout? For fun day, ive used 1 name/cert for some 4, and another named cert (swt form of cert remember, not x509)
>
> Must all confirm logout?

This is tricky. No, given we're implementing this in web content we cannot guarantee that sites will honor logout events. But we will keep firing them on every subsequent visit as long as the user stays logged out and the site insists she's logged in.

> Can anyone refuse (possibly silently)

yes.

> Does the pending transaction get aborted?

IIUC, no. The user logs out, and browserid goes and aggressively tells sites every time they're loaded.

> Is their a saml designers chain (such that failure of node n to participate for any reason prevents the remaining chain of rps to even participate?

no.

> perhaps logout merely disables assertion making for a particular certified name (armed by a ping against its primary, earlier).

This is essentially it, iiuc. logout is very much advisory, but we want to make it extremely clear in the API, so that we can realize a meaningful "logout everywhere" feature, and so that our "public terminal" support works as advertised.

lloyd

> On Apr 16, 2012, at 7:57 AM, "Mounir Lamouri" <mou...@lamouri.fr> wrote:
>
>> On 04/09/2012 07:18 PM, Lloyd Hilaiel wrote:
>>> Documentation for the new API is sketched here: https://gist.github.com/2287552
>>
>> Hi,
>>
>> I think we could make use of the DOMRequest object here. For
>> information, most of the new APIs made from the WebAPI effort are using
>> a pattern like this for async calls:
>> DOMRequest method(argument);
>>
>> You can find the DOMRequest interface here:
>> https://mxr.mozilla.org/mozilla-central/source/dom/base/nsIDOMDOMRequest.idl
>>
>> For example, the request() method (that I would name login()) could
>> return a DOMRequest object and a 'success' event would fire if the login
>> succeeded or an 'error' event otherwise like:
>>
>> var request = navigator.id.login(null, null, null);
>> request.onsuccess = function() { alert("successfully logged in!"); };
>> request.onerror = function() { alert("failed to login..."); };
>>

>> The same idea could be used for navigator.id.logout().
>>
>> In addition, IMO, navigator.id.watch() isn't very webby. We could
>> probably use the good old event listeners here instead.
>> That would create 3 events named 'login', 'logout' and 'ready' and three
>> event handlers name id.onlogin, id.onlogout and id.onready.

>> It's not clear to me what the |email| parameter is for in |watch|. If
>> the only idea is to filter events, we could allow web developers to do
>> that by themselves.
>>

>> Which actually leads to another question: how an API consumer knows the
>> currently logged in user with that API? Is that hidden on purpose?
>> Otherwise, should we expose this in navigator.id.something or add an
>> attribute to the event object sent with login/logout events?
>>

[Lloyd Hilaiel]

Revised version of the API proposal: https://gist.github.com/2287552

Thanks for the careful review, I look forward to more.

lloyd

On Apr 16, 2012, at 9:25 AM, Peter Williams wrote:

> If I have sessions on 5 to sites, 2 of which their own verifier and 1 of which is experiencing slowness, what happens on logout? For fun day, ive used 1 name/cert for some 4, and another named cert (swt form of cert remember, not x509)
>
> Must all confirm logout?
>

> Can anyone refuse (possibly silently)
>

> Does the pending transaction get aborted?
>

> Is their a saml designers chain (such that failure of node n to participate for any reason prevents the remaining chain of rps to even participate?
>

> perhaps logout merely disables assertion making for a particular certified name (armed by a ping against its primary, earlier).
>

[Ben Adida]

On 4/16/12 4:05 PM, Lloyd Hilaiel wrote:
> Revised version of the API proposal: https://gist.github.com/2287552

The onclose callback to navigator.id.request(), two issues:

(a) the naming implies a popup UX, which may not be the case in the
future. How about naming it in a way that is more about what's logically
happening, e.g. oncomplete().

(b) is it meant to fire whether login is successful or not, or is it
effectively an oncancel() ? That could affect the naming in (a) obviously.

-Ben

[Lloyd Hilaiel]

On Apr 16, 2012, at 8:49 PM, Ben Adida wrote:

> On 4/16/12 4:05 PM, Lloyd Hilaiel wrote:
>> Revised version of the API proposal: https://gist.github.com/2287552
>
> The onclose callback to navigator.id.request(), two issues:
>
> (a) the naming implies a popup UX, which may not be the case in the future. How about naming it in a way that is more about what's logically happening, e.g. oncomplete().

hah. https://github.com/mozilla/browserid/commit/a5c6113cc8686dcd559731bdb5db9204e95e2326#commitcomment-1175541

So now the tradeoff would seem to be do we want it to be more obvious and intuitive today, or tomorrow?

but ...

> (b) is it meant to fire whether login is successful or not, or is it effectively an oncancel() ? That could affect the naming in (a) obviously.

The only utility of this callback that I can think of is for the cancel case. That is why it exists.

Maybe we should change the name to `oncancel` and the semantic.

lloyd


> -Ben

[Ben Adida]

On 4/16/12 7:57 PM, Lloyd Hilaiel wrote:
> The only utility of this callback that I can think of is for the cancel case. That is why it exists.
>
> Maybe we should change the name to `oncancel` and the semantic.

+1.

-Ben

[Lloyd Hilaiel]

voilà: https://gist.github.com/2287552/

Three reasons I think this is good:
1. francois complained that onclose might be expected to return an assertion, this solves that.
2. The documentation is clearer.
3. cancel is implementation agnostic

yay!
lloyd

> -Ben

[Mounir Lamouri]

On 04/16/2012 11:08 PM, Lloyd Hilaiel wrote:
>> var request = navigator.id.login(null, null, null);
>> request.onsuccess = function() { alert("successfully logged in!"); };
>> request.onerror = function() { alert("failed to login..."); };
>

> I read several of the proposed APIs built on top of DOMRequest, and really appreciate
> the attempt to apply a concrete pattern to asynchronous requests in these emerging APIs
> (oh yeah, and can't *wait* till we can play with this stuff in apps).
>
> That said, I'm having trouble seeing that this is the most intuitive interface for persona.
>
> One key reason I don't feel that it fits here is that "login" can happen multiple times
> while the page is loaded - and it can happen as a result of the page requesting it
> (page can request an id from the user), or can occur out of band (user signs up for persona and
> simultaneously logs into the site, but not while the site is loaded).

You can login only once when .login() (or .request()) is called, right?
The DOMRequest object doesn't make the login event on navigator.id
obsoleted. Actually, a login event should still be sent to navigator.id
if .login() succeeded.

> This pattern seems to apply best to a asynchronous request. (like navigator.contacts.save(),
> or WiFiManager.getNetworks() for instance).

AFAICT, .login() is async, isn't it? otherwise, there would be no
callback...

>> The same idea could be used for navigator.id.logout().
>>
>> In addition, IMO, navigator.id.watch() isn't very webby. We could
>> probably use the good old event listeners here instead.
>> That would create 3 events named 'login', 'logout' and 'ready' and three
>> event handlers name id.onlogin, id.onlogout and id.onready.
>

> Yeah! We actually started with an "eventy" API, however several things don't
> really fit:
> * there isn't really a 1-1 correspondence between an event occurring, and the client
> getting notified. if we used events, the raised events wouldn't temporally correspond to the
> event occurring - which is weird and I can't find any precedent for this.

I do not understand what you mean...

> * assertion generation (for the login event) can have a significant cost (computation and
> network requests), and is only necessary *sometimes*, not at every page load. Every attempt
> to plug this hole led to a clumsy API that was harder to explain. (we would probably end up
> forcing pages to do something unnatural to tell us who the currently logged in user is -
> requiring they do server side substitution and serve non-cachable resources).

If a page doesn't care about the login event, the page could simply not
listen to it, right? I mean, if I'm currently logged in, the page could
simply listen to the "logout" event.
And I don't see how the current API handles that better.

> The idea is because there's a non-trivial cost to generating a "login" event every time,
> it's worth surfacing the "filtering" parameter in the API. Further, because even though
> webdevs could filter at a later point, this would not allow them to avoid the cost at
> page load time.

I'm not sure this is better than assuming pages will not listen to an
event when not needed.

> Do these motivations make sense to you?

Yes but I still think the API is odd. What about something like:

interface PersonaId_OrWhateverNameYouWant {
// Tells there is someone currently logged in.
// Should help building an UI on page load.
readonly attribute boolean logged;

DOMRequest login();
DOMRequest logout();

// Those functions are handlers for 'login', 'logout' and 'ready'
// events.
Function onlogin;
Function onlogout;
// I'm not sure how useful that is but that can be isolated to
// another discussion.
Function onready;
};

This is based on what I understood. So I might have missed some use cases.

Cheers,
--
Mounir

[Dan Mills]

On Tuesday, April 17, 2012 at 4:30 AM, Mounir Lamouri wrote:
> You can login only once when .login() (or .request()) is called, right?

No, the user agent may proactively send an assertion if it wishes to (for example, if the user previously configured the agent to do so).

Dan

[Mounir Lamouri]

I do not understand what you are trying to say.
What I tried to say is that, when .login() is called, it should actually
log the user in or fail but it can't log the user in twice, right? If
the user use something else to log in, it will be different an the event
will be caught by navigator.id.onlogin event handler.

--
Mounir

[Dan Callahan]

On 4/9/12 12:18 PM, Lloyd Hilaiel wrote:
> For a while now we've wanted to introduce a new JavaScript API for Persona that would allow us to improve the first-run sign in flow, improve user safety while using public terminals or shared computers, and easier user facing logout.

The new API looks great, but the current docs state that "Each page of
your site should [...] be prepared to handle asynchronous changes to
login state," which sounds scary and is possibly difficult to get right.

One of the big wins, if I'm understanding the context properly, is that
we'll be able to send login and logout events from other contexts,
paving the way for a "logout everywhere" button, or sign-in in the browser.

That sounds great! However, I'm a bit worried about the implications of
a logout event firing whenever it damn well pleases. Right now, I can
prevent access to the logout button when the user is, say, editing a
wiki page. They either need to save or discard that draft before logging
out. With the new API, I need handle that event as soon as it comes in,
and presumably non-interactively. (right?)

If we decide to roll with this, I'd like to see a little more guidance
around how to handle the login and logout events. After all, an
interactive logout flow would trivially defeat the "logout everywhere"
button, right?

-Callahad

[Dan Mills]

I would strongly encourage apps to save user state and restore it upon the next sign-in, rather than force user interaction.

If that is not feasible, apps do have an alternative with this new API: ignore the logout event and alert() or similar telling the user that they need to finish their modal task before being able to log out.

Dan

> _______________________________________________
> dev-identity mailing list
> dev-id...@lists.mozilla.org (mailto:dev-id...@lists.mozilla.org)
> https://lists.mozilla.org/listinfo/dev-identity
>
>

[Ben Adida]

On 4/18/12 2:06 PM, Dan Callahan wrote:
> That sounds great! However, I'm a bit worried about the implications of
> a logout event firing whenever it damn well pleases. Right now, I can
> prevent access to the logout button when the user is, say, editing a
> wiki page. They either need to save or discard that draft before logging
> out. With the new API, I need handle that event as soon as it comes in,
> and presumably non-interactively. (right?)

So, the site still gets to decide what to do upon logout event. The
scenario you describe is unlikely: you're writing something in one
window, then you go log out in a different window, then you come back.
But even if that happens, the site can still say "are you sure you want
to log out?" if you're in the middle of editing something.

> If we decide to roll with this, I'd like to see a little more guidance
> around how to handle the login and logout events. After all, an
> interactive logout flow would trivially defeat the "logout everywhere"
> button, right?

In any case, our logout event is just a hint to the site. It could
choose not to follow it. And that's probably the right level of control
given the example you give above.

-Ben