Scott Kveton

One of my favorite discussions of day 1 at the OpenIDDevCamp was around what you could do with an OpenID end-point. About 15 people showed up to whiteboard and talk first at high-level and then drilling down into the details.

Now, a bunch of folks have been talking about this idea of moving to URL’s as identifiers in recent weeks (even me). The idea is simple; your OpenID is an unique end-point that can act to describe for sites where you get specific services from. For example, if I prove that I’m scott.kveton.com then a website could feasibly query that URI and ask “hey scott.kveton.com, you just logged into my site, can I have your friends list?” or “where can I find your calendar?”

We did our best to try to keep the discussion simple first and then drive into the details of the existing technology. Some basic service types we might want to describe included personal contact information, address book (aka social network or friends list), bookmark service, calendar, photo service or instant messaging. Defining them opaquely we get “my photo service is provided by Flickr” or “I use Google for my calendar”. That’s the easy part.

We had two problems to contend with after we’ve described the types of services we want to expose: privacy and ability to query in or out-of-band. How much information do I want public? How can I share it if I want it to be private for only a few people? Since OpenID works within the browser (consider this “in-band”), what if I want a service (like my photo or calendar service) to update something of mine with my permission when I’m not in front of the computer?

When talking about privacy, it looks like we have the components we need already. In the case of the public data, we can accomplish this with microformats or XRDS right at the OpenID URL. My contact information in hCard, my friends in XFN, etc. Using XRDS you could share where you get specific service types. If you want to lock this up a bit, you can use Attribute Exchange. It allows you to share only what you want to who you want. Ideally you’d be using the same URI’s for both in this scenario.

To deal with the in/out-of-band data problem the idea was floated to leverage OpenID + AX for in-band and OAuth + AX for out-of-band. If I’m logging into a site via OpenID with my browser, I could use Attribute Exchange (AX) to move my private (and public if I want) data. If the web service wants to update something for me or my OpenID provider wants to update something on a service, it can use OAuth which ideally would be automatically setup when the user logs in for the first time to the service.

In the future, we could even consider having an XRDS entry to describe how to add or remove entries into my list of services I use. Now you could have a web service ask you if you’d like to use them as your default photo service or calendar. Very cool stuff.

Now, we have the pieces described for what we want to do. The best part is we’ve been able to turn our OpenID end-point into the choke point for our public and private data. I can see all kinds of applications for other types of information you might want to land there as well (can you say your lifestream?). Looks for some folks (maybe those attending OpenIDDevCamp?) will implement these features in the near future. Let’s get some code out there and start playin’ with it!! Yeah! :-)