Capabilities, Internet Style - Part 1

Dean is looking for a project for his Social Computing class. He's thinking about some form of Social File System. In response to a post about capabilities, he wrote:

So how would you suggest scaling capabilities to the internet? Everything I've always read about capability-based security alludes to persisting and passing file handles, but what does this look like on the web?

I have a Flickr account, with about 3000 photos now on line. If I want to publish photos, Flickr is the way to go... it's great for broadcasting. The thing Flickr lacks (by design) is any capability to delegate access to any portion of my account. There's no way I could create a bucket for someone to add photos to. Each photo is tied to an owner, and there's no way to delegate access.

So, from a capabilities view, a Flickr account is atomic.... you either have read/write access, or you don't. There's no granularity to it at all. If I wanted to share my flickr account I'd have to give my password to someone to do it.

Amazon S3 works in a more favorable way, from the standpoint of granularity. It treats each object as a separate entity, with it's own access control list. These objects live inside of buckets, each amazon user can have up to 100 buckets. This makes it easier to set the default permissions for objects, and segregate capabilities. Amazon thus supports delegating access, all the way down to the individual object.

From a capabilities perspective, it would seem that Amazon S3 is the way to go. It's certainly much better than the all/nothing approach of Flickr. However, you still have some significant restrictions.

S3 objects can be shared with other specific S3 users, ALL S3 users, and the world. There's no way to hand off an actual capability to someone without requiring them to have an S3 account.
Amazon wasn't thinking of how to optimize their service for capabilities when they designed it.

The next logical step would be to figure out how to extend Access Control to a distributed system of identity. This has to be an important feature in any Social File System. Implementing an Access Control List which allows both OpenID and Microsoft LiveID to be used to authenticate would be a good first step.

Now for the last step, the one that is subtle and very powerful. So far, we're still dealing with Usernames and Passwords. We need to take the last step, and get away from usernames and passwords. A pure capability isn't tied to any username or password. It grants specific access to an object (or set of objects).

Usernames and passwords work well for real live people. They should NEVER be given to code you can't trust. Capabilities offer path which allows for the separation of intent away from authentication.

Once authentication is out of the picture, then you can hand off a capability to a program, and it can't do anything outside of that capability, because it doesn't have any user names or passwords to give away. You don't have to trust that it won't send your bank password to China, because it can't.

So, how would it work? At the lowest level, I'd start with the same basic file systems we all know and love. I'd extend the data structure for the access control list to allow the creation of tokens. These would be a large random number, along with access rights, just like those for any other user. There would need to be a new API for generating these tokens, along with whatever tweaks would be required to integrate the extensions into the file system code.

Up a level, imagine being able to right-click on a file or folder somewhere, and say "generate capability" and have a dialog box appear which would allow copy/paste to take the resultant long text string and allow it to be given to a program.

Up a level more, you could drag and file (or folder) onto a web page, an the default action would be to allow write access to that folder (subject to the default policies you set in place)

You could even drag/drop that folder into an email, to allow the capability to be sent to a friend.

There's more here... thus this is part 1.

--Mike--