Sharing NASCAR via WebFinger
Will Meyer
I wanted to take a minute to recap the use-case/requirement view of
the nascar issue for "sharing" specifically, from some of us in the
sharing-tools camp. This is likely old hat to everyone here, but if
you care, here goes the "why" of recommending WebFinger as part of the
OExchange [1] stack (which some on here have given much-welcomed
feedback on already).
CONTEXT
Goal is to present users with appropriate options for operating on a
url with a given external service; this includes, predominantly,
"sharing" it. This determination needs to span machines, browsers,
sites, and time. It must not be required that the set of all possible
services be known at design time.
First, assume we have a common way to identify a "service" (in this
context, its via an URL to an XRD doc that contains a few specific
links and properties). So reduce the problem to one of associating a
set of service descriptor URLs with the user. There are various
algorithmic techniques, and even some common hacks (e.g. css visited),
that sharing tools use in this area, but none actually solve the use
case at the highest level.
REQUIREMENTS
1) Let a user publicize the set of services they prefer to use for
sharing URL-based content.
Characteristically, this set:
- is not necessarily the same as the set they are logged into on the
current machine
- is not necessarily the same as the set they have logged into before
on the current machine
- is not the same as the set of services they have visited in their browser
- is not limited to services known at design time by whomever is
providing the options
- is relatively stable over time
- contains a subset which the user will treat as "public"
In terms of implementation requirements, this set:
- must be available on more than one machine, ideally in more than one browser
- should be persistent across cookie/storage clears
- must not be modified without the user's consent
- must be obtainable in some low-friction way
In other words, the user needs a way to expose this set to
applications across the web, such that they can all honor the user's
preferences and present appropriate options once given some kind of
minimal user identification (e.g. when I go to a tech blog, show me
the chiclet for my long-tail hangout, and an email button, and that's
it).
2) Leverage publicly-available preferred service information to
streamline how one user can share content with another
This is the negotiated-communications-channel case -- be able to, as a
user, enter someone's email address into a tool, and let that tool
determine a service that that user uses, that you do as well, then use
that service to exchange the content. This is really just an
additional layer on top of the base case, which becomes possible with
publicly-exposed preference information.
USING WEBFINGER
Obvious, but...
- define a link relation type for the XRD URLs I mentioned earlier
(these XRD documents describe the OExchange "target")
- add these to user xrds via XRDP [2] (with some additions)
- let tools look those up for users by getting their "email address"
then performing the webfinger flow
More detail on this is in the spec [3].
Recapping from a user perspective:
- a user should be able to enter their email address to "personalize"
the options they see on any site, without any service-specific auth
required (no nascar required to solve your nascar)
- tools can use html5 storage or whatever else to keep track of these
as they see fit, across sites (even possibly XAuth, with some changes)
- a service should be able to request that it be added to a user's
personal XRD, likely via an OAuth'd XRDP call. IOW, go to flickr,
flickr asks you if you want to make it a preferred photo sharing
service, google asks you if you are sure you want to let flickr do
this, you say yes, voila.
While its true that a user may use services that they wouldn't want to
publicize, the user simplicity we get by excluding those, rather than
adding an auth step, is I think a big win. Given your email address,
any tool can customize itself to your settings. Given your friend's
email address, you can figure out mutual services (or just fall back
to email of course).
What I think is the still-open issue is the "refresh frequency" of the
personal XRD-housed data, and this is where we start potentially
talking about interesting browser/client cache solutions...
A small group of us also talked a bit about all this at IIW recently,
there are some related slides I prepped for that though didn't
actually use [4].
In any case, I'd love to hear any thoughts on the caching/refresh
issue as well as anything to do with practical provisioning.
Fin.
W
[1] http://www.oexchange.org
[2] http://xrdprovisioning.net/
[3] http://www-local.oexchange.org/spec/#discovery-personal
[4] http://www.slideshare.net/willmeyer/iiw10-nascar-for-sharing