XAuth feature detection standardization and future proofing

[John]

The discussion over at the OpenID list motivated me to write up my
proposal for an improved XAuth snippet. My JS-fu is weak, but the
basic idea is to avoid duplicate loading and more importantly allow
for swap-out of XAuth implementations in the future:


Suggestion: Change the snippet from the current:

<script type="text/javascript" src="http://xauth.org/xauth.js"></
script>

to something like

<script>
if (!document.XAuth) {
document.write('<script src="', 'https://xauth.org/xauth.js', '"
type="text/JavaScript"><\/script>');
}
</script>

...and then the API can be implemented by, basically, anybody. The
first module to install document.XAuth gets to handle the
implementation; if nobody does, then https://xauth.org is the
fallback, and obviously initially is the only implementation.

Then you could transparently implement XAuth in a browser extension
without needing to do hacky things or modify IdPs and RPs. If the
interface is stable enough, browsers could implement this in the
future and the xauth.org site would basically be for backwards
compatibility.

[Chris Messina]

+1. This is a good solution and provides a pathway to handing off this functionality to the browser.

My JS-fu is worse, but shouldn't it be more like:

<script>
if (!browser.XAuth) {
 document.write('<script src="', 'https://xauth.org/xauth.js', '"

   type="text/JavaScript"><\/script>');
}
</script>

Seems like if the browser were to have the user's set of services available globally, this would be the way to get at that data.

I'd eventually like to see things like browser.user.services, browser.user.identity, and browser.user.profile be available, but I think we're still aways off from that.

Chris

--
You received this message because you are subscribed to the xAuth group.
To post, send email to xa...@googlegroups.com

To unsubscribe from this group, send email to
xauth+un...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/xauth?hl=en

--
Chris Messina
Open Web Advocate, Google

Web: http://factoryjoe.com
Follow me on Buzz: http://buzz.google.com/chrismessina
...or Twitter: http://twitter.com/chrismessina

This email is: [ ] shareable [X] ask first [ ] private

[Dirk Pranke]

Well, there is no 'browser' object defined by default, so this won't work.

As to whether or not creating a global 'browser' object is a good
idea, that's a different topic ...

Otherwise, I also give a +1 to John's suggestion.

-- Dirk

[Chris Messina]

I defer to those with more JS Fu.

My +1 still stands. ;)

[Peter Watkins]

+1

I also like that proposal very much. BTW, I think "navigator" is what you
want for a scope broader than "document".

http://msdn.microsoft.com/en-us/library/ms535867%28v=VS.85%29.aspx

-Peter

On Wed, Jun 09, 2010 at 11:19:20AM -0700, Chris Messina wrote:
> +1. This is a good solution and provides a pathway to handing off this
> functionality to the browser.
>
> My JS-fu is worse, but shouldn't it be more like:
>
> <script>

> if (!*browser*.XAuth) {

[John Panzer]

Amusingly, IE's "navigator" apparently has an obsolete "userProfile" member: "Provides methods that allow a script to request read access to and perform read actions on a user's profile information."

--
John Panzer / Google
jpa...@google.com / abstractioneer.org / @jpanzer

[Peter Watkins]

I'd like to hear Microsoft's take on document vs. navigator. Maybe the
Chrome/Chromium folks, too.

I just remembered one significant behavioral difference between MSIE
and Firefox that is relevant. MSIE windows inherit session credentials
from their parents, and do not share session credentials with windows
spawned from different ancestors. You can open two MSIE windows and
with each one log in to the same website as different users if that
website uses session-scoped auth cookies.

Firefox, by contrast, shares session credentials, cookies, etc. across
different browser windows.

In the Firefox model, "navigator" seems right. But in MSIE, if an
Extender adds a token with extend() that it flags as a session token,
I think "document" might make more sense. And it's easy for document.XAuth
to refer to a browser-scoped object, but perhaps not so easy for
navigator.XAuth to refer to window-specific token collections, especially
if the core navigator JS object is actually shared between MSIE windows.

Chrome might have similar issues due to its one-process-per-tab security
model.

-Peter

On Wed, Jun 09, 2010 at 05:01:30PM -0400, Peter Watkins wrote:
> +1
>
> I also like that proposal very much. BTW, I think "navigator" is what you
> want for a scope broader than "document".
>
> http://msdn.microsoft.com/en-us/library/ms535867%28v=VS.85%29.aspx

> On Wed, Jun 09, 2010 at 11:19:20AM -0700, Chris Messina wrote:

[Dirk Pranke]

Disclaimer: I am not speaking on behalf of any Chrome/Chromium people
other than myself, but ...

1) I believe the Navigator object is basically a readonly collection
of properties and probably
should not be encouraged for new use.

2) I don't think we want to encourage a direct link to a
"browser-wide" object. It is possible that
we might have this stuff return window-specific data (tied to a
particular session). For example,
whatever the calls return might be very different in a normal Chromium
window and an Incognito
window. I think that call can be left up to the implementation as to
what is returned, and so
"window.XAuth" feels more correct to me.

Of course, window.XAuth also opens up the possibility that different
windows might have
completely different implementations of the object (as well as
different states). Whether or not this
is a good thing, I'm not sure yet.

-- Dirk

[Mike Hanson]

Speaking in a informal Mozilla capacity -

I agree that a browser-wide object might lead to regret since it locks us into the idea that the current user-service-context is identical in every tab. (The incognito example is a fine one)

Peter Watkins wrote:
> Firefox, by contrast, shares session credentials, cookies, etc. across
> different browser windows.

I would not assume that this will always be the same. I am aware that some conversations may be happening that might change this behavior.

I concur that window feels like the right scope to me right now.

m
--
Michael Hanson, Mozilla Labs (@michaelrhanson)