Re: VCs - zCaps / OCap a Discussion

*inline...*

On Wed, Dec 9, 2020 at 5:08 PM Alan Karp <alanhkarp@gmail.com> wrote:

> Adrian Gropper <agropper@healthurl.com> wrote:
>
> A request for an authorization token could be encoded as a VC presented to
>> a controller service endpoint but I'm not sure that makes sense. The
>> Subject of the request is the requesting party but they are acting on
>> behalf of some employer. Alan makes this distinction quite clear as we
>> discuss revocation of Bob's capabilities.
>>
>
>> As for the Subject of the authorization token issued by the controller
>> service, it sounds like we want that Subject to be Bob's employer rather
>> than Bob himself.
>>
>
> 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. *
   -
*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.*
   - *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.*

*How am I doing?*

>
> Our Zebra Copy <https://www.hpl.hp.com/techreports/2007/HPL-2007-105.html> paper
> has more detail.  (Don't be put off by the length.  The last 60 pages are a
> walkthrough of the code.)
>
>
>> The authorization token is presented to a policy enforcement point that
>> may choose to 'introspect' the token or not.
>>
>
> My understanding is that the PEP never looks at the request.  It just
> forwards the request to the PDP (policy decision point) and gets back an
> Allow/Deny decision.
>

*Yes. It would be a privacy violation for the PEP to know anything more
than the scope associated with the request and the encryption key or the
THS endpoint associated with Bob's client. It's just data minimization.*

>
>
>> This has a direct impact on both revocation and audit. In a Zero Trust
>> Architecture, it is desirable to provide a confidential audit capability
>> for activity at the policy enforcement point that is separate from the
>> audit capability at the policy decision point. How do we do that while
>> keeping the policy enforcement point blind to the requesting party and
>> purpose components of the initial request?
>>
>
> 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?*

*Adrian *

>
> --------------
> Alan Karp
>
>>