Re: VCs - zCaps / OCap a Discussion

Stephen Curran <swcurran@cloudcompass.ca> wrote:

>
> For OCAPS, is a simple assertion sufficient to convey the capability for a
> functioning system, or does it matter to whom the capability was given?
>
>
It does not matter to whom the capability was given.  You can (and should)
create a one-off key pair for every capability.  You can include an
identity for audit purposes, but it may not be meaningful to anyone else.
For example, my company may include my employee id in the capability that I
use for another company's service.

The danger of including an identity in the capability is that it will be
used as part of making the access decision, which can lead to a confused
deputy vulnerability.  There are also times when you don't know the
identity of who is getting the capability.  Perhaps it was given in
exchange for money.

>
> I've always assumed that it is important that a capability being used is
> done so by the party to whom the capability was given, or there is a chain
> from a delegate to the initial receiving party.
>
>
You can never know who used the capability, but you can know who to hold
responsible for its use.  The same applies to ACL systems.  The reason is
credential sharing.  In an ACL system, the only way to delegate is to share
your password.  (As dangerous as it is, people do it if that's the only way
they can get their jobs done.)  In a certificate-based capability system,
you can share capability and the private key needed to use it.  That's why
"do not delegate" as appears in SPKI is worse than useless.  You gain no
security, and you lose responsibility tracking.

--------------
Alan Karp

>

Received on Monday, 7 December 2020 16:37:42 UTC