Scott Kveton

I’m at SFO on my way back to Portland after a fantastic weekend in Sebastopol, CA at SG FooCamp ‘08. A really, really huge thanks to Tim O’Reilly, Sara Winge, Tony and the rest of the O’Reilly staff for providing a fantastic venue for this event. Also, we had some great sponsors in BBC, Google, MyStrands, Six Apart and Yahoo! We couldn’t have done it without you.

As a little background, David Recordon and I came up with the idea for SG FooCamp literally 44 days ago. The original idea was to get a bunch of hackers together, lock them in a room for a weekend and see what happens with respect to distributed/portable social networking, data portability, etc. Slowly but surely the invite list went from 10, to 25, to 30 … then David mentioned it to Tim and the idea was hatched to turn it into a FooCamp style event and host it in Sebastopol. Sweet. Now we can go all the way up to 70 people. We blew through that about an hour later and by the time all was said and done, we had over 100 people show up for the event.

It rained most of the weekend in Sebastopol (I must have brought it from Oregon with me) but the rain actually forced folks to stay inside and participate … the sessions were fast and furious and some of them pretty intense. It was cramped inside the O’Reilly facility but it sort of reminded me of the old school OSCON events hosted in the basement of the Portland Marriot; small spaces led to so many great conversations (and the booze helped to lubricate things).

Some of my favorite moments:

• Putting names with faces for just about everybody else I follow in Twitter
• Chris Mocko amazing us with his statistical prowess (“I’m less likely to be a werewolf this round”)
• Drinking the XMPP koolaid – XMPP may be the killer app that drives things like OAuth and OpenID … its the data stupid. Really cool stuff Twitter is doing in this space.
• Great OpenID/OAuth discussions
• Portland representin’ with Matt Tucker, Renny Gleeson, Brian Ellin and myself (and technically Brad and David)
• Watching Brad and Eran figure out OpenID <-> Email identifier specification in a matter of minutes.
• Discovery, discovery, discovery.
• Talking about OpenID as a URL (why is that interesting?) as well as UI.
• Realizing that Joseph Smarr is not only a great developer and evangelist for Plaxo, he’s also a great entertainer and tequila provider … err enabler.
• Fantastic Open IPR discussions (yes, this can be fantastic) … I’m always drawn finding an end solution and the idea was hatched for an administrative org like “The Open Web Foundation” to help technologies like OpenID, OAuth and others … who knows if it makes sense … hoping to talk more about this.
• Quality time with Chris Messina.
• Renny Gleeson coining the term “ebrandgelist” and thinking he actually coined it … :-)
• Making Sara Winge laugh and doing my video interview after far, far too much cider.
• Endless games of werewolf until late, late, late into the night.
• Getting to meet Chris Saad and talk seriously about Data Portability (have a whole other post to share on this).
• Sleeping outside both nights while the temperature was in the 30’s … I knew I kept that +15 bag for a reason.

I took about 500 pictures over the weekend and will be posting them on Flickr soon (its going to be tough; Ignite Portland 2 is on Tuesday and I’m not ready!)

What started as a weekend of hacking turned into a chance to bring together a bunch of different folks that don’t necessarily know each other. The biggest thing I’m taking away from this weekend is the direct connection to so many fantastic people. Now when I see their tweets, I’ll hear their voices and see their faces. I don’t know if we’ll do this event again. There was so much interest and we could have done a Social Graph conference on this (easily I think). Hopefully we can weave some of those themes into upcoming events like the Data Sharing Summit or even IIW.

Thanks everybody for participating and I can’t wait to see everybody again soon.

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! :-)

This just in from the my-lord-these-guys-are-fast department we have word that OAuth Discovery 1.0 specification has just been published. OAuth is yet another building block that will be critical for the open web. Okay, so what’s the big deal?

OAuth Discovery 1.0 uses the XRDS format coupled with Yadis to do the actual work. I know what you’re thinking; more stinkin’ acronyms you need to remember. No, no … its not like that. I swear, this is a good thing. XRDS and Yadis are used with another well-known protocol: OpenID.

OpenID 1.1 and newer have used Yadis for service discovery but unfortunately there hasn’t been anything to discover other than “hey, your OpenID provider is here!”. Most of the big OpenID providers support Yadis discovery and these are the same folks in the conversation about supporting OAuth as well. With OAuth Discovery using the same mechanisms for discovery as OpenID, you could now land your OAuth credentials on your OpenID provider and have it handle the discovery for that as well. Alright, let me break it down like a fraction for ya … :-):

The geek of all of this is that your OpenID is an end-point that you (and only you) own. Being able to do discovery on things this end-point can do (like “who proves who you are?”, “how do you authenticate with OAuth”, etc) means other sites can take advantage of you proving who you are to do ever cooler things. OAuth is just one more thing you can do at this end-point (and reality, one of the first “cool” things other than the actual OpenID authentication).

What does the future hold? Imagine being able to use discovery to find other services. What if I could use the discovery services to tell other sites where I get my social network from? Where and how people can attach to my public and private feeds? Information on who is providing my authoritative activity stream? It all could all land at these end-points and give sites lots of valuable information about the user while keeping that user in complete control.

I’m really excited about what OAuth means and the fact that they are using the other building blocks to make it a reality. All of these tools are coming together to build the applications we’ve all been talking about for years. Portable social networking is just around the corner and with it will come the reality that social networking isn’t something you go to a site to do; its something you’ll do on every site.

Yesterday the OAuth 1.0 specification was announced as final. This has been brewing for a few months and I’m amazed at the work that Chris and Blaine and the rest of the specification editors that have been working on this.

For those that don’t know, OAuth can best be described from the site itself:

The answer is simple, OAuth attempts to provide a standard way for developers to offer their services via an API without forcing their users to expose their passwords (and other credentials).

The launch of OAuth 1.0 reminds me a lot of the early days of OpenID. A small group of people leading with code and solutions has come together to build a fantastic solution to the API key problem. A light-weight technology that does one thing really, really well. That’s really cool and they did it in record time.

I’ve had quite a few people ask me “Why isn’t this a part of OpenID?” Again, the answer is best explained from the oAuth website:

The answer is simple, OAuth attempts to provide a standard way for developers to offer their services via an API without forcing their users to expose their passwords (and other credentials). If OAuth depended on OpenID, only OpenID services would be able to use it, and while OpenID is great, there are many applications where it is not suitable or desired.

Now, I actually think the two are really complimentary because OpenID doesn’t solve the API key problem. As a matter of fact, it makes it even more difficult. Using OpenID and oAuth together mean we can authenticate via OpenID and hand out oAuth keys to allow out-of-band access for web services or desktop applications. This is fantastic. Now we’re getting some very interesting technologies that are describing the open web.

Congrats to the OAuth crew for getting 1.0 out the door!