[cap-talk] In Defense of Identities - not, who?

[Jed at Webstart]

At 08:46 AM 12/6/2006, Jonathan S. Shapiro wrote:
>Okay, let me try to tease apart some of the problems in this, because I
>am worried that we are having divergent discussions.
>
>To be clear: I'm not necessarily arguing for identities per se as a
>basis of authorization (though they are needed as a basis for logging).

Ah - terrific.  I was beginning to wonder.

>What's really going on is that I'm challenging the viability of the
>membrane pattern in an OS-based implementation.

Legitimate.  Challenge on what basis?  Useful/needed functionality
or performance or ...?

>First, let me address something Jed said:
>
>   Suppose that in addition to the above whenever a permission
>   was delegated (either by being given or by being taken from
>   a global post) it was labeled as to who it came from and who
>   received it.
>
>I just want to note in passing that the entire notion of "who" is very
>problematic. Do we mean by this the user, or do we mean a more general
>notion of stakeholder? Often, when people resort to "who", they are
>engaged in the tacit assumption that programs act on behalf of their
>users (perhaps not voluntarily, but still).

I think likely the easiest way to understand what I mean by "who" (and
by extension what we mean by "identity" in this discussion) is anything
one could imagine having a public key pair.  It can really be any
subject (since any subject could have a key), but it can also be
represented in an object-capability (as MarkM rose to the challenge
on) paradigm.

As I've mentioned before (and was raised in the HP meeting, so
maybe it has enough metaphorical value that I'll try again), I often like
to use the example of identifying extra terrestrial entities that
we can never come into physical contact with.  "They" can send
us public keys.  We can communicate on the basis of those
keys and develop trust relationships.  For all we know there may
be one entity sending out many keys or they may have some complex
blob structure that the keys come out of.  From our perspective that
isn't really important.  We can't distinguish between that possibility
and the possibility that they are just in close collaboration.  It really
doesn't make any difference to us.  We have the keys that are identities
and we can establish trust relationships with them.  That's all we can do.

>So we have a very fundamental definitional problem concerning the word
>"who".

Perhaps because I've previously and recently (e.g. at HP) spent so
much time working that who/identity concept in the object-capability
context I don't find it particularly problematic.

>Okay. Back to membranes.
>
>Membranes are a very attractive pattern and idiom, but they flatly don't
>work as an operating system tool.

I think it will indeed be unfortunate if that's the case.  It will even
poke a hole in my identity tracking approach, so I certainly want
to get to the bottom of these issues.

>There are several problems:
>
>   1. In the presence of a trusted service you don't need them.

What do you mean by a "trusted service"?  One example I've
raised is for delegation of permissions between people as we've
been discussing with responsibility tracking.  Where is the
needed "trusted service" in that case.  I think I'm not following
your thinking at a fairly high level.

>   2. In the absence of a trusted service you can't build them,
>      because you cannot reliably obtain the object protocol.
>   3. In the absence of a trusted service, it is exceptionally
>      difficult to get transitivity of revocation right. The simple
>      cases are simple and the hard cases are impossible. Consider:
>
>         c1->someOperation(...arg...) => c2
>
>      the decision to wrap the 'c2' capability depends a great deal
>      on what 'someOperation' does.

I think until I get a better understanding of the higher level
terminology you are using I won't be able to interpret the
above.  Sorry.

>   4. There are also issues of capability identity preservation.

Whew.  The above is really confusing to me.   What do you mean
by "identity" in the above context?  Are you referring to subject
identity (as we've been discussing recently) or do you really
mean an object designation?

>Some of these (notable exception of 3) are more easily and efficiently
>resolved in a language context. In an operating system context,
>performance considerations strongly motivate implementing membrane-like
>logic within the kernel. Unfortunately, there isn't an efficent way to
>record capability interdependencies (and in any case issue 3 makes it
>unclear what to record).
>
>In addition, the introduction of membranes has to be done by a
>surprising number of parties in context-sensitive ways. This introduces
>several issues:
>
>   1. It increases the set of objects on which we must rely.
>   2. The context sensitivity of membrane introduction makes it very
>      very easy to get it wrong.
>   3. In the absence of a centralized implementation, it is unlikely that
>      membrane enforcement will be consistently implemented.

I'm not sure (pending the above), but I think I might be getting a hint of
what you're getting at.  Are you basically saying that implementing a
"membrane" can involving recognizing just when it is a permission
that requires wrapping that's being communicated?

IF so (really a big IF, but I proceed) then I think I agree with
your concern.  Let me just see if I've picked up the essence
of your concern by describing what I'm picking up in other terms.
This takes us way back to some earlier discussions on the list.

If a request on a capability (to exercise a permission) finds it's
way to a membrane server, the membrane server will make the
request on the underlying capability and then receive any reply.
That reply may contain permissions.  If so and the membrane
service is to do it's job then

--Jed http://www.webstart.com/jed/