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

[David Hopwood]

James A. Donald wrote:
> James A. Donald:
>  > 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.

That sounds like an unnecessary impediment to ease of use. An
advantage of capabilities is that they don't require separate
authentication. This property is also essential to their resistance
to confused deputy attacks: when the authentication is separate,
the effect of a deputy using delegated authority may be different
to what the delegator intended.

-- 
David Hopwood <david.hopwood at industrial-designers.co.uk>