Re: VCs - zCaps / OCap a Discussion

Sorry, but "the ocap way" is not helpful as an explanation in the health
care use-cases that I'm aware of.

Figure 5 applies because I think I'm proposing the Authorization-Based
Access control with the Service as Company A and PEP and the Policy
Database as the PDP controlled by the Subject. Arrow 1 could be either
Alice (the Subject) or Bob presenting some claims along with other
components of the 'Request'. GNAP
<https://datatracker.ietf.org/doc/draft-ietf-gnap-core-protocol/?include_text=1>
is actually the protocol we use because it wisely tries to treat the Client
in Figure 5 as being the user agent for either Alice or Bob.

The left side of Figure 5 is a privacy violation that shares too much
Request information with the Service.

You have added to my confusion by introducing the PAP as separate from the
PDP. From Alice's perspective the PAP and PDP are both under her control so
who cares?

To be fair, in the real-world health care use case, the Service (Company A)
is never happy about not knowing more about the request including:

   - Who is Bob?
   - Does the Client have a signed software statement?
   - Who signed the Client software statement?
   - Who do I (Company A) notify if I decide to ignore some or all of the
   authorization capability for whatever reason?
   - etc...

Services like Company A think they have a right to operate their own PDP
that can process these issues. This is part of the confusion around who is
delegating to whom when Alice decides to have a PDP - PEP relationship with
Company A. I see the issue of whether Company A also gets to choose a PDP
as irrelevant. All Alice cares about is her ability to specify a PDP to
Company A.

Still confused,
- Adrian



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

> Adrian Gropper <agropper@healthurl.com> wrote:
>
>>
>> *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.
>>>
>>
>>
>> *Still confused. In the real world, Company A never delegates to Company
>> B. Company A just operates a PEP. *
>>
>
> That's not the ocap way.
>
> How does the PEP know that Bob-as-employee of Company B has permission to
> use the service?  It will ask the PDP which will check with the policy
> access point (PAP).  What information will the PAP use to make the decision?
>
>>
>> *The question of whether Company A delegates to the PDP or the Subject
>> delegates to Company A seems talmudic but maybe it's important to resolving
>> my confusion.*
>>
>
> You're right.  It is an important point.  I think I see part of the
> confusion.  Who decides if an employee of Company B gets permission to use
> the service?  In a conventional setup, the PDP talks to a PAP to decide if
> a particular request matches the access policy, usually based on some
> authentication presented by the requester.  In an ocap system, the PAP is
> what decides whether to hand out an ocap, and the PDP merely verifies the
> delegation chain when a request comes in.  Figure 5 of
> https://www.hpl.hp.com/techreports/2008/HPL-2008-204R1.pdf shows the
> difference.  (I have a talk on this that I gave at RSA a number of years
> ago.)
>
> Imagine we're talking about your car.  You delegate permission to use the
> car by giving me the keys, perhaps because I presented a VC that I'm
> licensed to drive.  The ignition lock is the PEP, and the pins in the lock
> are the PDP.  I delegate to my son by giving him the valet key.  (I don't
> trust him not to go poking around in your glove box.)  The PEP isn't in the
> delegation chain, nor does it know anything about the users of the key.
> All it cares about is that the key moves the pins into the correct
> position.  That's the ocap way.
>
>>
>> *I agree with you that the PDP has no need to invoke the service so it
>> shouldn't have that permission but in the real world, the PDP can collude
>> with a service provider B out-of band and Company A would have no idea of
>> the collusion.*
>>
>
> True, but at least you can't trick the PDP into delegating a capability to
> the service to you :)
>
>>
>> *Adrian*
>>
>
> --------------
> Alan Karp
>