Agency is a puffed up word used to way to say that somebody else is doing the work for you. A real estate agent, for example, sells your house for you. The paranoid worry that agents won’t manifest exactly your best interests as they do the work.

The other day I overheard somebody saying he wanted to allow users of his site, call it A, to give permission to other sites, call them B, to push and pull information from A. That ought to be common, but it is not. eBay has a scheme for doing this; but that maybe the only example I’ve seen in the wild of what ought to be a common pattern.

For example say I wanted to delegate to a B site permission to scan my email for important messages and when it finds them it should send me SMS. For example say I wanted to give permission to site hosting my blog permission to pull URLs from my private bookmarks site. For example I want to give permissions out so that my blogging and email sites can collaborate to make posting something I got in an email more trivial.

The usual, and extremely lame work around for this is for site B to ask for my user name and password at site A. Site B then visits site A pretending to be me and get’s the data it needs. That’s bogus because it grants site B far more power to act on my behalf than is desirable. This is the “Here let me help! Oh, I’ll just need to steal your identity.” approach.

Better systems aren’t hard to build. For example Site A can have a page that the user fills out to state: “I grant site B the following rights to act on my behalf for the following period.” Submitting that page results in site A coughing up a big number, in effect a ticket (technically it’s called a capability). The user gives the capability to site B.

Just a small matter of standardization?

Actually no. These such simple systems that standards, while nice, aren’t really necessary. All site A needs to do is keep a table recording the capability tokens it has handed out. When site B wants to do work as the users agent it works directly with site A. The best news is that it does not have to lie. It no longer needs to masquerade as the user. Site B authenticates with site A using it’s own account. Site A knows who it’s working with. When B wants to do some work for the user it includes with it’s request the Site A capability token it got from the user.

Site A then has to check if the requested operation is approprate; e.g. timely, within the rights the user granted, and something Site A currently trusts Site B to do. Site A can then lookup who the user is and do the deed. Site B never need know the user’s identity at Site A.

I suspect the real reason this is so uncommon is that site A doesn’t really want to relinquish data to site B; it would rather horde that data and the options for what to do with that data closely. In the dreams of site A’s product managers holding the data enables them to lock the user into a more bundled solution. Capablities help temper this concern, notice that Site A can negotiate with Site B over time to reach mutually advantagous deals.

Small sites should do two things. They ought to enable this kind of agency because it will create complements around their offering; while complements always make your offering more valuable they also let small sites collaborate to create integrated experiances that currently only huge portals can. The second thing they should do is just as important though. They should be prepared to limit partner site access in scenarios where it becomes clear that they are taking more than they are giving back. I.e. some sort of peering agreement would be a good thing.

If small service sites can enable this kind of activity highly cool highly integrated services will emerge quickly, much more quickly than the product manager at any tightly integrated centralized site can manage to implement them.

Fear of agency v.s. fear of concentration – damn’d if you do damn’d if you don’t.

(thanks to the three people who noted typos so far)