Re: VCs - zCaps / OCap a Discussion

Adrian Gropper <agropper@healthurl.com> wrote:

> Privately, since you did not include the list.
>

Sorry.  The lists I most often use automatically send to the list when you
Reply.  I'll have to train myself to Reply All.  I've left the original
message following this reply.

>
> I'm completely baffled by your explanation. You use PAP as if I knew what
> you're talking about.
>

Sorry.  You used the terms PEP and PDP, which I learned the same time I
learned of PAP.  I thought they naturally go together.  A good description
is at https://ldapwiki.com/wiki/Policy%20Based%20Management%20System.
Basically, the PAP manages access authorization policies.

>
> Here are the actors in the use-case example.
> Company A - a service that is willing to delegate control to a data
> subject named Alice (not an employee of anyone)
> Company A PEP - the place where a Client's capability is enforced. The PEP
> does not see the request.
>

In the systems I know, the PEP stands between the client and the service.
When a request comes in, the PEP forwards the request to the PDP.  The PDP
evaluates the policy provided by the PAP and returns an Allow/Deny decision
to the PEP.


> PDP - A service controlled by Alice as data subject. This service is not
> controlled by anyone else. It represents Alice's persona or identity to
> everyone else.
>

That's a very different definition of a Policy Decision Point (PDP) than
I've been using.


> A Request endpoint at the PDP where an input (from Bob and some user agent
> of Bob's) is evaluated against Policy to return an authorization to Bob's
> user agent.
>

That's the way it works in an ocap system.  In a conventional
authentication-based system, the PDP directly sends an Allow/Deny response
to the PEP instead of returning an authorization.


> A Client - that may be operated by either Alice or Bob or Charlie that
> presents a capability to the Company A PEP.
>

That's my definition.

>
> The Client software statement is an _optional_ certificate that may be
> presented to the PEP.
>

How is the software statement used?

>
> Adrian
>

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

>
> On Thu, Dec 10, 2020 at 1:08 PM Alan Karp <alanhkarp@gmail.com> wrote:
>
>> Adrian Gropper <agropper@healthurl.com> wrote:
>>
>>
>>> Sorry, but "the ocap way" is not helpful as an explanation in the health
>>> care use-cases that I'm aware of.
>>>
>>
>> It might help me if you can walk through a specific use case.
>>
>>>
>>> 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.
>>>
>>
>> Alice, as the owner of the service, gets ocaps to use the service as part
>> of creating it.  Bob, the user of the service, must convince Alice to give
>> him a subset of those ocaps.  He can do that by presenting some VCs to the
>> PAP, the policy database in the right half of the picture.
>>
>>>
>>> The left side of Figure 5 is a privacy violation that shares too much
>>> Request information with the Service.
>>>
>>
>> I agree.  That's one of the things the US Navy liked about our ocap
>> solution.
>>
>>>
>>> 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?
>>>
>>
>> The distinction isn't important in authentication-based schemes, because
>> the policy is evaluated at the time of the request (left side of the
>> figure).  With ocaps, the policy is evaluated before the request is made
>> (right side).  The distinction is useful because the PAP issues the ocaps,
>> and the PDP verifies them, which does not involve checking the policy again.
>>
>> 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:
>>>
>>
>> There is no reason the decision to hand out ocaps can't require
>> additional information.
>>
>>>
>>>    - Who is Bob?
>>>    - Does the Client have a signed software statement?
>>>    - Who signed the Client software statement?
>>>
>>> What's a client software statement?
>>
>>
>>>
>>>    - Who do I (Company A) notify if I decide to ignore some or all of
>>>    the authorization capability for whatever reason?
>>>
>>> You can revoke the ocaps.  Any use of them should return an error
>> message to the client.
>>
>>>
>>>    - 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.
>>>
>>
>> Say that Alice delegated to Company A who delegated to Company B who
>> delegated to Bob.  Bob's request goes directly to the PEP specified in the
>> ocap.  That PEP will use any PDP that Alice trusts to correctly verify
>> ocaps, which could be Company A's if Alice is an employee.
>>
>>>
>>> Still confused,
>>> - Adrian
>>>
>>