[cap-talk] In Defense of Identities - not

[Jed at Webstart]

At 08:45 AM 12/6/2006, Karp, Alan H wrote:
>Jed wrote:
> >
> > At HP last Friday I mentioned a facility that we had at LLNL many
> > years ago that I considered quite helpful/useful in bootstrapping
> > sharing between people.  It had the following properties (sorry if
> > this is a repeat - I see it as relevant here):
> >
>What Jed goes on to describe is very similar to the Client Utility Name
>Frame mechanism.  Details on request.
> >
> > The features that the above system didn't have that seem
> > to me can provide additional value are responsibility tracking
> > and revocation.
> >
>Client Utility did have both, but responsibility tracking was done by
>auditing in the Core, the component which mediated all interactions.

Perhaps I can understand the Client Utility implementation better as
part of our researching this proposed paper on the responsibility tracking
mechanism.

> > That's the argument that I'm making also and I'm making a
> > concrete suggestion.  Please tell us Jonathan if there's something
> > still missing in the proposed responsibility (with
> > revocation) tracking
> > mechanism that you feel is needed, and if so what else do you feel
> > is needed and why.
>
>The main issue I see is the inability of Alice to delegate to Bob a
>responsibility-tracked capability right to use Carol without involving
>Carol.  I think that's unavoidable.

This seems mostly an implementation issue.  The problem seems a bit
like the one I solved with the public key mechanism for safely
communicating capabilities as data in Managing Domains:

http://www.webstart.com/jed/papers/Managing-Domains/#s13

I'll be interested to see if there is a comparable implementation
approach that uses cryptography and needn't involve the server
when a permission is delegated, even with responsibility tracking.

> > Also I'd like to understand how you imagine an IBAC mechanism
> > to work.  That is, if you don't imagine the identities themselves
> > being able to delegate their permissions, who do you imagine being
> > able to do so?  How do you see that working?
> >
>I don't.  It is my contention that IBAC is unworkable.

There we agree 100%.

>It is only by
>enormous effort that we get it to work at all within a single machine or
>administrative domain.  IBAC doesn't work at all when crossing
>organizational boundaries.

Amen to that.

> > I suppose I should mention that I don't have any problem with using
> > an ACL mechanism to implement permissions that can be delegated
> > (what I call a 'capability', but never mind).  I mentioned in:
> >
> > http://www.webstart.com/jed/papers/Managing-Domains/#s10
> >
> > two such mechanisms (ACL and "encrypted address") that one could
> > call "identity" variations.  Those protocols used ACL mechanisms for
> > their implementation, but the key is that they were used to implement
> > what effectively amount to 'capability' semantics.
>
>This mechanism is very similar to the proposed Client Utility
>introduction protocol.  The only difference is that we kept a c-list
>instead of an ACL.  Details on request.

As long as the semantics of the permission delegation are object-capability
semantics (really just 'good' object oriented programming semantics), then
I believe most of these issues are "implementation details" - though
Jonathan's ACL discussion seems to be more than that and has me concerned.

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