Presenting on XAuth at Gluecon

[Chris Messina]

Just an FYI: I'll be presenting on XAuth for 10 minutes at Gluecon
this Thursday in Colorado:

http://www.gluecon.com/2010/Glue2010_Agenda.htm

If anyone has specific ideas or messages to get across, I'm open to
them!

Chris

[Jian Shen]

Hi Chris,

Here are a few slides that we used at Mozilla Labs Night if it helps with the technologies XAuth uses.

A clarification that's come up frequently: 

The intent of XAuth is to address what happens _after_ people have signed into a number of services that they use regularly. It should be thought of as a cache or a performance optimization eliminating the need for extraneous server calls between partner sites. It won't solve the discovery of OPs that the user has never visited for instance.

If you clear everything in a browser and hit a page with the NASCAR problem, XAuth can't really do anything for you at that point, but it can reduce a lot of noise for the user over time. That's all we're trying to do. :)

Good luck on the talk!

-Jian

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

Super, thanks!

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

[Drummond Reed]

Jian,

My understanding is that one format being considered for an XAuth token is a JRD. If so, could not a service the user trusted to publish their JRD do that via XAuth? And could not that JRD describe any number of services the user wants to be discoverable (just like if the user publicly published that JRD on their blog, for instance)?

If so, that JRD could be read directly by other XAuth retreivers to discover those services, regardless of whether the user is logged in or not, right?

Just wanted to clarify my understanding on this.

Thanks,

=Drummond 

[Joseph Smarr]

Drummond-in theory, what you're saying is correct. But I imagine in practice the more common use-case is for a service to publish its own endpoint info when a user logs in, e.g. "I'm logged into MyOpenID.com, and it's an OpenID provider, so it puts its OpenID endpoint info into XAuth, and then a retriever site can easily find my OpenID provider, even if it's never heard of MyOpenID.com, and it will know how to talk to it without having to make any other RPCs. And it can advertise it to me on their site as a good IdP choice, since it can be reasonably sure I'm already logged in."

Thanks, js

[Drummond Reed]

Joseph, thanks, I know that's the typical use case; I was just wondering if it could be extended to publishing a user's full JRD (or at least the JRD they want shared via XAuth). That way it _could_ be used to solve the NASCAR problem.

=Drummond

[Chris Messina]

It seems like we'd to add another call to retrieve such a document, but if providers are willing to publish that info to XAuth (or perhaps if discovery is set at the browser level) then yes, I could imagine XAuth being used in that way. 

I'd think it'd be more convenient for a requestor to get one JRD with all the pertinent services and endpoints than having to do two roundtrips. 

Chris

Sent from my iPhone 2G

[Jian Shen]

I think the point I was making was that if you never sign into any services, then your identity should still be anonymous to xauth retrievers. 

Say you visit google but never log in, google shouldn't know what to publish in a JRD to xauth that's truly personalized to your identity, unless google somehow is able to identify you without you actively logging in...

I think maintaining this expectation is important. It would be strange if my webfinger profile were magically made available somehow without me ever authenticating.

-Jian

[Chris Messina]

Though at the same time, nothing about XAuth today forces providers to authenticate users before extending your XAuth profile.

And though this may stray off topic — you could imagine visiting Random Site X which silently extends your XAuth profile w/o your consent or knowledge, right? I mean, it seems like that wouldn't create a tremendous amount of value for them, but of course they could do it with the way the model works today, right? And that might result in a bunch of none-useful entries in your XAuth profile, right? 

And worse, if the common model is what Joseph's described, then requestors might receive a list of bogus JRD endpoints (some of which the user may not have set). While I can of course monitor my XAuth settings and block rogue additions, in reality, the goal here was to minimize management of one's preferred services. Is this simply a known issue or a design feature?

Chris

Chris Messina
Open Web Advocate, Google

Web: http://factoryjoe.com

[Jian Shen]

Chris,

I think you highlight one of the bigger reasons for not having a wildcard search value because you as a retriever have to decide which xauth providers you trust. Normally you do this through agreements in the real world and then integrate.

With that in mind, having no wildcards in the retrieve call makes it harder for retrievers to shoot themselves in the foot.

I do think the JRD use case needs a bit more iteration to deal with the scenario you just outlined. While there is opportunity for extremely open discovery here, you'd need a mechanism to decide who you can trust as a provider.

-Jian

,

On May 27, 2010 7:58 AM, "Chris Messina" <mes...@google.com> wrote:

Though at the same time, nothing about XAuth today forces providers to authenticate users before extending your XAuth profile.

And though this may stray off topic — you could imagine visiting Random Site X which silently extends your XAuth profile w/o your consent or knowledge, right? I mean, it seems like that wouldn't create a tremendous amount of value for them, but of course they could do it with the way the model works today, right? And that might result in a bunch of none-useful entries in your XAuth profile, right? 

And worse, if the common model is what Joseph's described, then requestors might receive a list of bogus JRD endpoints (some of which the user may not have set). While I can of course monitor my XAuth settings and block rogue additions, in reality, the goal here was to minimize management of one's preferred services. Is this simply a known issue or a design feature?

Chris

On Thu, May 27, 2010 at 8:36 AM, Jian Shen <jian...@gmail.com> wrote:

>
> I think the point I was making was that if you never sign into any services, then your identity ...

--

> You received this message because you are subscribed to the xAuth group.

> To post, send email to ...

--

Chris Messina
Open Web Advocate, Google

Web: http://factoryjoe.com

Follow me on Buzz: http://buzz.google.com/chrismessina

...or Twitter: http://twitter.com/chrismessi...

--

You received this message because you are subscribed to the xAuth group.

To post, send email to xaut...

[John Bradley]

Once you can search for a particular service across all of the extenders you start running into that issue.

In the current release that is mitigated by having to ask for a specific extenders token.

In the current model a extender could set a JRD as there token.  That is probably not that interesting.

The other approach is making xAuth JRD aware so that you can ask for the users openID providers, and get back a list of them.

That certainly would create new security concerns if a RP could not tell the difference between Google saying they are my openID provider and some random 3rd party saying Google is my openID provider.

Perhaps there is some middle ground where you could have a service that published a JRD for you via xAuth so that the smaller providers and services could be discovered.  

However the user needs to visit that site to kick that off unless xAuth itself allows the user to edit and publish their own discovery doc.

There are a bunch of design tradeoffs that need to be looked at.

John B.

[John Bradley]

Yes,

The other option is to put a trust framework in place to have some control over the extenders via policy.

The problem is making this useful to more than the top three or for providers.   

In principal if the set of providers is limited they can all do there own service and xAuth is not adding much value.

John B.

[John Panzer]

IMHO:  If the results of xAuth are just used as hints rather than being authoritative, the potential for abuse is not high.  In other words, the payoff for getting your site into a list of "possible" sites to be presented to the user is... what, exactly?  (This assumes that a site must get a user to visit it before the site can add xAuth hints, and that I can't overwrite other site's entries.)

So I attract a visitor to my site somehow -- w/cute cat pictures, say -- and then advertise myself as a potential OP for that user.  Which the user will need to choose at some other site.  This is mildly annoying; if it started to be a problem perhaps we could do something like http://badwarebusters.org/community/submit and have community-enforced blacklisting.  

The problem with pre-federation is that you end up with the same NASCAR problem, just in your code.  To become an OpenID provider you now need to figure out how to convince every xAuth RP to add you to their whitelist.  This is reasonable to do for (say) a small set of banks, but unreasonable to do for every RP in the world.

So:  Mandatory whitelisting to make the protocol work, bad; optional whitelisting for high security operations, good.

[Drummond Reed]

John, this form of "whitelisting" is exactly what OIX was created to enable. So it seems like an OIX XAuth trust framework is just what the doctor ordered here, no?

=Drummond

[John Bradley]

I agree that having some sort of search is important.

Until we better define what the "Hints" are it is hard to define the security risk.

Getting back a list of photo service URI for the user may be useful to the RP's service,  However a bad person could add a photo service delivering adds or worse.

Some things may simply damage the reputation of xAuth.

Knowing who is doing the extension may be important for the RP to know.

If it is simply a list of binary hints about what OP's the user supports that is easier to control than a RP's interpretation of a JRD containing multiple services.

There are a number of possible approaches that can be taken.

John B.

[Will Meyer]

A week or two ago there was talk on this list of publishing a proposal
for an updated api/mechanism to handle some of these things (which
have come up before and were also discussed a bit at IIW). IMHO it'd
be awesome to discuss these tradeoffs in the context of a concrete set
of use-cases the system intends to solve, even without a proposed
solution.

A goal of "a way for a page to determine if a user is currently logged
into site X in this browser" is different than something like "a way
for a page to determine the set of services a user 'uses'" which is
different from "a way for a page to determine the set of endpoints for
specific protocol Z that have been identified for this user in this
browser", and a bunch more. It might be easier to talk about jrd,
webfinger/lrdd, public vs private, retrieve(reltype), retrieve(*), etc
if we had a crisper formulation of the target use-cases.

Sensible?

W

[Chris Messina]

Yes, agreed.

Now that I/O is behind us, we might have a little more head room to think about these things — but community-sourced proposals and ideas are more than welcome.

I know Joseph is rather busy these days — and I've personally got lots of travel coming up. That said, let's try to get something up on a wiki or a wave or a spreadsheet or *something* so we begin nailing these things down!

Chris

[John Panzer]

Yup; optional whitelisting as a service (OIX) sounds reasonable for many purposes.

[Chris Messina]

To those interested, I recorded a screencast of my talk:

http://vimeo.com/12121710

Happy to hear feedback (it's about 15 minutes long)!

Chris

Personal: http://factoryjoe.com

[Robert]

Chris, that was great.  It did pause to make me think -- when you said "100% front end technology" -- I'm not sure that's 100% accurate.  So tell me where I'm wrong here.  When you retrieve the token from XAuth, doesn't that essentially have a stored list of all the OPs?

Also, it occurred to me we could build something into XAuth that could potentially solve some of the nascar problem even more.  If there were a variable built in which specified *which* service a user preferred as an OP, the XAuth service could feed that information back to the receiving service (as well as the other providers).  This could eliminate nascar altogether in some scenarios.  One OpenID Connect button to rule them all, essentially.

While this could pose a risk in that some abusing OPs could/would want to be listed as user's without the user specifying such, I'm sure there's a way to make it so only the user can specify that.  Something to think about.  I'm such a proponent of making federated or single sign on services as utterly simple as possible, and such a preferred state would deliver.

What does the community think?

-- Robert

[Chris Messina]

Inline.

On Sat, May 29, 2010 at 4:29 PM, Robert <lang...@gmail.com> wrote:

Chris, that was great.  It did pause to make me think -- when you said "100% front end technology" -- I'm not sure that's 100% accurate.  So tell me where I'm wrong here.  When you retrieve the token from XAuth, doesn't that essentially have a stored list of all the OPs?

It does, except the data is stored in the browser — in the localStorage. The data is NOT stored on the server. Hence it's 100% server side.

 

Also, it occurred to me we could build something into XAuth that could potentially solve some of the nascar problem even more.  If there were a variable built in which specified *which* service a user preferred as an OP, the XAuth service could feed that information back to the receiving service (as well as the other providers).  This could eliminate nascar altogether in some scenarios.  One OpenID Connect button to rule them all, essentially.

 

Well, in theory, sure. In practice, I'm not convinced that people necessarily want to only use ONE provider for ALL every site. Or if they do, they'll still need a simple way to switch between the accounts they already have, perhaps at the browser level (like Chrome's incognito mode).

So, at the end of the day, we won't necessarily be able to get rid of the NASCAR altogether, but I do agree that one "connect button to rule them all" would be a nice way to invoke the selection of your preferred providers in different contexts:

http://www.flickr.com/photos/factoryjoe/4246318962/

While this could pose a risk in that some abusing OPs could/would want to be listed as user's without the user specifying such, I'm sure there's a way to make it so only the user can specify that.  Something to think about.  I'm such a proponent of making federated or single sign on services as utterly simple as possible, and such a preferred state would deliver.

There's no reason why the browser couldn't pop a prompt: "Do you want to set your account at Provider X as your default account?" 

That would make all of this simpler — though could get annoying if every site starts jockeying to play that role.

Chris