[cap-talk] ... enforcement - hope? Capabilities as clumsy, not
list at waterken.net
Thu Sep 30 10:18:05 EDT 2004
>>The most accurate way to state the design principle is
>>"An object must not be polymorphic with another object that provides
> I could probably twist dean's arm and get him to rephrase this, "an object
> must not be polymorphic with another object that provides different
> authority". At which point I'd like this definition a lot.
It is perfectly fine for an object to be polymorphic with another object
that provides different authority. If your code mistakenly provides the
wrong object to a caller, your program will malfunction, since the wrong
authority is being provided to the caller. This kind of mistake can be
detected with basic application testing.
The purpose of this design principle is to eliminate the possibility of
*undetected* authority leaks.
> It even seems to
> support my current strategy for dealing with it, i.e., give them different
> guards (actually, give them different stamps, tested with different guards),
> which breaks the polymorphism.
I don't yet understand your current problem. Maybe we should go over it
at our next meeting.
The web-calculus is the union of REST and capability-based security.
More information about the cap-talk