Re: VCs - zCaps / OCap a Discussion

*inline...*

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

> Adrian Gropper <agropper@healthurl.com> wrote:
>
>>
>> *Progress! *
>>
>> Progress indeed.
>
>>
>> On Thu, Dec 10, 2020 at 5:09 PM Alan Karp <alanhkarp@gmail.com> wrote:
>>
>>> Adrian Gropper <agropper@healthurl.com> wrote:
>>>
>>
>
>> 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. *
>>
>
> I still have trouble keeping the GDPR terminology straight.
>
>>
>> *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.*
>>
>>>
>>>> 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.*
>>
>
> Good point.  For simplicity, I usually assume the Data Controller is the
> same entity as the service provider.  Here, both Company A.
>
>>
>> *Yes, the PEP evaluates the policy and prepares the PDP to Allow/Deny a
>> capability introspection if required by the PEP. *
>>
>
*BIG typo on my part. I meant the PAP evaluates policy.*

>
> In the link I sent you, the PDP evaluates the policy and sends Allow/Deny
> to the PEP.
>
>
>> *In many cases, the PEP simply executes the capability because it is
>> deemed authentic without introspection.*
>>
>
> I don't see how that can possibly work.  Even with a bearer token, you
> have to verify that the requested invocation is allowed by the ocap.
> With certificate-based ocaps, at the very least, you need to check
> signatures.  You also get a vulnerability if you don't validate the
> delegation chain.  Company A can give me permission to invoke method X.  I
> can then delegate to you permission to invoke methods X and Y.
>

*This is above my pay grade. All I know is that some tokens don't need
introspection for things like scope or revocation whereas some tokens are
just an opaque handle to be introspected at the PDP. I fancy the result is
the same in terms of privacy but I may be missing a lot when it comes to
validating a delegation chain. I could be wrong about my terminology but
that's the behavior in the use-cases I'm familiar with.*

>
>>
>>>
>>>> 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?*
>>
>
> Since the PEP talks to untrusted clients, you want it to make it as simple
> as possible, which is why most deployments have a separate PDP.   Since
> that's just an implementation detail, we can call it the validator.  That
> word explains what it does without getting into implementation details.  Of
> course, if PEP is the term GDPR uses, we should stick to it.
>

*Here we still have a bit of confusion with terminology. My goal is a
separation of concerns to remove as much of the privacy liability from the
service as possible. Period. I think that goal aligns with GDPR, CCPA,
CPRA, and other regulatory approaches.  *

>
>>
>>>
>>>> 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.  *
>>
>
> The API part of the request has to be visible to the service, of course.
>


*No. The request is never seen by the service (Company A) for privacy
reasons. I don't know what "the API part of the request" means. The PAP has
the policies and and an API to receive requests. *

>
>>
>>>
>>>> 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.*
>>
>
> I guess I'll have to dig into GNAP.  All I know about now I got from
> Justin's oauth.xyz talk.
>

*Nov 17 version: GNAP:
https://datatracker.ietf.org/doc/draft-ietf-gnap-core-protocol/?include_text=1
<https://datatracker.ietf.org/doc/draft-ietf-gnap-core-protocol/?include_text=1>
*

>
>>
>>>> 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.*
>>
>
> So it's only used for Deny?
>

*Yes, pretty much, although "Break the Glass" is another common pattern.
Break-the-glass works if there's an audit mechanism to keep the
authentication-based access honest.*

*Adrian *

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