[cap-talk] What Horton cannot do? (Was: mailkey: transfer of accountability...)

[James A. Donald]

James A. Donald:
 >> No you would not like to hear, for I have been
 >> expressing my concerns, and you do not appear to have
 >> heard.

Jed Donnelley:
 > It's really difficult for me to know how to respond to
 > a statement like the above.  It seems to me
 > confrontational to no positive (e.g. communication)
 > effect.

Communication is not occurring.  I find I have repeated
myself in different words more times than I can easily
keep track of, and am running out of different ways to
express the same idea, not to mention patience.

 > Let me give a simple example of what Horton is focused
 > on:
 >
 > Let's say we have a capability for setting off a fire
 > alarm.  We believe all occupants of the building
 > should have permission to set off the alarm.  However,
 > we want to know who set off the alarm in case there is
 > a false alarm set off so we can know who to blame. We
 > may choose to revoke that persons capability to set
 > off the fire alarm if they abuse the capability
 > (crying "wolf").
 >
 > In this case every time there is a new occupant of the
 > building we use Horton to delegate them a new instance
 > of the capability to set off the fire alarm with their
 > identity labeled as responsible.
 >
 > [...]

 > I described a real world scenario above in the LLNL
 > "give and take" directory structure.  In that
 > situation we would imagine that capabilities in the
 > home and "receive" directories for people would
 > typically be labeled as the responsibilities of those
 > people. However, one person, Alice, could choose to
 > communicate a capability labeled as her responsibility
 > directly to Bob (not through Horton).  In that case
 > Bob's invocations would be logged as the
 > responsibility of Alice.  Bob would not (we hope)
 > receive access to Alice's "Be Alice" capability
 > (essentially her private key) and so couldn't act for
 > Alice in general, but Bob could invoke the capability
 > that Alice communicated directly with the "Alice is
 > responsible" label.  Bob may also have capabilities
 > labeled as "Alice delegated to Bob".

In the example you gave, there is no sensible reason for
Alice to delegate to Bob, through the Horton mechanism
or otherwise  But let us suppose there is some sensible
reason.

Now if Alice and Bob both have private keys, whose
corresponding public keys are recognized by the entity
that issues capabilities to activate the fire alarm,
which is necessary if Alice is to pass the capability
through the Horton mechanism, then we could just as
easily pass the capability directly, not through the
horton mechanism, and require the use of the capability
to be signed by a private key.

 > The distinction between active objects (processes,
 > e.g. deputies) and identities is vital to the
 > scenarios where we imagine Horton to be useful. People
 > will likely have identities and some few active
 > objects may act with the full authority of people
 > (have their private keys), but most active objects
 > will only act with some number of permissions
 > (capabilities) that may be labeled as the
 > responsibilities of zero, one, or more people.

So Bob gives the active object the capability signed
with his private key, rather than giving the active
object his private key.

A more realistic solution would be that Bob somehow
logged in, perhaps by means of his private key through a
mechanism akin to OTR (no signing involved), and got a
cookie, and the alarm needs both an ID cookie and a
capability - it being fairly standard for cookies,
though not private keys, to be passed around liberally.

An ID cookie may be thought of as the capability to
attribute an action to account, so that the action may
be billed, or applied to the reputation of an entity -
since capabilities are commonly implemented as shared
secrets, whereas identities may well be private public
key pairs - thus an ID cookie is more like a capability
than it is like an identity.

James A. Donald:
 > > > > "who" contains too many meanings.  Identity is
 > > > > not a clear well defined concept with clear well
 > > > > defined  meanings and definite unambiguous
 > > > > solutions.  If each key is unique, as is
 > > > > typically the case with electronic keys used in
 > > > > office security systems, then the owner of a key
 > > > > will be disinclined to share it, whereupon
 > > > > knowing what key opened the lock is in fact
 > > > > sufficient information.

Jed Donnelley:
 > > > You lost me with the above.  Sufficient for what?
 > > > Sufficient to attribute responsibility to an
 > > > identity? How?

James A. Donald:
 > > Think about it.  Seems perfectly clear to me.

Jed Donnelley:
 > Such is always the case when listening to oneself. In
 > future I'm going to simply delete such insults with no
 > communication content.

It was not intended as an insult.  I believe you do not
want to hear what I say, rather than that what I say is
unclear or difficult to understand.

 > I'm trying to be polite in responding.

Politeness would require making a reasonable effort to
understand, or, if failing to understand, recognizing
the fact and assisting the other to clarify.