a proposal to move the Relying Party API to event-based.

[Ben Adida]

Hi everyone,

I want to propose that we move the main BrowserID API to an event model
rather than callbacks. The existing callback mechanism would still work,
at least for a while.

The issue is logged here:
https://github.com/mozilla/browserid/issues/912

The main idea is that separating the navigator.id.get() call from the
event handler that will be triggered on login will:

- greatly simplify the persistent login use case

- map neatly to the way many JS developers already work: register event
handler in a library, call navigator.id.get() on button click.

- help "close the loop" on the login process if there is ever a reload
of the web site's page, e.g. if the user leaves the web site to go check
their email for verification.

We'd love your feedback!

-Ben

[Burak Yiğit Kaya]

Hi Ben,

I think this is a good motivation though I'm not sure if it's the best
solution to the problems you mention. First of all, having an event system
actually means many different handlers can listen on the event which I fear
is not a very good use case for BrowserID. And secondly, how can you make
sure that the initial firing of the event is never missed? This can be a
tricky issue. I would suggest using something like the promises which can
be resolved immediately, use a property-like function to check the login
state(isLogged() etc.) or keep the current usage since it makes more sense.

Burak Yiğit "BYK" Kaya <http://byk.im>

On Thu, Jan 19, 2012 at 01:30, Ben Adida <b...@adida.net> wrote:

>
> Hi everyone,
>
> I want to propose that we move the main BrowserID API to an event model
> rather than callbacks. The existing callback mechanism would still work, at
> least for a while.
>
> The issue is logged here:

> https://github.com/mozilla/**browserid/issues/912<https://github.com/mozilla/browserid/issues/912>

>
> The main idea is that separating the navigator.id.get() call from the
> event handler that will be triggered on login will:
>
> - greatly simplify the persistent login use case
>
> - map neatly to the way many JS developers already work: register event
> handler in a library, call navigator.id.get() on button click.
>
> - help "close the loop" on the login process if there is ever a reload of
> the web site's page, e.g. if the user leaves the web site to go check their
> email for verification.
>
> We'd love your feedback!
>
> -Ben

> ______________________________**_________________
> dev-identity mailing list
> dev-id...@lists.mozilla.org
> https://lists.mozilla.org/**listinfo/dev-identity<https://lists.mozilla.org/listinfo/dev-identity>
>

[Ben Adida]

On 1/18/12 4:14 PM, Burak Yiğit Kaya wrote:
> I think this is a good motivation though I'm not sure if it's the best
> solution to the problems you mention. First of all, having an event
> system actually means many different handlers can listen on the event
> which I fear is not a very good use case for BrowserID.

Yes, I had this same worry. When I walked through all the use cases,
however, I realized that the callback approach was not that much better:
an attacker with script access to the site can easily replace the login
button with his own, set up his own callback, and intercept the
assertion almost as easily as by listening in on the event. So I think
events don't actually make security any worse, even if there is a
perception, at first, that they might.

> And secondly, how can you make sure that the initial firing of the event is never
> missed? This can be a tricky issue.

It's fairly straight-forward if you add the event listener before you
call navigator.id.get(), no?

And for the case where we want to fire the event automatically for users
who are permanently logged in, we follow a simple rule: register the
event handler before window.onLoad, and we promise not to fire the event
until after window.onLoad.

This seems relatively predictable. What do you think?

> I would suggest using something like
> the promises which can be resolved immediately, use a property-like
> function to check the login state(isLogged() etc.) or keep the current
> usage since it makes more sense.

This wouldn't be very different from callbacks in terms of what it
offers. Specifically, we'd like to be able to auto-fire the login event
if the user has opted to be always logged in. If you can't fire the
event until a promise is created (from calling navigator.id.get() I'm
guessing), then that feature goes away, and it's not clear that we have
a reason to move away from callbacks.

Let me know if I missed something.

-Ben

[Burak Yiğit Kaya]

2012/1/19 Ben Adida <b...@adida.net>

> So I think events don't actually make security any worse, even if there is
> a perception, at first, that they might.
>

Well, I was actually more worried about developers shooting themselves in
the foot rather than security concerns =)

> It's fairly straight-forward if you add the event listener before you call
> navigator.id.get(), no?
>

For this use case, it is simple yet I think worse than the callback
approach in my opinion in terms of clarity of the code since you can
practically assign an event handler in any part of the page though when we
call navigator.id.get() we actually expect something to happen and forcing
people to keep related code close together is a better approach IMO.

> And for the case where we want to fire the event automatically for users
> who are permanently logged in, we follow a simple rule: register the event
> handler before window.onLoad, and we promise not to fire the event until
> after window.onLoad.
>

What if the author/site owner uses some deferred script loading fired *after
*the onload event? Then how is (s)he supposed to get the login state? If
the answer is "by calling navigator.id.get()" then I think using the event
system is more like an overkill since we actually expect to have zero or at
most one event handler for this event. Actually this is the point why I
don't like this change, event system is designed for multiple event
handlers and in this case you expect at most one handler and in fact using
more than one handler would actually likely to break something and it is
possible for novice developers to mix some scripts together and end up
assigning multiple event handlers to this event.

I still think that if you want to know whether a user is logged in or not,
you should check it explicitly but then I cannot offer a better solution
for the e-mail followup scenario with lousy developers.

--
Burak

[Ben Adida]

On 1/18/12 5:13 PM, Burak Yiğit Kaya wrote:
> Well, I was actually more worried about developers shooting themselves
> in the foot rather than security concerns =)

Gotcha. I think JS events are fairly standard, at least as much as
callbacks.

> For this use case, it is simple yet I think worse than the callback
> approach in my opinion in terms of clarity of the code since you can
> practically assign an event handler in any part of the page though when
> we call navigator.id.get() we actually expect something to happen and
> forcing people to keep related code close together is a better approach IMO.

My sense is the opposite, at least from talking to some early adopters
of BrowserID: they wouldn't mind putting the event handler in an include
file of theirs, and calling navigator.id.get() on a button click.

> What if the author/site owner uses some deferred script loading fired

> /after /the onload event?

Yes, you're right, in that case, it may be harder to get the event to
them. But... maybe not. Our library could be smart about waiting for the
event to be registered and queuing it until then. I can see ways of
playing with this that remain very easy for the developer.

> Actually this
> is the point why I don't like this change, event system is designed for
> multiple event handlers and in this case you expect at most one handler

Not necessarily true. We were discussing how you might want parts of
your UI to flash or otherwise change when a login happens. Maybe not,
but if there are different parts of your UI that should react, which is
certainly possible in a complex JS app, then an event is exactly what
you need.

I'll note that I started out with exactly your point of view: this is
not an event. As I've explored the use cases, I've become fairly
convinced that this is, in fact, best handled by an event.

That said, you bring up important concerns. I still think it's worth
implementing, at least on a branch, and seeing how things work out.

-Ben

[Burak Yiğit Kaya]

2012/1/19 Ben Adida <b...@adida.net>

> That said, you bring up important concerns. I still think it's worth
> implementing, at least on a branch, and seeing how things work out.
>

I concur. I see your points and you made a really good job explaining them
so thank your this productive discussion =)

[Burak Yiğit Kaya]

2012/1/19 Burak Yiğit Kaya <b...@byk.im>

> so thank your this productive discussion =)

I meant to say "thank you for this productive discussion"

[Ian Bicking]

On Wed, Jan 18, 2012 at 5:30 PM, Ben Adida <b...@adida.net> wrote:

> Hi everyone,
>
> I want to propose that we move the main BrowserID API to an event model
> rather than callbacks. The existing callback mechanism would still work, at
> least for a while.
>
> The issue is logged here:
> https://github.com/mozilla/**browserid/issues/912<https://github.com/mozilla/browserid/issues/912>
>
> The main idea is that separating the navigator.id.get() call from the
> event handler that will be triggered on login will:
>
> - greatly simplify the persistent login use case
>
> - map neatly to the way many JS developers already work: register event
> handler in a library, call navigator.id.get() on button click.
>
> - help "close the loop" on the login process if there is ever a reload of
> the web site's page, e.g. if the user leaves the web site to go check their
> email for verification.
>

I see this removes silent: true - are the use cases for that being replaced
somehow? Does it all just get folded into "remember me" (or whatever it is
being presented as)?

Another use case this makes harder - and it's only a vague use case - is if
you have multiple interface elements that trigger a login, but mean
something different. They'll all end up in one bucket. One possible
example of this is app receipt verification, if you want to distinguish it
from "logging in" to the site. One case is identity confirmation, the
other is attaching identity to a site. I might want to create a flow like
this for instance:

1. decode app receipt, see that "f...@bar.com" paid for it
2. put up a big "login" button, user clicks it, run id.get(), no required
email, get response
3. log person into my site. If they are f...@bar.com, all good, they paid
for it
4. if they are not f...@bar.com then trigger another login with
requiredEmail (maybe with a little splash page to explain the purpose of
this second login)

So... come to think of it, that's mostly okay: I attach to "login", and if
I get a login besides "f...@bar.com" I treat it as the identity they want to
use, but don't let them actually use the application until "f...@bar.com"
comes in, and if that's the first thing that comes in then also treat it as
their identity. The fact that different interface elements triggered those
logins doesn't matter.

So I have yet to establish any actual use cases for interface element
specificity ;)

Ian

[Ben Adida]

On 1/19/12 9:55 AM, Ian Bicking wrote:
> I see this removes silent: true - are the use cases for that being
> replaced somehow? Does it all just get folded into "remember me" (or
> whatever it is being presented as)?

That's the idea: this gets folded into a fully user-controlled decision,
and simplifies the site's job tremendously. We noticed that few sites
seemed interested in doing the current rigamarole to enable permanent
login, which is quite understandable.

> Another use case this makes harder - and it's only a vague use case - is
> if you have multiple interface elements that trigger a login, but mean
> something different.

That's an interesting point. As per your walk-through, I'm having
trouble seeing when there is a true undetectable difference. If we can
come up with one, we might want to feed some extra parameters into the
.get() that come back to you in the event object, but I would propose we
do that only if we have a clear use case.

-Ben

[Burak Yiğit Kaya]

On Thu, Jan 19, 2012 at 20:05, Ben Adida <b...@adida.net> wrote:

> If we can come up with one, we might want to feed some extra parameters
> into the .get() that come back to you in the event object, but I would
> propose we do that only if we have a clear use case.

That sounds like a pretty good solution.