[xauth] Clarifying the problem XAuth does not solve.

23 views
Skip to first unread message

Rabbit

unread,
Apr 20, 2010, 9:26:52 PM4/20/10
to xa...@googlegroups.com
Just making sure I understand.

XAuth answers the question:
"Does Jane have a token for Service X?"

It does not answer the questions:
"What services does Jane have tokens for?"
"What service does Jane use as her identity provider?"

In other words, it is unlikely this will help unpopular-idp.com as the
request to XAuth has to specifically ask the question: "Is Jane most
likely logged into unpopular-idp.com?"

Is this correct?
Also, what is the significance of the token? I'm a little confused as
to why it was included.

=Rabbit

--
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

unread,
Apr 20, 2010, 10:06:29 PM4/20/10
to xa...@googlegroups.com
No, your understanding is not completely correct.

The token can contain anything that your service provider wants to include, on your behalf (so make sure you trust your provider!).

Retrievers can currently only query for information by domain (i.e. does the user have an active "reddit.com" session?). We hope to add support for querying by service type as specified by some set of extensible URIs.

It is possible but not clear whether a retriever would be able to request all known providers for a user... though that doesn't seem out of the question.

Your unpopular-idp.com could list itself as "speaking OpenID" and thus be returned to all retrievers that ask for "OpenID service providers". It helps out unknown services quite well in that case.

Chris
--
Chris Messina
Open Web Advocate, Google

Personal: 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

Rabbit

unread,
Apr 21, 2010, 12:10:21 AM4/21/10
to xa...@googlegroups.com
I see. That's actually really cool. :)

Token is completely open ended and the only consistent information that can be conveyed is whether or not a token exists indicating the presence of a session between the queried service and the browser.

I would be interested to hear how the extensible URI's could potentially be added. Seems to me it could be added by just one additional meta parameter indicating the data format of token.

Example Response JSON:
{
    "cmd": "xauth::retrieve",
    "id": 2,
    "tokens": {
        "xauth.org": {
            "interfaces": {
                "xrd": "http://namespace/xrd-uri",
                "someother": "http://someother/"
            },
            "token": "{ \"xrd\": \"http://example.com/my.xrd\", \"someother\": \"hello world\" }",
            "expire": 123456789
        }
    }
}

The token would be a JSON encoded string. The object keys of "interfaces" dictate the object keys of the JSON token object. You could then query for a specific interface. I imagine XRD would be an important next step due to the storage limits of localStorage.

Sorry, if I'm jumping ahead of conversations that have probably already taken place.

=Rabbit

Chris Messina

unread,
Apr 21, 2010, 1:36:55 AM4/21/10
to xa...@googlegroups.com
XRD in JSON is how I imagine this shaking out, but I'm leaving the specifics to Joseph.

Thanks for taking a crack at it though! ;)

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

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

Sam Johnston

unread,
Apr 21, 2010, 6:06:37 AM4/21/10
to xa...@googlegroups.com
Chris,

If I understand well it appears the "Does Jane have a token for Service X?" question unnecessarily retains an unfortunate characteristic of NASCAR pages whereby only the most popular services are supported (thus encouraging the creation of a small number of large IdPs while excluding a large number of small ones).

A much more interesting question IMO is "What *protocols* does Jane have tokens for?". For example, my site speaks OpenID so which OpenID services does Jane have active sessions at (there may be many - big ones that throw in IdP services like AOL, Google, Microsoft, etc. as well as IdP-specific providers like myOpenID). If I still want to maintain a white- or blacklist of OpenID providers then that's fine, but I don't have to fire into the darkness and hope I hit something.

I'm also curious as to whether the storage of token data (rather than just returning booleans) is worth the potential cost and concerned that there might be security implications we haven't considered (e.g. sites reading/writing tokens for other domains, circumventing cookie mechanisms for tracking, interactions with SSL, etc.).

Sam

=nat

unread,
Apr 21, 2010, 10:30:28 AM4/21/10
to xAuth
Yes, I think it is much better to have a pointer to the user's or his
Discovery provider's XRD in the XAuth than
the actual tokens from providers. I have not closely evaluated yet,
but I have a concern that
individual XAuth token can be used to correlate a user across domains
or "sectors",
which is a privacy breach. If that is not the case, then I will be
very happy.
Someone please do the analysis.

=nat
> >> xauth+un...@googlegroups.com <xauth%2Bunsu...@googlegroups.com>
> >> For more options, visit this group at
> >>http://groups.google.com/group/xauth?hl=en
>
> > --
> > Chris Messina
> > Open Web Advocate, Google
>
> > Personal: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
>
> > --
> > 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
>
> >  --
> > 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 <xauth%2Bunsu...@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
>
> --
> 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 athttp://groups.google.com/group/xauth?hl=en

Chris Messina

unread,
Apr 21, 2010, 12:53:43 PM4/21/10
to xa...@googlegroups.com
On Wed, Apr 21, 2010 at 3:06 AM, Sam Johnston <s...@google.com> wrote:
Chris,

If I understand well it appears the "Does Jane have a token for Service X?" question unnecessarily retains an unfortunate characteristic of NASCAR pages whereby only the most popular services are supported (thus encouraging the creation of a small number of large IdPs while excluding a large number of small ones).

We're not going to solve that problem today. The best we can do is address the world as it is, and provide a path forward to the way we want it to be.

Overnight we're not going to get people to switch off to running the show on their own domains — and for the vast majority of people, just knowing whether they're a "Google", "Yahoo", "Hotmail," et al, -user is better than the status quo (for example, I never login using Windows Live ID or Yahoo — so why ever show them on the login screen?

Though I may have an active session with Yahoo — but never use it for signing in — removing just one option from the NASCAR could actually provide an appreciable usability improvement to make it worthwhile.
 

A much more interesting question IMO is "What *protocols* does Jane have tokens for?". For example, my site speaks OpenID so which OpenID services does Jane have active sessions at (there may be many - big ones that throw in IdP services like AOL, Google, Microsoft, etc. as well as IdP-specific providers like myOpenID). If I still want to maintain a white- or blacklist of OpenID providers then that's fine, but I don't have to fire into the darkness and hope I hit something.

Indeed. I agree. In using the "system registry" metaphor, this is what I was envisioning.

It's a challenge for now — because making your services known via XAuth before you've explicitly visited them or signed in is not possible. So, the "cold start" barrier with XAuth is actually significant. It's only after some time that XAuth — on a single machine — would be able to accurately render your preferences on a protocol basis.

Curiously, it would be perhaps easier if your IDP just set a service type of "WebFinger" and your WebFinger profile did the heavy lifting of providing a persistent list of your preferred services.
 

I'm also curious as to whether the storage of token data (rather than just returning booleans) is worth the potential cost and concerned that there might be security implications we haven't considered (e.g. sites reading/writing tokens for other domains, circumventing cookie mechanisms for tracking, interactions with SSL, etc.).

My understanding of the security model is that services can't write tokens for other domains, though we'd have to consider whether google.com could, for example, set a token for youtube.com as your preferred video sharing service.

There are plenty of security considerations to investigate and I hope this community pursues them; at the same time, we're not doing much more than existing cookie technology with the additional design of leveraging HTML5's more robust local data storage/origin security model.

And as I've said before — XAuth is a more transparent way for you to have this information stored on your behalf — rather than "about you" invisibly by other parties where you can't audit or block the entries on a granular level.

Chris
Reply all
Reply to author
Forward
0 new messages