Re: VCs - zCaps / OCap a Discussion

Stephen Curran <swcurran@cloudcompass.ca> wrote:

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

I took "whom" in your question to imply identity in the sense of government
ID, name, etc.

An important point is that you can never know who did "it;" you can only
know who to hold responsible for doing "it."  That's certainly true for
bearer tokens used as capabilities.  It's even true when using signed
certificates.  You only have to share the certificate and the private key
needed to use it.  The private key makes it harder to steal the capability,
but it doesn't tell me that it was used by who I gave it to.

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


On Sun, Dec 6, 2020 at 3:50 PM Stephen Curran <swcurran@cloudcompass.ca>
wrote:

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