Webfinger location discovery

[Darren Bounds (Cliqset)]

Hi guys,

Earlier today I came across an article on RWW (http://bit.ly/b8Ft7l)
regarding a "Universal Check-in" being proposed by Mark Krynsky. The
idea, as the name implies, is similar to the goals of FireEagle in
that you check-in through a single service and that location is then
re-published to other LDS services. It seems to me that this is the
wrong approach and that it fact fits in perfectly with WebFinger.

I'm curious if there has been any discussion around how to express/
reference an individuals location within an XRD.

We've recently added our own WebFinger discovery resources and would
like to add discoverable location information as well.

Darren

[John Panzer]

I agree that Webfinger is the right approach :)

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

[Eric Mill]

I agree that this is the right approach, so how would this work? Two
approaches come to mind:

1) Location providers like FireEagle, Gowalla, Foursquare all settle
on a standard location auth/API approach for getting "your location".
My Webfinger provider has a special slot for me to enter in the domain
name of my Location Provider. From then on, location consumers can
look me up by my Webfinger, and get permission from the Location
Provider specified in my Webfinger profile through whatever standard
mechanism providers settled on.

2) I sign into Gowalla, which can see my Webfinger account from my
email, and it asks for permission (via OAuth I guess) to keep my
Webfinger profile up to date with my location.

Do either of these seem like a promising direction?

-- Eric

[Will Norris]

Most likely, you would enter your "Social Location API" endpoint URL in your XRD document, not just a domain name, but yeah that's the idea.

Actually both of them do.  #1 solves the problem of only being able to see the locations of those friends of yours who happened to have used the same service as you.  #2 separates the tool used to manage my location from the service used to store my location.  If these location services had a common API, then there's no reason why I couldn't imagine using Gowalla as a client to update my location on Foursquare.   I don't know how common this would be in practice, but it's certainly a reasonable model.

-will

[Eric Mill]

So is there any such thing as a "Social Location API" out there?
FireEagle has already set up a simple API using OAuth for
authentication, I wonder if Foursquare and Gowalla could be convinced
to adopt the "FireEagle API" the same way that Wordpress adopted the
Twitter API.

-- Eric

[Mike Hanson]

Yes, that sounds like exactly the right way to do it.  In the spirit of the times, perhaps it would be called OLocation?  (somehow OCanada suddenly comes to mind...)

If you have an OLocation-compatible location service provider in your XRD, it becomes really easy for any application to produce or consume your location... using OAuth to handle authorization for services makes sense.  

It's (as usual) trickier to figure out how client software should interact with it -- imagine your Mozilla Geolocation service, for example, or a dedicated app on a mobile.  But certainly solvable using the same techniques we've been talking about elsewhere.

And I'm quite taken with the idea of my GPS-enabled phone telling my location provider my exact location, so my web browser in my non-GPS-enabled laptop doesn't have to guess (with the user's permission, granted per-site (?), of course).  We'd have some homework to do in Firefox but it's quite solvable.

-Mike

--

Mike Hanson, Mozilla Labs

mha...@mozilla.com

[Eric Mill]

I like the ring of OLocation. Or OLoc ("Oh look..."). :) Though
honestly, to start out I doubt the whole thing has to be specced out
formally and named ahead of time - if 4sq or Gowalla just support
basic OAuth and follow FireEagle's example, things can move forward
quite rapidly.

I don't suppose anyone from Foursquare or Gowalla is on the list?

-- Eric

[Dick Hardt]

On 2010-03-08, at 8:06 AM, Eric Mill wrote:

> I agree that this is the right approach, so how would this work? Two
> approaches come to mind:
>
> 1) Location providers like FireEagle, Gowalla, Foursquare all settle
> on a standard location auth/API approach for getting "your location".
> My Webfinger provider has a special slot for me to enter in the domain
> name of my Location Provider. From then on, location consumers can
> look me up by my Webfinger, and get permission from the Location
> Provider specified in my Webfinger profile through whatever standard
> mechanism providers settled on.
>
> 2) I sign into Gowalla, which can see my Webfinger account from my
> email, and it asks for permission (via OAuth I guess) to keep my
> Webfinger profile up to date with my location.
>
> Do either of these seem like a promising direction?

Yes and no.

Similar to the issues around FOAF, advertising where your services are could be viewed as over sharing. In other words, I don't want to share who my location service is with the world.

Asking the user for their location service and having that standardized is a great idea. This also allows the user to run more than one service, and offer up the one that is appropriate for the context.

-- Dick

[David Recordon]

FriendFeed and Buzz users seem comfortable with sharing which services
they use. That isn't to say that there aren't use cases around
discovering non-publicly listed services, but there's a lot to do with
public stuff first.

--David

[Dick Hardt]

On 2010-03-08, at 1:58 PM, David Recordon wrote:

> FriendFeed and Buzz users seem comfortable with sharing which services
> they use. That isn't to say that there aren't use cases around
> discovering non-publicly listed services, but there's a lot to do with
> public stuff first.

Users were "comfortable" with FOAF files at first as well ...

IMHO, Webfinger solves the bootstrap discovery problem: binding an identifier the user is familiar with to a place to ask more questions. Like FOAF, I think additional information being published will be problematic from a privacy point of view.

-- Dick

[Eric Mill]

But, it's a choice on the user's part - this would be opt-in,
certainly. So I don't really see the privacy concern.

-- Eric

[Dick Hardt]

The FOAF model took the opt-in approach as well once the privacy issues were understood. How many FOAF files are there out there? Not many, and most have very little data.

Making the services I use publicly available makes it much easier to spear-phish me.

-- Dick

[Eric Mill]

I would put the blame on slow adoption of FOAF on the fewer services
out there that use such information. By contrast, use of location
awareness by web and mobile apps is exploding.

-- Eric

[Darren Bounds]

Any additional context available aids in spear fishing, it certainly
isn't limited to services information or location.

Frankly, if the information is already published in a public document
then exposing it via programmatic discovery like this isn't an issue.
Some services will be comfortable with this, others won't.

Darren

--
darren bounds
dar...@cliqset.com

[Dick Hardt]

On 2010-03-08, at 2:39 PM, Darren Bounds wrote:

> Any additional context available aids in spear fishing, it certainly
> isn't limited to services information or location.
>
> Frankly, if the information is already published in a public document
> then exposing it via programmatic discovery like this isn't an issue.
> Some services will be comfortable with this, others won't.

I agree if it is public, then having it available programatically does not make a difference.

I believe that a model where the user pushes their service information is much better for security and privacy than where anyone can pull it at will.

-- Dick

[Kevin Marks]

Sounds like you're on the wrong mailing list then, as enabling service discovery is the entire point of webfinger.

 

[Dick Hardt]

On 2010-03-08, at 2:37 PM, Eric Mill wrote:

> I would put the blame on slow adoption of FOAF on the fewer services
> out there that use such information. By contrast, use of location
> awareness by web and mobile apps is exploding.

Pretty much all location awareness apps I have encountered have asked permission to get my location, and they know my location service by virtue of where they were installed. I must be missing where the location service discovery is happening and the use exploding.

I was pretty active telling FOAF supporters what the privacy issues were, and when they moved to opt-in, no one wanted to bother.

meta-point: let's learn from history. FOAF was not adopted for a number of reasons.

-- Dick

[Kevin Marks]

OpenSocial Person has a Location structure in it already:

http://wiki.opensocial.org/index.php?title=Opensocial.Person_(v0.9)#opensocial.Person.Field.CURRENT_LOCATION

specified as an Address (which is a vCard style address structure + GeoPoint)

[John Bradley]

I agree that there will be a mix of public and private services.

That was one of the things we discussed in the design of XRD.

It is possible that one of the links you have in you public XRD is to a private XRD service. that requirers authorization before disclosing more information.

We also considered returning a private XRD as a AX value or SAML assertion.

Private XRD can also safely contain access tokens for the services they describe.

John B.

[Dick Hardt]

I am a big fan of Webfinger for discovery of my OpenID Provider. I think there will be mass adoption issues with using it for other services. I would hate to see Webfinger fail because of that, and not be able to use it with OpenID.

[Eric Mill]

Any client would still have to ask the user's permission to get their
actual location. What the client would not have to do is ask the
user's permission to discover where to *look* for that location.

I don't see how exposing what location-aware services you use is
exposing anything private.

-- Eric

[John Panzer]

So, define the location-service rel value and also the location-service-discovery-service rel value.

[tyler gillies]

IMHO the reason why FOAF sucks is because the whole paradigm of "social graph" is false. My "social graph" changes everyday, and is not bound by some chart of connections.

Location on the other hand, is a very concrete thing. I am either here, or there. (shut up all you quantum physicists out there)

--
Everyone Loves Tea
http://www.everyonelovestea.com