Re: VCs - zCaps / OCap a Discussion

*Progress! *

*Inline...*

On Thu, Dec 10, 2020 at 5:09 PM Alan Karp <alanhkarp@gmail.com> wrote:

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


*No worries. I always presume the perspective of the data subject or DID
controller and the near-universal GDPR terminology of Data Processor and
Data Controller because that introduces the regulatory issues. Much of the
jargon predates human-centricity, zero-trust architectures, and
self-sovereign anything. *

*Here, I'm trying to stay as close as I can to SSI intent while bringing in
the most common of real-world use cases, like writing a prescription.*

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


*Yes, the PEP stands between the Client and the Service (Company A). *

*No, Company A does not see a request because that violates data
minimization principles. Company A MUST redirect a Client or user agent to
the PDP + PEP combo so the request can be evaluated against policy that is
private to the Data Controller.*

*Yes, the PEP evaluates the policy and prepares the PDP to Allow/Deny a
capability introspection if required by the PEP. In many cases, the PEP
simply executes the capability because it is deemed authentic without
introspection.*

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

*Sorry. I think we're getting to a shared understanding. My interest, and
the GDPR framing, is to allocate the security risk to Company A and the
privacy risk to the entity that has the policy and can therefore process
the request. If we all agree to use PEP for the entity that is the Data
Controller then I can drop the PDP term. Does anyone care?*

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

*See above. I'm not proposing that the request be visible anywhere other
than the entity that holds the policy. Call the entities involved in any
decisions whatever you prefer. The PEP is clear as protecting the Data
Processor.  *

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

*This is the beauty of GNAP and why I think it fits nicely with a
capabilities-based, GDPR resonant, and zero-trust architecture.*

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

*Even in a world where the Data Processor is denied much controller
privilege, they still have some claims on control in the name of security
or legal mandates. It is typical for these processors to need the
opportunity to raise exceptions if they don't like the smell of the Client
and capabilities combo.*

*Adrian*

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