At Mark's request, I'm following up to my own earlier comments on droplets. I may have left the wrong impression about my view on droplets, and it would be a shame to do that. I needed to actually read Tyler's documents before following up.
Editorial:
There are some important inaccuracies on the Droplets pages. Much as I cherish him, Norm did NOT invent much of capability-based security. Similarly, on the main page, the statement "The capability model is the only proven, successful model for computer security." is simply untrue. I believe that it is important not to overstate the case on these things, lest our community lose credibility. Let us instead confine ourselves strictly to statements that are accurate and defensible.
Originality:
Droplets is not the first system to use this kind of mechanism. While the specific encodings are different, the Lotus Domino server uses an essentially similar mechanism for naming Notes objects in web-based presentation -- even the format of the URL is highly similar. The Domino server, however, is not using swiss numbers; it's capabilities are purely object identifiers. Permission checking in Domino is done based on the session (and therefore on the user identity).
It is not clear to me if Domino has session-only capabilities. If anybody cares I will try to find out. Domino, however, was not envisioned as a general web-based mechanism, so Droplets may be unique in that regard.
Mind you, I don't think this detracts from Droplets; quite the opposite.
Security:
Here I find that my initial impression of Droplets is correct, though I
think my concerns could readily be addressed. Droplet capabilities are
unforgeable, but they are not partitioned. Because they are simply data,
there is no way to restrict their transfer once they escape into the world.
From my reading of the description at
http://www.waterken.com/Droplet/index.html (which I may have understood
incompletely), the session-independent capabilities remain valid
independent of any particular session. On the one hand the droplet
capabilities cannot be forged, but on the other they cannot be trusted as a
means of security because there is no way to constrain their propagation.
Once they are out in the world, one may safely attribute to them only those
qualities normally attributed to object identifiers.
Droplet's session-only capabilities, when running over an SSL link, provide a kind of partitioning for droplet capabilities, though hostile programs might still act from the client side by piggybacking on the session. This is a significant narrowing of exposure, and potentially very valuable. This is the part of Droplet that most appeals to me. The piece that seems to be missing is a private transform that will let me translate a new type of sessionless capability (let's call it an unauthenticated capability) into a session-local capability, and a corresponding public transform that will let me turn the session-local capability back into an unauthenticated capability.
In its current form, Droplets has some potentially very useful properties:
+ It can be used to selectively publish things on a server that otherwise
contains private information (this is because of the swiss numbering)
+ It can be used to extend the web URL space to generalized object
identifiers (128 bits might be too small, but not because of security).
[and probably others as well; this is only what struck me first.]
So in summary: I think this mechanism is interesting and valuable, and that
it is very much worth looking at. I think it is the start of a usable,
general security mechanism. I think further work is needed to really bring
it to fruition. I even think I would like to help. Whether IBM will let
me is another question.
Jonathan S. Shapiro, Ph. D.
IBM T.J. Watson Research Center
Email: shapj@us.ibm.com
Phone: +1 914 784 7085 (Tieline: 863)
Fax: +1 914 784 7595