[cap-talk] Declaring a victory

[Jed Donnelley]

----- Original Message -----
From: Norman Hardy <norm at cap-lore.com>
Date: Sunday, August 12, 2007 4:46 pm
Subject: Re: [cap-talk] Declaring a victory
To: jed at nersc.gov, "General discussions concerning capability systems." <cap-talk at mail.eros-os.org>

...
> My stuff below is vague; I am not sure I am asking precise questions.
> 
> At which level is the distinction made between between principals?

The short answer of course is wherever we want to.  A very important
case is that of people as principles (I'll get to your nuances below).
However, roles can also be 'principles' (the term people seem to
prefer in this thread) such as 'executive secretary' or CFO or ...
I can't think of any reasonably effective uses for such a 'principle'
that corresponds to what amounts to a programming construct,
because of course doing so seems to me likely to get in the
way of composing those programming constructs.

> If principal X is using code written by Y to accomplish the charter 
> of X, who is the principal?

For what purpose?

> If X invokes a properly confined object that obeys code by Y, is 
> that  delegation?

I don't consider who code is written by as relevant to the use
of principles for responsibility tracking (e.g. Horton).  Even the
question of 'who' wrote code, let alone who reviewed it, etc.
seems vague to me.  We want to trust code as little as possible
(POLA) because there may be bugs, trojan horses, etc. that
escaped review, etc., but I don't see the relevance of the 'principle'
notion (labeled responsibility for actions enabled by capabilities)
as being useful for labeling code.

> It seems as we are sliding back to the assumption that all of the  
> code that a principle X uses does just what X wants it to do.

Definitely not.

> Sometimes we say that X relies on all of the code that X invokes.
> A capability platform is so that X can correctly rely in code Z 
> while  
> knowing less about Z than if the platform were conventional.
> This influences the concept of "rely upon"; it is relative to the  
> platform we assume.

I don't see something like Horton as being useful for dealing
with who is responsible for code.  Where I see Horton as
useful is when dealing with explicit delegation of responsibility
between higher level "principles".  For me the most generic
Horton mechanism is an email-like facility where we agree
(because we set things up that way with a Horton 'tunnel')
that what you send to me I become responsible for and
what I send to you, you become responsible for (namely
for actions enabled by the communicated capability).

With that as a base we can send other things across like
Wideword sorts of Web documents.  That is why I'm pushing
on the deep attenuation mechanism (I accept that terminology)
now, because I think it is important to provide such deep
attenuation for such documents.  I also think that Horton
responsibility labeling is important for such documents
(with other VOC policies such as "don't delegate" or
"delegate only within a group", etc. as desired).  At the
level of  'principle' responsibility transformations I don't
believe most performance issues are very important.
The one that still concerns me some is that the server
for an object (e.g. Carol as per Horton) must be up
and available for Alice to delegate a capability to Bob.
Given what Horton can do, getting around this seems
rather difficult, but I still consider this goal worthwhile.

> I think the magic of Horton is being able to say (and mean) to  
> another agency:
>    Do your magic on this here thing, (but I will have a record of  
> what it is that you have done.)

I agree, though I might word it a bit differently.  From my perspective
Horton allows us to inject any policy we wish at points where there
is an explicit delegation of responsibility from one "principle" to
another.  We can choose to simply log it, we can later revoke
such a delegation, we can put in policies like "don't delegate"
or "don't delegate outside this group", etc.

The way the delegation becomes explicit is that the capability
being delegated passes through a Horton responsibility
transforming tunnel (as described in the paper and further
clarified in the presentation - did you post those graphics
yet MarkM?).

> In short I am not sure what we are discussing in this thread.

I hope the above clarified what I at least believe we are discussing.
It seems abundantly clear to me, so if it still isn't to you, please
ask again until we achieve greater shared clarity.

--JED  http://www.nersc.gov/~jed/