Re: VCs - zCaps / OCap a Discussion

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

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.

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

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

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

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

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

>