Re: VCs - zCaps / OCap a Discussion

Adrian Gropper <agropper@healthurl.com> wrote:

>
>> It's easier to understand by starting at the beginning.  Company A
>> creates a service.  It delegates a subset of the methods of the service to
>> company B.  Company B delegates a subset of those permissions to
>> Bob-as-employee.  (The delegation chain can be longer.)  Bob-as-employee
>> then makes a request of the service.  The policy decision point doesn't
>> have to know anything about Bob, as-employee or otherwise.  It just
>> verifies that the request and the delegations were signed by the correct
>> private keys and that each delegation is a (proper) subset of the
>> delegator's permissions.
>>
>
>
>    - *Company A creates a service with Alice as Subject. Company B is not
>    yet in the picture.*
>    -
> *The Subject controls all permissions. Is A a delegate of the Subject or
>    is the Subject the delegate. I'm assuming the Subject is the delegate and
>    has all of the relevant capabilities. *
>
> Someone is the "owner" of the service.  That person typically delegates
all external API permissions to someone in the company who is responsible
for managing the company's services, keeping the management permissions for
the owner.  In your example, Alice is acting as the owner and is the
Subject.

>
>    -
>    -
> *The Subject sets up a policy decision point (PDP) as an authorization
>    server that can process requests by others such as B. *
>    - *The PDP does not know or care about Bob as an individual. The
>    policy only considers Company B as an issuer of a VC to employee Bob.*
>
> Not even that.  The PDP only cares that the delegations along the chain
are properly signed and that the permissions are properly subsetted.
Company A never needs to know anything about Bob, except perhaps an opaque
identifier meaningful only to Company B.

>
>    - *When Company A introspects a capability with the PDP, the PDP has
>    to follow the delegation chain all the way back to the capability it issued
>    to employee Bob.*
>
> Actually, it works the other way.  The PDP looks at the request, the one
signed by Bob-as-employee of Company B and verifies that it was signed with
the private key corresponding to the outermost certificate in the
delegation chain.  It then verifies that the request is included in the
list of permission.  The PDP then looks at the next certificate, verifies
that it was signed by the private key corresponding to that certificate.
It then verifies that the delegator has all the delegated permissions.  The
PDP keeps peeling the onion until it gets to the innermost certificate,
which was signed with a private key known to the owner.


> *How am I doing?*
>

Really close.

>
>> The delegation chain can provide blind enforcement.  When company A
>> delegates to company B, it includes in the certificate an opaque identifier
>> that only it knows refers to company B.  Company B does the same when
>> delegating to Bob-as-employee.  If someone on the delegation chain does
>> something bad, the direct delegator will be able to identify the culprit.
>>
>
> *I'm confused. Company A never delegated to company B. It delegated to the
> Subject that controls a PDP. How do we enable an audit of activity by
> Company A?*
>

The owner of the service delegated to Company A.  Company A delegated to
Company B, which delegated to Bob-as-employee.  The PDP isn't in
the delegation chain; it only verifies the signatures and permission
subsetting.  That's actually a good thing.  The PDP has no need to invoke
the service, so it shouldn't have that permission.

Section 4 of the Zebra Copy
<https://www.hpl.hp.com/techreports/2007/HPL-2007-105.html> paper walks
through the scenario in some detail.

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

>