[xauth] Why disallowing "*" on retrieve?
14 views
Skip to first unread message
Will Meyer
May 7, 2010, 8:49:18 AM5/7/10
to xa...@googlegroups.com
Hiya,
Trying to grok the reason for disallowing "*" on the Retrieve call
(meaning "give me all tokens that have been extended to me, whether or
not I know the hosts that might have done so"). I think it makes a
big difference in terms of use-cases that can be supported.
Is it because of a security concern or an implementation artifact?
Security-wise, you can dictionary it and pretty much get around the
limitation if you really want to, it seems. Implementation-wise, I
don't know the latest on browser support but in theory with the api
you can .length and .key(index) and iterate everything (and if not
that, its at least possible change the data structure a bit).
Or maybe I'm missing something else obvious?
Also, I've mentioned this a few times but I still think there's an
error in the docs on the explanation of retrieve -- "extenders" don't
call this, retrievers do.
Thanks for any clarification!
W
--
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
Trying to grok the reason for disallowing "*" on the Retrieve call
(meaning "give me all tokens that have been extended to me, whether or
not I know the hosts that might have done so"). I think it makes a
big difference in terms of use-cases that can be supported.
Is it because of a security concern or an implementation artifact?
Security-wise, you can dictionary it and pretty much get around the
limitation if you really want to, it seems. Implementation-wise, I
don't know the latest on browser support but in theory with the api
you can .length and .key(index) and iterate everything (and if not
that, its at least possible change the data structure a bit).
Or maybe I'm missing something else obvious?
Also, I've mentioned this a few times but I still think there's an
error in the docs on the explanation of retrieve -- "extenders" don't
call this, retrievers do.
Thanks for any clarification!
W
--
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
Matthias Pfefferle
May 11, 2010, 2:21:43 AM5/11/10
to xAuth
+1
I am working on an XAuth+OExchange plugin for WordPress to test a
generic way of sharing things (some kind of a case study for YIID:
http://www.yiid.com). But if site-owers only get informations by a
specific list of hosts, all unknown or small hosts will be excluded.
Matthias
I am working on an XAuth+OExchange plugin for WordPress to test a
generic way of sharing things (some kind of a case study for YIID:
http://www.yiid.com). But if site-owers only get informations by a
specific list of hosts, all unknown or small hosts will be excluded.
Matthias
Joseph Smarr
May 11, 2010, 5:02:00 PM5/11/10
to xa...@googlegroups.com
I think the basic argument is: you should only ask for things that you know how to handle, since otherwise what's the point? Of course, the big limitation with domain-based-lookup for XAuth today is that you can't ask for "any site that supports protocol XYZ" (e.g. OpenID, OExchange, Portable Contacts, etc.)--but that should be easy enough to add, and I'm working on a proposal for that as we speak, which I'll share with the list as soon as it's a bit more solid. But if you don't know based on either the domain of the provider or the protocol supported, then you can't really do anything with the data you get back, so you might as well ask for a specific list of known domains and protocols.
Do you agree with that, and would it address your use case, or am I missing something else?
Thanks, js
Rabbit
May 11, 2010, 5:28:27 PM5/11/10
to xa...@googlegroups.com
I'm waiting eagerly for query-by-interface.
Will your proposal include limiting result sets?
Query-by-domain is intrinsically limited to the number of domains being queried whereas query-by-interface is unbounded. Would probably need a form of limit+page.
=Rabbit
Matthias Pfefferle
May 11, 2010, 5:28:34 PM5/11/10
to xAuth
But isn't the host/domain the only information you need to discover
the protocols/services you support?
* get alle hosts
* discover the host-meta
* check if the host supports OpenID/OExchange/PoCo/...
On 11 Mai, 23:02, Joseph Smarr <jsm...@google.com> wrote:
> I think the basic argument is: you should only ask for things that you know
> how to handle, since otherwise what's the point? Of course, the big
> limitation with domain-based-lookup for XAuth today is that you can't ask
> for "any site that supports protocol XYZ" (e.g. OpenID, OExchange, Portable
> Contacts, etc.)--but that should be easy enough to add, and I'm working on a
> proposal for that as we speak, which I'll share with the list as soon as
> it's a bit more solid. But if you don't know based on either the domain of
> the provider or the protocol supported, then you can't really do anything
> with the data you get back, so you might as well ask for a specific list of
> known domains and protocols.
>
> Do you agree with that, and would it address your use case, or am I missing
> something else?
> Thanks, js
>
> > > xauth+un...@googlegroups.com<xauth%2Bunsu...@googlegroups.com>
the protocols/services you support?
* get alle hosts
* discover the host-meta
* check if the host supports OpenID/OExchange/PoCo/...
On 11 Mai, 23:02, Joseph Smarr <jsm...@google.com> wrote:
> I think the basic argument is: you should only ask for things that you know
> how to handle, since otherwise what's the point? Of course, the big
> limitation with domain-based-lookup for XAuth today is that you can't ask
> for "any site that supports protocol XYZ" (e.g. OpenID, OExchange, Portable
> Contacts, etc.)--but that should be easy enough to add, and I'm working on a
> proposal for that as we speak, which I'll share with the list as soon as
> it's a bit more solid. But if you don't know based on either the domain of
> the provider or the protocol supported, then you can't really do anything
> with the data you get back, so you might as well ask for a specific list of
> known domains and protocols.
>
> Do you agree with that, and would it address your use case, or am I missing
> something else?
> Thanks, js
>
> > > For more options, visit this group athttp://
> > 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>
> > 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
Rabbit
May 11, 2010, 5:39:18 PM5/11/10
to xa...@googlegroups.com
What if XAuth returns 100 hosts and only 1 supports the protocol your
app is interested in?
Consider:
1) Does User have a token for me from ServiceX?
2) What tokens does User have for me?
3) What tokens from services implementing OExchange-Interface does
User have for me?
XAuth answers #1 currently. Which, if you know that ServiceX
implements a given service interface it's useful. (ie: I know people
can OpenID login through Google, Yahoo!, etc)
Query-by-interface would answer #3. So you could provide the user with
a potentially more relevant result set (ie: mom-n-pop-provider.com
supports OpenID login and the user has a session there)
Question #2 might be useful? What's the use case?
=Rabbit
app is interested in?
Consider:
1) Does User have a token for me from ServiceX?
2) What tokens does User have for me?
3) What tokens from services implementing OExchange-Interface does
User have for me?
XAuth answers #1 currently. Which, if you know that ServiceX
implements a given service interface it's useful. (ie: I know people
can OpenID login through Google, Yahoo!, etc)
Query-by-interface would answer #3. So you could provide the user with
a potentially more relevant result set (ie: mom-n-pop-provider.com
supports OpenID login and the user has a session there)
Question #2 might be useful? What's the use case?
=Rabbit
Matthias Pfefferle
May 11, 2010, 5:53:30 PM5/11/10
to xAuth
For this case, you could cache the host-meta informations for a short
period to save time. But isn't that how "discovery" works?
Certainly it is far easier to ask for all hosts that support
OExchange, but therefore a site-owner has to set one entry for each
services/api... what about a service with 30 apis... and how to expire
all these keys?
period to save time. But isn't that how "discovery" works?
Certainly it is far easier to ask for all hosts that support
OExchange, but therefore a site-owner has to set one entry for each
services/api... what about a service with 30 apis... and how to expire
all these keys?
Will Meyer
May 11, 2010, 11:27:58 PM5/11/10
to xa...@googlegroups.com
There's clearly a wide range of possibilities -- host-keyed arbitrary
strings, strongly-organized data structures, everything in between.
Would it help to restate specific questions the protocol answers (or
should try to)? Perhaps there's a wiki of key ones in our future...
It would be cool to hear that viewpoint from the main drivers/authors
of the spec.
FWIW I agree Rabbit the get-service-urls-by-protocol is quite
valuable. I don't know the latest feelings on the personal
discovery/webfinger ideas, but I remain a big believer in the
potential and have myself been thinking of XAuth as potentially a sort
of cache of Links that might otherwise, or also, be in a public
personal XRD. A set of Links, with relation types that are defined
and that you can look for, can live in local storage just like it can
live in xrd documents or viewable html pages. The expiry and
call-quantity issues you raise Matthias are real, though. There's
also the question of there being no user approval step required for a
site to add itself into your cache (rewind to those media players that
used to take over your registered mp3 extension handler every time you
happened to open one by accident).
Lastly, I also think it would be helpful to harden the current
host-oriented behavior, as a separate use case. If there's consensus
that there's value in a boolean test of the "is this a host of
interest to this user" variety, I'd ask whether it would be possible
to hide the actual token and expose the enum. As it stands, there's a
1024-character string that you shouldn't really look at, you can't get
determine things you don't already know to ask, and you're not sure
what the boolean existence check really means. With a few small
changes, we could allow tools to cleanly make their own judgements
about whether/how to use the information, and then focus on extending
into the richer typed discovery capabilities.
Curious as to others thoughts...
W
strings, strongly-organized data structures, everything in between.
Would it help to restate specific questions the protocol answers (or
should try to)? Perhaps there's a wiki of key ones in our future...
It would be cool to hear that viewpoint from the main drivers/authors
of the spec.
FWIW I agree Rabbit the get-service-urls-by-protocol is quite
valuable. I don't know the latest feelings on the personal
discovery/webfinger ideas, but I remain a big believer in the
potential and have myself been thinking of XAuth as potentially a sort
of cache of Links that might otherwise, or also, be in a public
personal XRD. A set of Links, with relation types that are defined
and that you can look for, can live in local storage just like it can
live in xrd documents or viewable html pages. The expiry and
call-quantity issues you raise Matthias are real, though. There's
also the question of there being no user approval step required for a
site to add itself into your cache (rewind to those media players that
used to take over your registered mp3 extension handler every time you
happened to open one by accident).
Lastly, I also think it would be helpful to harden the current
host-oriented behavior, as a separate use case. If there's consensus
that there's value in a boolean test of the "is this a host of
interest to this user" variety, I'd ask whether it would be possible
to hide the actual token and expose the enum. As it stands, there's a
1024-character string that you shouldn't really look at, you can't get
determine things you don't already know to ask, and you're not sure
what the boolean existence check really means. With a few small
changes, we could allow tools to cleanly make their own judgements
about whether/how to use the information, and then focus on extending
into the richer typed discovery capabilities.
Curious as to others thoughts...
W
Joseph Smarr
May 12, 2010, 2:03:59 AM5/12/10
to xa...@googlegroups.com
Yeah, basically the idea is that the host could embed a JSON representation of its own XRD in the XAuth.extend call, and that way retrievers could efficiently discover the services available from the extended providers without having to do an additional discovery lookup on each one. That's really the whole point of XAuth--the providers stick their info in XAuth on login/logout and that way the retrievers already have it ready and don't have to make O(N) calls to discover state/capabilities of N possible providers.
Thanks, js
Will Meyer
May 13, 2010, 6:19:04 PM5/13/10
to xa...@googlegroups.com
That all sounds cool, anxious to talk proposal. If anyone from the
discussion will be at IIW by the way, it would be awesome to talk
through some of this.
W
discussion will be at IIW by the way, it would be awesome to talk
through some of this.
W
Joseph Smarr
May 13, 2010, 6:54:33 PM5/13/10
to xa...@googlegroups.com
Yeah, was just going to ask: who's going to be at IIW next week? I will. We should definitely do a session on XAuth! Thanks, js
John Bradley
May 13, 2010, 8:29:11 PM5/13/10
to xa...@googlegroups.com
Yes that is a good idea. I will be there.
John B.
Allen Tom
May 13, 2010, 9:33:45 PM5/13/10
to xa...@googlegroups.com
+1
I’ll be at IIW next week too!
Allen
I’ll be at IIW next week too!
Allen
>> >> a potentially more relevant result set (ie: mom-n-pop-provider.com <http://mom-n-pop-provider.com/>
>> >> >>>http://www.yiid.com <http://www.yiid.com/> ). But if site-owers only get informations by a
>> >> >>>> xauth+un...@googlegroups.com <mailto:xauth%2Bunsu...@googlegroups.com> <xauth%2Bunsu...@googlegroups.com <mailto:xauth%252Buns...@googlegroups.com>
>> >>
>> >> >>>> For more options, visit this group athttp://
>> >>
>> >> >>> --
>> >> >>> 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 <mailto:xauth%2Bunsu...@googlegroups.com>
>> >> >>> <xauth%2Bunsu...@googlegroups.com <mailto:xauth%252Buns...@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
>> >> >> For more options, visit this group
>> >> >> athttp://groups.google.com/group/xauth?hl=en <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
>> >> > 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
>> >> For more options, visit this group
>> >
>> > --
>> > 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
>> > 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
>> 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
> 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
For more options, visit this group at
http://groups.google.com/group/xauth?hl=en
Matthias Pfefferle
May 14, 2010, 3:52:38 AM5/14/10
to xAuth
For your interest: Today, Eran Hammer-Lahav wrote about the JSON
serialization of XRD: http://hueniverse.com/2010/05/jrd-the-other-resource-descriptor/
On 12 Mai, 08:03, Joseph Smarr <jsm...@google.com> wrote:
> Yeah, basically the idea is that the host could embed a JSON representation
> of its own XRD in the XAuth.extend call, and that way retrievers could
> efficiently discover the services available from the extended providers
> without having to do an additional discovery lookup on each one. That's
> really the whole point of XAuth--the providers stick their info in XAuth on
> login/logout and that way the retrievers already have it ready and don't
> have to make O(N) calls to discover state/capabilities of N possible
> providers.
>
> Thanks, js
>
> > On Tue, May 11, 2010 at 17:53, Matthias Pfefferle <pfeffe...@gmail.com>
> > <xauth%2Bunsu...@googlegroups.com<xauth%252Buns...@googlegroups.com>
> ...
>
> Erfahren Sie mehr »
serialization of XRD: http://hueniverse.com/2010/05/jrd-the-other-resource-descriptor/
On 12 Mai, 08:03, Joseph Smarr <jsm...@google.com> wrote:
> Yeah, basically the idea is that the host could embed a JSON representation
> of its own XRD in the XAuth.extend call, and that way retrievers could
> efficiently discover the services available from the extended providers
> without having to do an additional discovery lookup on each one. That's
> really the whole point of XAuth--the providers stick their info in XAuth on
> login/logout and that way the retrievers already have it ready and don't
> have to make O(N) calls to discover state/capabilities of N possible
> providers.
>
> Thanks, js
>
>
> > >> >>>> For more options, visit this group athttp://
> > >> >>> 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><
> > xauth%2Bunsu...@googlegroups.com<xauth%252Buns...@googlegroups.com>
> > >> >>>> For more options, visit this group athttp://
> > >> >>> 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><
>
> Erfahren Sie mehr »
Mike Hanson
May 14, 2010, 1:40:57 PM5/14/10
to xa...@googlegroups.com
I'll be there.
Question: Will one or both of the PowerBox authors be there? I would really like to have a point-counterpoint on personal service discovery approaches; it seems like we're converging a bit.
m
peterw
Jun 7, 2010, 5:58:48 PM6/7/10
to xAuth
On May 12, 2:03 am, Joseph Smarr <jsm...@google.com> wrote:
> Yeah, basically the idea is that the host could embed a JSON representation
> of its own XRD in the XAuth.extend call, and that way retrievers could
> efficiently discover the services available from the extended providers
> without having to do an additional discovery lookup on each one.
As a Retriever/RP site, I'd be interested to see that sort of info.
> Yeah, basically the idea is that the host could embed a JSON representation
> of its own XRD in the XAuth.extend call, and that way retrievers could
> efficiently discover the services available from the extended providers
> without having to do an additional discovery lookup on each one.
Earlier you wrote
>> I think the basic argument is: you should only ask for things that you know
>> how to handle, since otherwise what's the point?
were able to use, that would help me decide what services I should
support on my end. I don't want to spend a couple weeks adding
Portable Contacts support to our site templates only to discover that
0.1% of our regular XAuth-supporting users can use PC. I'd rather wait
and let XAuth help me decided which services are worth our time.
Also, having more stats on the domains/hosts providing services would
help me decide which sites to test against.
-Peter
John
Jun 9, 2010, 2:23:36 PM6/9/10
to xAuth
Reviving...
If we have an interface it would be great to be able to pass a simple
relvalue string (mapping to the JRD's relvalues of course) to retrieve
data across all hosts. So then I could ask for, maybe,
"openid.server" and "*" for domain, and get back a list of all the
openid.server links in the associated JRDs for all the domains (just a
filter and merge of the JRD data, basically). Or I could ask for
"magic-public-key" and get back a list of public keys the user (says
they) own across all sites.
I think this requires some type inference for the token, though. (How
do you know it's JRD data?)
John
If we have an interface it would be great to be able to pass a simple
relvalue string (mapping to the JRD's relvalues of course) to retrieve
data across all hosts. So then I could ask for, maybe,
"openid.server" and "*" for domain, and get back a list of all the
openid.server links in the associated JRDs for all the domains (just a
filter and merge of the JRD data, basically). Or I could ask for
"magic-public-key" and get back a list of public keys the user (says
they) own across all sites.
I think this requires some type inference for the token, though. (How
do you know it's JRD data?)
John
Chris Messina
Jun 9, 2010, 3:41:02 PM6/9/10
to xa...@googlegroups.com
Also, for those worried about security/privacy of this, the interface could easily look something like this:
--
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
Where the string "would you like use your" could be substituted with service-appropriate language: "would like acces your OpenID" or "would like to access your sharing services".
Etc.
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
Will Meyer
Jun 9, 2010, 5:23:05 PM6/9/10
to xa...@googlegroups.com
>> If we have an interface it would be great to be able to pass a simple
>> relvalue string (mapping to the JRD's relvalues of course) to retrieve
>> data across all hosts. So then I could ask for, maybe,
>> "openid.server" and "*" for domain, and get back a list of all the
>> openid.server links in the associated JRDs for all the domains (just a
>> filter and merge of the JRD data, basically). Or I could ask for
>> "magic-public-key" and get back a list of public keys the user (says
>> they) own across all sites.
>>
>> I think this requires some type inference for the token, though. (How
>> do you know it's JRD data?)
>> relvalue string (mapping to the JRD's relvalues of course) to retrieve
>> data across all hosts. So then I could ask for, maybe,
>> "openid.server" and "*" for domain, and get back a list of all the
>> openid.server links in the associated JRDs for all the domains (just a
>> filter and merge of the JRD data, basically). Or I could ask for
>> "magic-public-key" and get back a list of public keys the user (says
>> they) own across all sites.
>>
>> I think this requires some type inference for the token, though. (How
>> do you know it's JRD data?)
FWIW I've been confused since launch what the value of having an
open-ended "token" at all is. Without structure, on either the
content or the lifecycle, isn't what we're talking about really just a
host-oriented version of the Storage spec? To my point on another
thread about the need to clarify the functional interface we want to
provide to services, I see value in a x-domain link-based store, a
boolean login session check, and a few other practical cases, but they
really are fairly different cases and if they share a substrate the
substrate is more generic than xauth as currently spec'd. To your
point, I don't think the token can be half-pregnant in terms of
typing.
Peter Watkins
Jun 9, 2010, 5:30:44 PM6/9/10
to xa...@googlegroups.com
On Wed, Jun 09, 2010 at 12:41:02PM -0700, Chris Messina wrote:
> Also, for those worried about security/privacy of this, the interface could
> easily look something like this:
>
> http://www.flickr.com/photos/factoryjoe/4684593122/sizes/o/
>
> Where the string "would you like use your" could be substituted with
> service-appropriate language: "would like acces your OpenID" or "would like
> to access your sharing services".
> Also, for those worried about security/privacy of this, the interface could
> easily look something like this:
>
> http://www.flickr.com/photos/factoryjoe/4684593122/sizes/o/
>
> Where the string "would you like use your" could be substituted with
> service-appropriate language: "would like acces your OpenID" or "would like
> to access your sharing services".
s/your sharing/your list of sharing/ -- right?
Yes, I would personally very much like to see that. But if the JS API is
stable and websites use John's recommended fallback technique, this sort
of thing can be left to 3rd party ISVs.
Does somebody here (Google?) have the resources to translate some strings
so that the hosted xauth.js could add such a UI (recording decisions to the
LocalStorage space)? If so, great, let's try adding a fairly simple UI (even
if users have to visit http://xauth.org/ to enable the dialog windows).
If not, it's no big deal so long as Extenders and (especially!) Receivers
use the (!navigator.XAuth) fallback code.
-Peter
Reply all
Reply to author
Forward
0 new messages