Capabilities and inheritance…

As I said before, I’ve been milling about in my head how capabilities can be passed around on the web. Mike Warot’s been riffing on this for a bit, and I think that, for the most part, we’re on the same page for what a credential actually is (UPDATE: I mean capability — I keep intertwingling these two terms but they are very different things), but I’m still a little fuzzy on the whole…

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

This part I agree with, and at first blush is very straitforward. Google Docs is a great example of a capability-based model. If you want to invite someone to view or edit, you can add them to a list and they get an email with a special link — containing their credential. The invitee always has that credential link, but the invitor can change the authorization associated with that credential at any time.  This is an interesting approach, and far from unique to Google — many web apps have been doing this for quite a while out of sheer necessity, what with identity a train wreck for too long and email the only standard form of testable credential. In a more robust credential-based model the invitor could even set attributes like expiration dates or authority tests for specific credentials (like OpenID, or even email, to minimize certain attacks).

But things get a little more convoluted when you bring in object inheretence. In Google Docs, sharing credentials is a snap, but what happens when Google lets you embed an external spreadsheet into a document? Will sharing write permissions to the document extend to the spreadsheet? What about the ability to edit an image embedded in the document? This can get pretty hairy pretty quickly and can lead to all sorts of classic inheritance problems.

Mike mentions S3’s buckets:

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.

Perhaps not, or perhaps they realized the potential complexity involved and simply punted, which may not be a bad idea. From what I gather, S3’s buckets are unique volumes, just like my concept of domains would be. If volumes are easy enough to instantiate, it would be a lot easier to manage permissions at the volume level. Setting up a blog? You have write on everything, the world has read on everything published. Inviting someone to coauthor? They get write on everything in that space. If you don’t like that, create a new space just for that person or group of people.

Of course, this completely blows up the easy send-me-an-email capability described above. I haven’t worked  through all the use cases in my head, but my guess is there room for both. But one thing I don’t want to do is reimplement the cascading nightmare that is administering a windows file share. Creating a system simple and clear enough for the average user to fully understand the implications of their actions is paramount.

One Response to “Capabilities and inheritance…”

  1. Mike Warot Says:

    I know it seems overwhelming, but consider the payoff… being able to share things and work on projects with anyone, and not having to worry about security. 8)

Leave a Reply

Underneath this flabby exterior lies an enormous lack of character…