[cap-talk] Another "core" principle - Brinkmann

[Marcus Brinkmann]

Hi Jed,

At Sat, 23 Dec 2006 00:21:12 -0800,
Jed Donnelley <capability at webstart.com> wrote:
> 
> At 08:32 PM 12/22/2006, Marcus Brinkmann wrote:
> >Hi,
> >
> >I think I see now what you want to achieve.  I think you can achieve
> >all of this in a pure capability model, assuming revocable delegation
> >(without any identity tracking) and a MyCap? operation.  No extension
> >to the capability model seems to be necessary.
> 
> I want to make clear that I never suggested any extension to the
> pure object-capability model.  I've stated this many times during this
> discussion.

Now that little bit of information sets me straight! :)

For me it was never a question that capabilities could be used to
implement ACL systems or even hybrids.  I got side-tracked when
identity tracking got mixed up with the membrane discussion, where we
were indeed talking about the properties of the capability model and
how delegation works at a low-level.

> >Here is a very rough sketch of what needs to happen, I can expand on 
> >this if necessary,
> >although it seems rather standard to me.
> 
> I agree that it is "rather standard".  You are describing nearly
> exactly what I've tried to describe several times during this
> discussion.  The power of email ;-).  If others like this
> description better or see what appear to be any substantive
> difference, I'd like to hear about it/them.
> 
> Perhaps I can ask again for any thoughts pro or con on the
> basic model and the value (or not) that it provides.

I am really happy I finally got to understand you now.  Let me raise a
couple of points.

* I like that people can communicate with each other in ways other
  than revocable delegation.  It seems to me that this is a critical
  feature in any real life system.  As Jonathan pointed out, revocable
  delegation only means one can get into a situation were revocation
  is impossible.

* My personal model of capabilities is stricter than yours.  For
  example, I only allow capability delegation through authorized
  channels, which exists in form of capabilities of course.  So,
  whenever a capability is communicated from A to B, I need a
  capability that is used for that.  Even if you think about
  capability transfer in form of copying binary blobs of data I think
  that this is a useful restriction to apply, because it makes
  communication explicit.  This explains the "emergency capability"
  which I introduced:
 
> One aspect of things that's different in your discussion
> is the "emergency capability" that you suggest that Carol keep (get
> somehow?) to the server.  I don't see a need for such a capability if
> we're assuming that the subjects are people.  In that case Carol
> can call or email Alice (or R) and ask that her capabilities delegated
> through Bob be restored.  Alice (or R) must make a policy decision,
> based on other information (e.g. an independent introduction to
> Carol) and choose to either request the bypass or not.  I believe
> Alice can do her bypass call simply on P_A, or what I've referred
> to as the capability labeled R->A.  Your introduction of P
> might suggest syntax like P:R->A.

  I agree tentatively, but note that you are weakening the mechanism
  by this.  By designating P:R->A->B, Alice does not need to know or
  confirm if Bob delegated access to Carol: If he did, Carol will now
  have access, if he didn't, Carol won't.  If you want to make Alice a
  new decision, completely independent of Bob, then what you described
  works.  But in this case, see below for my description of "groups"
  for a possible alternative.

  I also have squirms with the terminology.  Bypass would in that case
  clearly be the wrong term, it's simply a new capability delegation
  then, and the capability should not be returned by the server to
  Carol, but by Alice to Carol directly.  I like this variant as well.

  Note that in this case Carol needs a communication channel to Alice,
  in addition to one to S.  See above for why that translates into a
  capability for me.  For you, this may not translate into a
  capability, but clearly Alice needs some way to verify who this
  Carol person is, so there is another framework (public key
  management?) which subsumes this requirement in some form or
  another.

* I agree with the following critique, but I can refine it:

> One other thing that I want to make clear that I think is important
> (and as I recall shows up in the Horton protocol) is that the
> capability exchange must (for responsibility tracking) be such
> that (at least initially) only Carol possesses what you refer to
> as P_C and I label R->A->B->C.  None of R or A or B can have access
> to this capability unless explicitly communicated from Carol.  This
> is the aspect of things that can assure responsibility for logged
> actions - non repudiation.

  What matters here is how identities work.  If the "Carol" name is
  created by Bob, and thus Bob is the introducer, it doesn't seem to
  matter that Bob has the capabilities bound to "Carol".  Clearly
  there are situations where this is not desirable, and we want to
  have some other authority than A, B or C who provides a naming
  service for identities.  In particular if we talk about People(tm),
  but I think the mechanism described is more general than that.

  In this case, yes, the protocol that does capability delegation from
  B to C is more complicated, involves the authenticating identity
  service, and in the process replaces the initial P:A->B->C
  capability hold by Bob with a new, authenticated capability
  P':A->B->C that is closely held by Carol.

  There are many ways one can refine the protocol in this way, and
  some of these ways may avoid the creation of the intermediate
  capability P:A->B->C by Bob.  Nothing to get hung about, unless it
  matters for some other detail (like resource management, whatever).

* Let me conclude:

> Given the above, do you see value in a mechanism like that?

  I definitely do.  What I am less sure about is if that much is even
  required, or if there aren't simpler models that work well in
  practice.

  Let me get back to the notion of a "group".  My theory is that you
  will never want to apply the mechanism you described on capabilities
  at the individual object level.  If there are hundreds of objects,
  we don't want Alice to make one hundred decisions if to bypass or
  not.  Thus, we will probably limit this to capabiities representing
  a collection of capabilities, say a directory.  In my model, there
  is a principal, let's say Alice, who is the arbiter on the
  capabilities in this directory.  I call the directory a "group",
  Alice the "group leader".  Note that if you want the group to
  survive a revocation of Alice's identity, the group needs to have an
  identity itself and there need to be two types of access to the
  group: One for the group leaders and one for the group.  That's just
  more details, so let's go on with the revocation example.

  Now the scenario is described like this: Bob gives a membrane for
  the group capability to Carol.  Bob's identity is revoked.  Carol is
  out of luck, and needs to apply to Alice to get access to the group.

  If we look at it this way, do we really need elaborate mechanisms to
  do this?  If you remove the "P:A->B" capability from the Bypass
  operation, and not even make it a Bypass, then what remains is the
  following:

  Carol has some idea of what group it has access to and who the group
  leader is.

  Carol loses access, and then emails the group leader to regain
  access to the group.

  Alice gives Carol access to the group, completely ignoring what Bob
  did or didn't.

  If that's all you want, I think there are probably simpler solutions
  available, like a canonical way to get the information from the
  group before Carol loses access, and storing it in a Carol-local
  database.

  That's not the only way it can work out.  If you want Alice to only
  confirm or deny Bob's delegation to Carol, rather than establishing
  a completely new delegation, then you will want Alice to name the
  original delegation to Bob in the Bypass operation, and strictly
  more support is required than in the group model I just described.

At this point we are talking about details where I no longer know what
exactly you want to achieve, so I better stop.  I agree with you that
we are on the same double-page of a largish book.  If somebody shuts
the book now, we will be squished together. :)

Thanks,
Marcus