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

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