Re: Funded Deployments of Verifiable Credentials - framework for meta-credentials

On Sun, Sep 11, 2022 at 6:51 AM David Chadwick <d.w.chadwick@truetrust.co.uk>
wrote:

> your argument is inconsistent. First you say the  PEP (which makes the
> access request to the PDP) is never a confused deputy, then you say the
> deputy (which makes the access request to the PDP) has the potential to be
> a confused deputy. Which is it please?
>
Did I say the deputy makes the access request to the PDP?  That's a typo
on my part.  Let me try again.

The user makes a request of the deputy who invokes the resource.  The PEP
intercepts the request made by the deputy, forwards it to the PDP for
inspection, and uses the PDP response to decide whether to forward the
request to the resource server.  Note that the PEP doesn't need, nor does
it have, permission to use any of the resources specified in the request.
Hence, the PEP can never be a confused deputy.

> Second the PEP is a trusted component of the resource infrastructure and
> therefore would never make "any" request to the PDP. It will only ever make
> the request that the VC Holder is making (barring a bug in the
> implementation). This is the beauty of the claim based infrastructure, the
> VC holder decides the designation to make, whilst the resource holder
> decides which designations are allowed and which are not, thereby greatly
> increasing the flexibility of the system.
>
Resulting in a separation of designation from authorization.

> Whilst I appreciate the difference between a claims based VC and
> capability based VC, there is no possibility of a confused deputy in either
> case (given an un-buggy implementation).
>
 You can have a confused deputy any time you separate designation from
authorization.

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


On Sun, Sep 11, 2022 at 6:51 AM David Chadwick <d.w.chadwick@truetrust.co.uk>
wrote:

> Alan
>
> your argument is inconsistent. First you say the  PEP (which makes the
> access request to the PDP) is never a confused deputy, then you say the
> deputy (which makes the access request to the PDP) has the potential to be
> a confused deputy. Which is it please?
>
> Second the PEP is a trusted component of the resource infrastructure and
> therefore would never make "any" request to the PDP. It will only ever make
> the request that the VC Holder is making (barring a bug in the
> implementation). This is the beauty of the claim based infrastructure, the
> VC holder decides the designation to make, whilst the resource holder
> decides which designations are allowed and which are not, thereby greatly
> increasing the flexibility of the system.
>
> Whilst I appreciate the difference between a claims based VC and
> capability based VC, there is no possibility of a confused deputy in either
> case (given an un-buggy implementation).
>
> Kind regards
>
> David
> On 10/09/2022 23:36, Alan Karp wrote:
>
> On Sat, Sep 10, 2022 at 2:30 AM David Chadwick <
> d.w.chadwick@truetrust.co.uk> wrote:
>
>> I think the model works perfectly well for both capability and claims
>> based VCs. The gatekeeper/PEP blocks the user's access, passes the user's
>> VCs (of either type) to the appropriate PDP (clearly there will be
>> different policies for capability based and claims based VCs) and acts upon
>> the result. In neither case does the PEP pass its own VCs. So there is no
>> possibility of a confused deputy in either case (unless I have
>> misunderstood something)
>>
> The PEP is never a confused deputy.  (In the simplest case, the PEP only
> has permission to invoke the PDP.)  The confused deputy is one user (the
> deputy) performing an action requested by another user.  The deputy can be
> a confused deputy any time you separate designation from authorization.
>
> An authorization VC necessarily designates a single resource and specifies
> which operations on that resource are being authorized. Hence, designation
> and authorization are combined in the VC, and there is no confused deputy.
> Note that the user delegates to the deputy a new authorization VC for
> attenuation, selective revocation, and audit purposes.
>
> A claims VC says something about the holder, and typically does not
> designate a specific resource.  When presented for access, the PDP checks
> some property specified in the VC and makes an access decision for a
> resource specified in the request.  Here designation and authorization are
> separated, so there is a possibility of a confused deputy.  You might say
> you are safer because the deputy can include the user's claims VC in the
> request, but that would let the deputy make any request with the user's
> claims VC, whether the user wants it done or not.
>
> The essential difference is that the authorization VC specifies something
> about a specific resource, while a claims VC says something about the
> holder.
>
> --------------
> Alan Karp
>
>
> On Sat, Sep 10, 2022 at 2:30 AM David Chadwick <
> d.w.chadwick@truetrust.co.uk> wrote:
>
>>
>> On 09/09/2022 21:16, Alan Karp wrote:
>>
>> On Fri, Sep 9, 2022 at 9:57 AM David Chadwick <
>> david.chadwick@crosswordcybersecurity.com> wrote:
>>
>>> Sorry this just isn't the case. In the case of VCs, the user is wanting
>>> to access a resource with their own VCs, and the resource has a
>>> gatekeeper/PEP which is the Verifier/RP (the deputy in your terminology).
>>> So the RP verifies the VC, then validates the VC, and if and only if the
>>> verification and validation rules are passed is the user allowed to access
>>> the resource. The RP does not use its own VCs during this process (in fact
>>> it usually wont have any). I think you are thinking of the process that
>>> takes place after the user has been granted (or denied) access. In this
>>> case, say reading records from a database, the RP (deputy) is indeed the
>>> user accessing the resource (on behalf of the real user). But the RP
>>> already knows (from the PDP it queried) that the user has the necessary
>>> permissions.
>>>
>> Clearly, I completely misunderstood your point.  If the user invokes the
>> deputy with an authorization VC, we are talking about a capability
>> invocation.  There is no confused deputy vulnerability.  I thought you were
>> saying that the user invokes the deputy with a claims VC.  You might have a
>> confused deputy depending on how you use those claims to make the access
>> decision.
>>
>> I think the model works perfectly well for both capability and claims
>> based VCs. The gatekeeper/PEP blocks the user's access, passes the user's
>> VCs (of either type) to the appropriate PDP (clearly there will be
>> different policies for capability based and claims based VCs) and acts upon
>> the result. In neither case does the PEP pass its own VCs. So there is no
>> possibility of a confused deputy in either case (unless I have
>> misunderstood something)
>>
>> Kind regards
>>
>> David
>>
>>
>>
>> --------------
>> Alan Karp
>>
>>
>> On Fri, Sep 9, 2022 at 9:57 AM David Chadwick <
>> david.chadwick@crosswordcybersecurity.com> wrote:
>>
>>>
>>> On 09/09/2022 17:36, Alan Karp wrote:
>>>
>>> On Fri, Sep 9, 2022 at 2:49 AM David Chadwick <
>>> d.w.chadwick@truetrust.co.uk> wrote:
>>>
>>>> Hi Alan
>>>>
>>>> we did discuss this many years ago in the context of X.509 Attribute
>>>> Certificates and at the time you did agree that they could be used.
>>>>
>>> Yes, they can be used.  The question is if overloading something meant
>>> as a form of authentication should also be used as a form of
>>> authorization.  I have no problem doing that if the certificate clearly
>>> indicates which of them it is for.
>>>
>>>> and providing their credentials. The deputy (acting as a PEP) then
>>>> checks that these credentials are sufficient to do what was requested (by
>>>> calling a PDP and passing the user's credentials. Note it NEVER passes its
>>>> own). If the PDP returns OK then the user is granted access, otherwise the
>>>> user is denied access. So there is no chance of the confused deputy
>>>> situation arising.
>>>>
>>> I think that's the disconnect.  The deputy is not acting as a PEP.  As
>>> far as the PEP is concerned, the deputy is just another user.
>>>
>>>
>>> Sorry this just isn't the case. In the case of VCs, the user is wanting
>>> to access a resource with their own VCs, and the resource has a
>>> gatekeeper/PEP which is the Verifier/RP (the deputy in your terminology).
>>> So the RP verifies the VC, then validates the VC, and if and only if the
>>> verification and validation rules are passed is the user allowed to access
>>> the resource. The RP does not use its own VCs during this process (in fact
>>> it usually wont have any). I think you are thinking of the process that
>>> takes place after the user has been granted (or denied) access. In this
>>> case, say reading records from a database, the RP (deputy) is indeed the
>>> user accessing the resource (on behalf of the real user). But the RP
>>> already knows (from the PDP it queried) that the user has the necessary
>>> permissions.
>>>
>>>
>>> Consider a simple use case in which the user asks the deputy to
>>> translate a document from French to German and put the result in a
>>> specified place.  The user never accesses either file directly.  It simply
>>> tells the deputy which files to use.  It is the deputy that will do the
>>> reading and writing, so the PEP makes the access decision based on the
>>> deputy, not the user.
>>>
>>> We are talking about different PEPs. In my case, say I go to the google
>>> translate web service with my browser, and say that it is not a free
>>> service but a permissioned one. Then I pass my VCs to the google PEP (web
>>> service) asking it to translate the attached French document. The PEP
>>> checks my VCs by passing them to its PDP, and either grants or denies me
>>> permission. If the PDP grants me permission based on my VCs, then the PEP
>>> will ask for the translation to take place and return the German document
>>> to me. I think you are talking about this latter step. But this latter step
>>> will never take place if the user did not have the required permissions in
>>> the first place.
>>>
>>> Kind regards
>>>
>>> David
>>>
>>> No the access decision has already been made by the PDP and enforced by
>>>> the deputy. Of course if the PDP's policy is wrong, then the user could be
>>>> granted access, but that is not a confused deputy it is a bug in
>>>> implementation.
>>>>
>>>>
>>>> In fact, the verifier does not even know who the user is.
>>>>
>>>> In the ABAC model the verifier (PDP) does have the subject attributes,
>>>> resource attributes, action attributes and environment attributes in order
>>>> to make the access control decision.
>>>>
>>> In the cases in which you have a confused deputy vulnerability, the
>>> subject is the deputy, not the user.
>>>
>>>>
>>>> The result can be a confused deputy.
>>>>
>>>>> Of course with an appropriate schema we can constrain VCs to be
>>>>> capabilities, but in general this would lose the benefits of the RBAC/ABAC
>>>>> model. However where the use case requires it e.g. key to open hotel room,
>>>>> then it is easily achieved with VCs.
>>>>>
>>>> Roles, attributes, and even access control lists are fine ways to
>>>> describe access policies.  In a capability system, those policies are used
>>>> to decide who gets which capabilities.
>>>>
>>>> And a bug in that policy would give a capability to someone who should
>>>> not have it. So both models can suffer from bugs in implementation.
>>>>
>>> Correct.
>>>
>>> --------------
>>> Alan Karp
>>>
>>>>