XAuth + JRD (was: Presenting on XAuth at Gluecon)

[Drummond Reed]

+1 to John's analysis. I am not saying the security or privacy considerations are trivial, I'm only saying that the potential to use XAuth + JRD as a discovery mechanism could deliver a lot of value to both the user and to the sites they visit.

Where would further exploration of this option happen? Here on this list? Is there any other forum for development of XAuth? Should this be pursued by creating an XAuth Trust Framework Working Group at OIX?

=Drummond

On Thu, May 27, 2010 at 9:24 AM, John Bradley <ve7...@ve7jtb.com> wrote:

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.

On 2010-05-27, at 10:58 AM, Chris Messina 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 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

On May 27, 2010, at 6:58 AM, Chris Messina <chris....@gmail.com> wrote:

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

On May 27, 2010, at 6:38 AM, Drummond Reed <dire...@informationcard.net> wrote:

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

On Wed, May 26, 2010 at 10:13 PM, Joseph Smarr <jsm...@google.com> wrote:

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

On Wed, May 26, 2010 at 8:42 PM, Drummond Reed <dire...@informationcard.net> wrote:

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 

On Wed, May 26, 2010 at 8:17 PM, Jian Shen <jian...@gmail.com> wrote:

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

On Tue, May 25, 2010 at 11:12 PM, Chris Messina <mes...@google.com> wrote:

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

--
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
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
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
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
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
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
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 at
http://groups.google.com/group/xauth?hl=en

[Chris Messina]

If we're talking about implementation details, then I think this is the right list for the discussion.

If we're also talking about the principles of a trust framework for XAuth, I also think this is the right place for that discussion.

I'd certainly like to see this list gain more traction — even if XAuth as it's currently specified isn't the long term solution to the problem. It may be that a trust framework might actually make it possible for such a centralized system to work — especially because it addresses a problem that technology alone can't.

Chris

On Thu, May 27, 2010 at 9:52 AM, Drummond Reed <dire...@informationcard.net> wrote:

+1 to John's analysis. I am not saying the security or privacy considerations are trivial, I'm only saying that the potential to use XAuth + JRD as a discovery mechanism could deliver a lot of value to both the user and to the sites they visit.

Where would further exploration of this option happen? Here on this list? Is there any other forum for development of XAuth? Should this be pursued by creating an XAuth Trust Framework Working Group at OIX?

=Drummond

On Thu, May 27, 2010 at 9:24 AM, John Bradley <ve7...@ve7jtb.com> wrote:

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.