Re: VCs - zCaps / OCap a Discussion

Thanks, Alan, but I think you answered my question with both Yes and No.

Directly, you said it doesn't matter.  But your follow up statement  ("You
can (and should) create a one-off key pair for every capability") implies
to me that you (as the capability issuer/verifier) do want to be sure that
the entity (or delegates) using the capability demonstrate they indeed were
given the capability. I interpret that as answering my question as "yes --
it matters to whom the capability is given".  It doesn't matter the
identity of the person (gov't ID, name, or anything like that), just that
they can demonstrate they have a verifiable chain to the key-pair
associated with the given capability.

On Sun, Dec 6, 2020 at 3:04 PM Alan Karp <alanhkarp@gmail.com> wrote:

> 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
>
>>

-- 

Stephen Curran
Principal, Cloud Compass Computing, Inc. (C3I)
Trustee, Vice Chair - Sovrin Foundation (sovrin.org)

*Schedule a Meeting: **https://calendly.com/swcurran
<https://calendly.com/swcurran>*