Marc Canter has been talking about his idea of the Open Mesh, especially its dashboard. In the new web, I’ve got all my services spread all over. The dashboard presents a centralized place to tie all these outside services together. To actually make all of these things work together, there are a bunch of pieces missing. The dashboard needs a way to connect to these services, a way to group the people who can access those services, and a way tell those services what rights those groups have to access them. So this is the first in a series of brainstorming about the gaps in the OpenStack to be filled to make this work.

Today, plenty of people want to tie together their identity from different places on the internet. They maintain a list of their identities at Flickr, Twitter, Magnolia, Plaxo and Brightkite. If they’re geeky, they may even mark these links with hCard attributes, so those places are marked rel="me". The geekiest keep a single page showing everything happening at those services, perhaps with Plaxo or FriendFeed or an Activity Streams plugin on their blog. But when you’ve got an account over at Ma.gnolia, there isn’t a good way to push that service back to your OpenID so it can advertise that you store your links there. Right now, you have to collect those identities manually. Doesn’t that just smell ripe for automation?

If you use OpenID, there is a document somewhere saying all the services your ID supports. For the moment, the list of possible services is pretty small. Your ID might be able to send your registration information, like name and email address, or maybe your PGP key. But right now, there isn’t much you can advertise in your discovery document. There isn’t a way to send your photo gallery, your microblog, your bookmarks.

But even if there were, there isn’t a simple way to update those services. The way disco docs work today requires someone to manually edit the disco doc to add a service. Even if that disco doc is automatically generated, it’s probably only generating services for stuff the OpenID Provider knows how to play with. So your service provider needs a way to tell the disco doc it wants to play.

It shouldn’t be too hard to design a service where Ma.gnolia can send a request to be added to the disco doc. All it really needs to do is send what type of service it is, and where the service lives. Since an XRDS disco doc has a format for this info, it is natural to send it:

<Service>
  <Type>http://ma.gnolia.com/links/1.0</Type>
  <URI>http://ma.gnolia.com/josephholsten</URI>
</Service>

These services need to be able to be added to, updated and deleted. The Atom Publishing Protocol is a great example of a protocol to handle collections like this. The real trick is to treat the XRDS document as a service link collection and give each of these service links a URI so they can be updated and deleted. With this API, it would be simple to access the services attached to an OpenID.

But doesn’t that mean any site could post some new service onto your identity? Not if we ensure the service is authorized to post before we do anything. And the most powerful general purpose authentication protocol today is OAuth.

Most of the time, you know if you want the service attached to your disco doc when you log in at the service. Assuming it lets you log in with OpenID, your OpenID Provider can just ask you if it should also give the service access to add to your disco doc. If you agree, the OpenID Provider can send an authorized OAuth Access Token along when it authenticates you to the service. The service posts its disco information to your disco doc, and Bob’s your uncle.

But since the OpenID-OAuth Hybrid protocol is not finished yet, the service provider could just ask to get authorized to post to your disco doc itself. It would send you to your disco doc’s authentication endpoint, you allow access, and the service can then update your disco doc like before.

The great thing about OAuth is that it allows us to control exactly who can update the disco doc. A smart dashboard would allow you to delete a service, all the endpoints it created, and revoke that service’s access to your disco doc.

To wrap up, I’d like to mention some alternatives to an XRDS protocol modeled after AtomPub. First, this data shouldn’t be in XRDS, but microformats or RDF. I sympathize and am convinced there should be representations of this data as both microformats and RDF, but think XRDS is optimized for just this case. Alternatively, this information could be pushed back via an XML-RPC or SOAP protocol. But since the end result is to change an XRDS document, HTTP verbs are well suited to the actions that would actually be used, where an RPC implementation would simply reinvent standard HTTP procedures and unnecessarily confuse the semantics. Finally, this could be implemented as an OpenID AX pushback service. But as as I know of no services using AX, there is little precedent to build upon. Regardless, I only want the simplest protocol that does the job, so if you can present something better I will gladly support it. Whatever gets the job done.