Tuesday, May 06, 2008

Capabilities, Internet Style - Part 2

I think the primary feature that capabilities have to offer to an internet environment is one of isolation intent from authentication.

Now... that's pretty obtuse, and I might have even said it wrong... I'll expound on it for a bit.


I want to be able to generate a token that gives access to a resource on the internet. I want to be able to do it in a way that only requires holding the token, with no other authentication necessary. I want to be able to issue multiple tokens to access the same resource. I want to be able to revoke a token without ambiguity. (I don't care about copies of the resource, that's a branch into the murky world of DRM)

I think the simplest way to do this is to write a proxy server that has the local authority to access a given resource, and to allow it to maintain the database of tokens, and to mediate access to the resource. I hope that this could eventually be folded into the operating systems, or even the kernel of Linux at some future point.

For now, a proxy, no matter how inefficient will suffice to demonstrate principles and help popularize capabilities as an better alternative to handing over authentication information to code you can't trust.

For now, the proxy has to allow a local user to generate access tokens, manage an access control list, and enforce it. I think that something that works locally and can be accessed via HTTP is the way to go.

I'll start working on a prototype... probably in Python, to help get this ball off the ground.

I'm interested in collaboration in all aspects of this project.


So... from a user perspective, you don't get much. You already have full access to your stuff. You get a toy which hopefully can allow you to sandbox access to a file and give it away, without your username or password being involved. (Unless of course the code in the proxy is bad, and goes all confused deputy on you)

Being able to give away access without sharing usernames or passwords helps make your internet node more valuable, because you can innovate once again. Heck, you might even get to the point where Metcalfe's law starts to apply again and get some real value going.



I hope that wasn't too far out for everyone.

What do you all think?

--Mike--

2 comments:

Dean Landolt said...

Mike...

Does it even need to be folded into the operating system? Isn't this right up FUSE's alley? It shouldn't be too hard to shape it into the proxy you speak of: a virtual file system that takes capability tokens and exposes file handles.

Put a WSGI server on top of that and with a well thought out API, you can expose all the necessary procedures to acquire "file handles" and operate on them.

I'm still chewing on the full text of your ideas here and I'm working up a post, but I think I get where you're going with this, but there are definitely a few issues -- specifically -- how do we pass these file handles around (YURLs?) and how are the inheritance issues handled?

Definitely a good start.

Mike Warot said...

Dean,
Wow... I had to look up FUSE, WSGI and YURLS, I've been out of the programming loop for a very long time.

I think that this is right up FUSE's alley. I know enough to get Ubuntu working, plus a bit more... but I'm no guru. It seems to me that if you put together a FUSE system, you could proxy local programs as well as net stuff transparently.

For a demo I think it's ok to expose both the URL and the Capabilities token... long term it might be better to hide it completely.

I think the eventual scheme would be something like:

cap://cap.warot.com/6167412fa423195153

A RESTful approach might be good as well, as I said, it's still all up for grabs.

Yes... I think we're off to a good start. Thanks!

--Mike--