"New services" use-case

[Will Meyer]

In the interest of continuing to detail possible changes/additions to
XAuth that we've discussed here off and on...

The use-case I'm most focused on is the one in which the client does
not know about every possible service at design-time. There are some
other use-cases of note as well, I posted some over on the webfinger
list (I didn't x-post since I think most here are on that:
http://groups.google.com/group/webfinger/browse_thread/thread/5895c74c1b71d780)

This is to some extent a superset of requirements we've discussed here
(some of which are described at the end of Chris' great video[1]).
It'd be cool if we could leverage XAuth, as it gains adoption. The
OExchange JS demo [2] doesn't actually use XAuth, even though it does
use postmessage/iframe/localstorage like everything else, because the
XAuth spec currently doesn't support that case. A good example if
you're using that demo is click "Edit this list" then "Add", then add
www.instapaper.com or www.bitly.com or even www.addtoany.com -- all
added since the demo code was built.

So recapping, as currently spec'd XAuth is a single-machine,
single-browser list of black-box strings keyed by hostname. You can
retrieve these strings (if the setting host allows you to) by
providing the hostname you are interested in, which you therefore must
know a priori. This works for a "are you logged into twitter.com
y/n?" case, albeit in a perhaps loose way as there's not a clear
definition of what the "session" lifecycle is or what it really means
to have a token. It doesn't yet handle most of the other
requirements, most notably this dynamic discovery thing.

As discussed on this list, the XAuth API could be refactored to
provide a service-oriented registration/request model instead. In
this case, we would store links (as far as OExchange is concerned, it
would be "target XRD" URIs) in XAuth storage, and clients would ask
"give me all the sharing endpoints registered in this browser". If
XAuth starts using JRD for tokens as has been discussed, that could
live underneath, but that doesn't solve it alone -- its a different
index we're talking about (the call would be something like
retrieveLinks(relType), not retrieveLinks(hostName)). This gets us
more than we have today. It doesn't though meet the web-wide aspects
of the use case, still relies on a shared iframe and a
postmessage-based api (if not shared JS in the calling page) from some
kind of central server, lets services add themselves automatically
without user knowledge (if you can trick someone into visiting a page
on that domain one time), and is limited to a single browser.

The general idea of a local store/cache of personal discovery
information is powerful no doubt. Design-wise, it would be nice to
see it in the browser as opposed to via mutually-loaded iframes (with
a server dependency), and not as a replacement for a distributed
version that can be used in some of the ways we've discussed here, but
as a compliment to it -- a cache. That said, a service-oriented
version of the current XAuth proto would be practically useful if it
was spec'd and avail now...if we had that, we could start building at
least sorta-real code on top of it right now, which would be cool.

W

[1] http://vimeo.com/12121710
[2] http://www.oexchange.org/demo/blog

[Chris Messina]

I do think this is where this needs to go -- and I think this group
would be more than happy to entertain one or more strawmen to help us
make progress. That is: YES! Let's do it! ...but how should it
actually work?!

Another idea I've been meaning to throw out there (and maybe should be
directed to the OExchange list as well) is the ability to post
ActivityStream-based messages -- or something equivalent to Twitter's
tweet + annotation model, so that we can support more than just
sharing actions, but others as well.

For example, in someone's personal discovery profile (maybe we call it
"personal API"?) there's a list of several dozen endpoints for all the
activity types (verb/object pairs) that they support (or for which
they have previously set up services as handlers). That way we can go
further than just "share this link" but support cases like "recommend
to a friend" or "add product to my global wishlist/registry".

I think there's something here -- but the tension is to keep it simple
while supporting many unique use cases.

Chris

Sent from my iPhone 2G

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

[Will Meyer]

On Fri, Jun 4, 2010 at 09:55, Chris Messina <chris....@gmail.com> wrote:
> I do think this is where this needs to go -- and I think this group would be
> more than happy to entertain one or more strawmen to help us make progress.
> That is: YES! Let's do it! ...but how should it actually work?!

Concretely, if we had a "service"-first instead of a host-first api we
could use it in demo JS right now. Its not "extending an auth token
from host X to some set of other hosts" its "registering an instance
of a service endpoint of a particular type". There are still some
issues, notably the fact that there's no protection on who can add to
this and whether a user has any idea its happening, but it would be
functionally useful to play with at least and flesh out some of the
ideas. This isn't actually related to XAuth AFAIC other than by the
fact that its iframe/postmessage/localstorage-based, but hey, if we've
got a means to that, we should use it. The API to me is
Link-oriented. Set a link, get links by reltype.

>
> Another idea I've been meaning to throw out there (and maybe should be
> directed to the OExchange list as well) is the ability to post
> ActivityStream-based messages -- or something equivalent to Twitter's tweet
> + annotation model, so that we can support more than just sharing actions,
> but others as well.
>
> For example, in someone's personal discovery profile (maybe we call it
> "personal API"?) there's a list of several dozen endpoints for all the
> activity types (verb/object pairs) that they support (or for which they have
> previously set up services as handlers). That way we can go further than
> just "share this link" but support cases like "recommend to a friend" or
> "add product to my global wishlist/registry".
>
> I think there's something here -- but the tension is to keep it simple while
> supporting many unique use cases.

Thats exactly the tension, yes -- I think its critical that we avoid
negotiation requirements as well. We can pick that up on that list
(there was discussion already about how to do "like" with oexchange
for example), and where the line is between basic url exchange with
tons of services and deeper, app-domain-specific kinds of integrations
via things like AS content. Overreaching in the type space is I think
the risk.

>
> Chris
>
> Sent from my iPhone 2G

Really? ;-)

[John Panzer]

The only real objection to this as part of xauth is a potential for
abuse by bad actors that fool users into visiting them. This is a
very small exposure if the data is used to fill out choice lists; but
the benefits of an open system are huge.

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

[Mike Hanson]

Couple thoughts:

- We definitely need to rope in the Powerbox folks (Tyler Close, Mark Seaborn, and Kenton Varda at Google) to this conversation. They are talking about very similar problems and very similar solutions, but with slightly different language. The latest spec is here: http://lists.w3.org/Archives/Public/public-device-apis/2010May/0133.html

- The Powerbox API as currently proposed is findService[relType], as Will sketched below -- it has the additional optional step of letting the service present some UI to create a less-powerful URL, which fits with OAuth model pretty well. Ultimately the requesting page gets a URL, same as in XAuth.

- There's a lot of proposals kicking around about how service discovery should happen. So far I've heard well-known/host-meta (with a Link), a Link element in content, a Link header (q.v. WebLinking spec), a JS API, and a special "type" attribute on the A element. The axes of the design here are:
who gets to write to the list
how the user picks from the list
whether the user-agent is able to manage the list
how selection from the list (e.g. "relType") is filtered.

The use cases for "adding a service" vary from very explicit - "I want to register this new sharing service in my browser" to the totally implicit - "Here are all the sharing services you've ever navigated to, and I've tried to sort them nicely". Implicit cases would benefit from more context, which probably means deeper browser integration (e.g. it would be nice to have access to the history to rank the services by frequency/recency).

- Integration with a cloud-based store of the service preferences, probably through Webfinger, sounds like a really good idea. I'm beginning to imagine something like this:
A browser-based store of service endpoints, which is automatically discovered as the browser navigates the web.
An integration in the browser with one (or more?) webfinger/XRD endpoints, so that the browser updates something in the cloud as the user makes new discoveries or changes their preferences, and everything gets synced across devices/browsers nicely.
(probably) A JS API to query this store by type and perform "chaperoned introductions" between services and consumers (the Powerbox spec is farthest along on this idea)

Implementation questions for me are:
- Is the browser-based store actually the XAuth local storage, or is it some other database that is not addressible through postMessage?
- Could this system be designed in a way to provide backwards compatibility through a pure JS API, but have the nicer webfinger & chaperonage stuff for browsers that knew about it?
- Could the XAuth cloud implementation connect to a user-provided webfinger and perform this synchronization in the pure JS API (I think so, but there are cross-origin issues to hammer out)

-Mike

[Robert]

My two cents on this objection.  The potential for abuse lies not just in XAuth, but in *all* distributed technology.  It's very, *very* Wild West as I see it.

That is all.  :)

[John Panzer]

(Yes, though this argument applies to simply visiting arbitrary websites as well.)

[Chris Messina]

On Fri, Jun 4, 2010 at 9:18 AM, Mike Hanson <mha...@mozilla.com> wrote:

Couple thoughts:

- We definitely need to rope in the Powerbox folks (Tyler Close, Mark Seaborn, and Kenton Varda at Google) to this conversation.  They are talking about very similar problems and very similar solutions, but with slightly different language.  The latest spec is here: http://lists.w3.org/Archives/Public/public-device-apis/2010May/0133.html

- The Powerbox API as currently proposed is findService[relType], as Will sketched below -- it has the additional optional step of letting the service present some UI to create a less-powerful URL, which fits with OAuth model pretty well.  Ultimately the requesting page gets a URL, same as in XAuth.

Good call. One wonders where this discussion and work should be had. W3? XAuth? Mozilla Labs?

 

- There's a lot of proposals kicking around about how service discovery should happen.  So far I've heard well-known/host-meta (with a Link), a Link element in content, a Link header (q.v. WebLinking spec), a JS API, and a special "type" attribute on the A element.  The axes of the design here are:
       who gets to write to the list
       how the user picks from the list
       whether the user-agent is able to manage the list
       how selection from the list (e.g. "relType") is filtered.

It seems like this can/should be lead by user experience design... and that we should work to address those use cases. We can bikeshed the way this information is expressed til the yakks come home, so having an idea for how the interaction is performed would be useful in the meantime.

 

The use cases for "adding a service" vary from very explicit - "I want to register this new sharing service in my browser" to the totally implicit - "Here are all the sharing services you've ever navigated to, and I've tried to sort them nicely".  Implicit cases would benefit from more context, which probably means deeper browser integration (e.g. it would be nice to have access to the history to rank the services by frequency/recency).

How do operating systems currently deal with this when it comes to installed apps that handle multiple file types? Is it possible or even desirable to offer less functionality than what we already have at the OS level?

 

- Integration with a cloud-based store of the service preferences, probably through Webfinger, sounds like a really good idea.  I'm beginning to imagine something like this:
       A browser-based store of service endpoints, which is automatically discovered as the browser navigates the web.
       An integration in the browser with one (or more?) webfinger/XRD endpoints, so that the browser updates something in the cloud as the user makes new discoveries or changes their preferences, and everything gets synced across devices/browsers nicely.
       (probably) A JS API to query this store by type and perform "chaperoned introductions" between services and consumers (the Powerbox spec is farthest along on this idea)

Implementation questions for me are:
       - Is the browser-based store actually the XAuth local storage, or is it some other database that is not addressible through postMessage?
       - Could this system be designed in a way to provide backwards compatibility through a pure JS API, but have the nicer webfinger & chaperonage stuff for browsers that knew about it?
       - Could the XAuth cloud implementation connect to a user-provided webfinger and perform this synchronization in the pure JS API (I think so, but there are cross-origin issues to hammer out)

This is why it's super important to have browser folks involved in this discussion! Could an extension also take over this functionality? Ultimately we just need a way to point to service handlers — using a conventional protocol.

Man, doesn't this quickly head down the path of POWDER and WS-*?

http://www.w3.org/2007/powder/

http://www.soaspecs.com/ws.php

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

[Peter]

Hi

I am working with a group call the safe internet alliance

Where I am pulling together a proposal for allowing third party sites,
to discover what parental policies, or indeed any privacy policies are
located with that device.

We have floated xauth as a lower level discovery layer, in order for
sites, to find where to look for policy requirements.

Here is a use case . Parent signs up a browser to
"parentPolicy.com' (fake site) , here they set up their family
requirements, for example, to limit children posting personal
information shared with the world on Socialnetwork.com

Parentpolicy is an extender and writes itself into the local storage
with a token that will be called back by social network.

When the browser visits socialnetwork.com, the site knows it needs to
play in the policy space and so makes a bunch of requests for all
known policy providers that support the layered policy standard.

Here is where i see the issues raised in this topic. We now have a
NASCAR problem on the inside, where does socialnetwork.com go to
discover what providers to ask for.

Sure for our layered standard, we could hold a web service registry at
say parentpolicy.org for example. But now it feels like we are doing
the job of xauth, although it could help keep out rogue
providers.

I really like the service discovery proposal to help sort this issue
out. But there is a nagging voice saying what about bad actors
knocking out the registered provider.

Echoing Chris concerns, this needs to stay simple.

For our specific concerns, I am thinking that there is no other way,
than local tools, to help lockdown the settings, warning when changed
etc, preventing dislocation.

Is this discussion moving forward? I am based in sf and if there are
any meet ups going on to discuss, I woukd love to throw our hat in
plus some resources. (cold beer and food!)

Cheers

Peter Maude
CTO Crispthinking.com