Re: VCs - zCaps / OCap a Discussion

I have no idea what

“ The PEP may know that the token is valid, perhaps because it has cached
the validation result, but it doesn't know if the request is included in
the permissions specified in the token.”

means. I try to use ‘request’ consistently to refer to interaction at the
PDP. I use ‘token’ in relation to the capability presented by a ‘client’ to
Company A as the PEP.

- Adrian


On Wed, Dec 16, 2020 at 1:07 PM Alan Karp <alanhkarp@gmail.com> wrote:

> Adrian Gropper <agropper@healthurl.com> wrote:
>
>> *just sent to me, so replying in private...*
>>
>
> Aaarrrggghhh!!! I hereby give you permission to forward my response to the
> group if (when) I to this again.
>
>>
>>
>> On Sun, Dec 13, 2020 at 6:53 PM Alan Karp <alanhkarp@gmail.com> wrote:
>>
>>> Adrian Gropper <agropper@healthurl.com> wrote:
>>>
>>>>
>>>> Even if you know the capability has been validated, you still have to
>>> verify that the request is consistent with it.  What if you asked to write
>>> with a read-only capability?
>>>
>>
>> *I'm really confused by this. A token presented to the PEP can either be
>> self-authenticating (like a VC signed by a key that was pre-registered by
>> the PDP that represents the resource owner). The other alternative is that
>> the token presented to the PEP is an opaque handle that is presented by the
>> PEP to a pre-registered PDP. The PDP returns a scope of access. How else
>> can this work?*
>>
>
> The request presented to the PEP consists of two pieces, the access token
> and the request you are making of the service.  This combination is signed
> by the private key corresponding to the public key in the access token.
> The PEP may know that the token is valid, perhaps because it has cached the
> validation result, but it doesn't know if the request is included in the
> permissions specified in the token.
>
>>
>>> One of the nice things is the privacy ocaps can provide.  You may need
>>> some personal information to decide to grant a capability, but the
>>> capability need not contain any of it.
>>>
>>
>> *Exactly. That's why I'm a fan of ocaps. We seem to be having trouble
>> linking them to the real-world use case of health information access and
>> DIDs. *
>>
>
> Let's work through a use case
>
>>
>>> There must be a disconnect.   You invoke a service to read a particular
>>> file.  Clearly, the service needs to see that, what I'm calling the API
>>> part of the request.
>>>
>>
>> *Me too. But the API is only one _part_  of the request. The other two
>> are requesting party credentials and the purpose of the request. These
>> other two parts should not be shared with the service (Company A).*
>>
>
> I agree.  The nice thing about ocaps is that Company A can validate the
> request while learning nothing about the requester.
>
> --------------
> Alan Karp
>
>>