Tuesday, September 02, 2008

Protecting "discovery" information?

I’ve been thinking a lot lately about discovery of personal services (e.g. endpoint and metadata of my “portable contacts” service, endpoint and metadata of my preferred “email service”, etc). One problem with enabling discovery of this kind of information is that it leaks information about me. For example, I might not want the world to know where I keep my personal photos?

So the question is... How, in the world of open identity protocols, do I restrict access to a subset of my “discovery” information? The obvious answer is for the discovery service (or service provider in general) to restrict access based on the identity of the invoking party. However, how is that invoking identity presented? At first thought is seems like OpenID and OAuth should suffice, but it turns out this doesn’t work to well in practice.

Let’s take the following example and walk it through.
“Alice logs into her hiking site, uploads a GPS track and photos, and notifies her friends of the new information.”
  1. Alice logs into one of her favorite web sites (hikingtrails.example.com).
  2. Alice uploads a GPS track and some photos of a new trail she hiked over the Labor Day weekend.
  3. At the conclusion of her upload, hikingtrails.example.com asks Alice if it should notify her friends about her activity.
  4. Alice thinks that’s a great idea and agrees.
  5. So hikingtrails.example.com queries portablecontacts.example.com, using pre-established OAuth credentials, and retrieves Alice’s list of contacts with a tag of “hiking buddy”.
  6. Now for each of these friends, hikingtrails.example.com has to discover the “notification” service and send it the new activity message.
  7. One of Alice’s friends, Bob, only exposes the endpoint and metadata of his “notification” service to a restricted list of people.

It’s at this point that things begin to break down. How does hikingtrails.example.com identify Alice to Bob’s discovery service so that hikingtrails.example.com can attempt to discover Bob’s “notification” service? There currently isn’t a binding for OAuth to be used with XRDS discovery, and even if there were, it would mean that Alice would have to have an “account” at Bob’s discovery service in order for the discovery service to be able to authenticate Alice and establish OAuth credentials. While this would only have to be done once with Bob’s discovery service, the user experience would have to be repeated with each of Alice’s friend’s discovery service. That seems like over kill for the simple purpose of identifying Alice to Bob's discovery service.

A possible solution would be an “open identity token” that could be created by an identity provider and passed to any service provider. I have some thoughts on this that I hope to expound on in another post.

3 comments:

Anonymous said...

Good thoughts, George! I think you're on the right track: the essence is for hikingtrails to say to Bob, "i'm doing this on behalf of Alice, whom you know". If Alice has authenticated an OpenID identifier to hikingtrails, it could present it to Bob, and if Bob knows Alice by that same OpenID (or if there are a chain of rel=me links that can be traced) then Bob could say ok. But if Bob needs proof that Alice really authenticated with hikingtrails for that identifier, then hikingtrails needs to present some kind of "receipt", like a digitally-signed message from Alice's OpenID provider. Seems like a similar problem when wanting to invoke an API on behalf of a user that logged in with OpenID--just because hikingtrails trusted that Alice really owns that OpenID doesn't mean that others will trust that hikingtrails did that verification.

Personally, I'm not sure I mind my XRDS doc being public in practice, but I certainly understand the concern in theory, and if we can come up with a good practical solution for non-public service discovery, I'm sure it will be useful, so I think we should keep working here and see what we can come up with.

Thanks, js

Jakeo said...

George,

Interesting idea, and a good example.

The real question is why I would want to let hikingtrails.example.com go out and talk to all my friends.

In reality, I would suggest that if hiking trails wants to contact my friends, they should ask my portable contact service for the details.

My service can go and ask their service, potentially telling them that its hikingtrails.example.com that wants to know.

Then my service can tell hikingtrails.example.com what details to use.

R

George Fletcher said...

Jakeo: It's possible that portable contacts could grow into more than just managing my social graph and instead provide more information (e.g. endpoints, metadata, preferred notification method, etc). However, at that point it's acting like a discovery service. Plus, I think it (the portable contacts services) would have to discover my friends notification services before it could proxy that information. In that discovery call, it might need to provide some "identity token" for me to their discovery service.

The reason I picked a "notification" service is that in my discovery service I might specify that my preferred notification service is via SMS while someone else would prefer email at one of their less frequented email accounts.

You are correct that there are multiple ways to solve this problem (some probably better than what I outlined). However, I still feel that having an Open Identity Token will simplify many use cases (when it comes to privacy and sharing).