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

On Mon, Sep 12, 2022 at 10:47 AM David Chadwick <
david.chadwick@crosswordcybersecurity.com> wrote:

> I think we have finally hit the nub of the problem.
>
> In your view there is the user, PEP, deputy and resource, but in the
> ABAC/PEP/PDP model there is only the user, PEP and resource (with the PDP
> off to the side). There is no deputy in the latter architecture
>
If there is no deputy with resource permissions of its own, then there is
nobody to be confused.  However, it is quite common to invoke a service
specifying a resource and have that service access it.  In that case, the
service is the deputy.

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


On Mon, Sep 12, 2022 at 10:47 AM David Chadwick <
david.chadwick@crosswordcybersecurity.com> wrote:

> I think we have finally hit the nub of the problem.
>
> In your view there is the user, PEP, deputy and resource, but in the
> ABAC/PEP/PDP model there is only the user, PEP and resource (with the PDP
> off to the side). There is no deputy in the latter architecture
>
> Kind regards
>
> David
> On 12/09/2022 18:15, Alan Karp wrote:
>
> On Mon, Sep 12, 2022 at 9:55 AM David Chadwick <
> d.w.chadwick@truetrust.co.uk> wrote:
>
>>
>> On 12/09/2022 17:34, Alan Karp wrote:
>>
>> I just popped out to pick up some bagels.  While standing in line I
>> realized why I've been missing your point.  (Something about the smell of
>> onion bagels?)
>>
>> I hope they tasted good :-)
>>
> Izzy's Brooklyn Bagels are the best.
>
>> You are saying that the deputy submits the request with the user's VC.
>> Is that right?
>>
>> In ABAC the entity is called the PEP (policy enforcement point). But in
>> your terminology it is a deputy since the user asks it to do something on
>> its behalf.
>>
>
> I believe you are talking about 2 parties, the user and the PEP acting as
> deputy.  I am talking about 3 parties, the user, the deputy, and the PEP.
>
>>
>> There are two problems with that.  First,  it's a gross violation of the
>> Principle of Least Privilege,
>>
>> No its not, because prior to this step, the user requested to do
>> something, and the PEP returned its LP policy, saying if you want to do
>> this, then I need the following VCs from you. So LP has already been
>> enforced because the PEP is required (in Europe at least due to GDPR) to
>> only request those claims that are needed for the task in hand. (DIF has
>> produced a draft spec for this request, called Presentation Exchange, to
>> which the user returns a VP).
>>
> The problem is that a claim can authorize many permissions, not just the
> one needed for a given request.
>
>>
>> because the deputy can use any of the user's permissions.
>>
>> Again you are missing the point that the PEP is a trusted component of
>> the resource site. So it would not request the wrong action on behalf of
>> the user, and it could not use the user's VCs itself because it cannot
>> prove possession of them.
>>
> See above.  There is a third party acting as the deputy.
>
>> Second, it only avoids confused deputy in the simplest case where there
>> is only one argument.  You can still have a confused deputy when there are
>> multiple arguments, and some need the permissions of the user and the
>> others the permissions of the deputy.
>>
>> Now you are confusing me, because in the ABAC model the deputy never uses
>> its own permissions to enact the task requested by the user (other than the
>> ambient authority as we have agreed). If the user wants to perform a series
>> of tasks, then the entire process is repeated so that least privileges is
>> ensured for each action through the different VCs that the user presents to
>> the PEP each time.
>>
> In the classic confused deputy described by Norm Hardy, there are two
> arguments in the call.  One should use the permissions of the user; the
> other, the permissions of the deputy.
>
> --------------
> Alan Karp
>
>
> On Mon, Sep 12, 2022 at 9:55 AM David Chadwick <
> d.w.chadwick@truetrust.co.uk> wrote:
>
>>
>> On 12/09/2022 17:34, Alan Karp wrote:
>>
>> I just popped out to pick up some bagels.  While standing in line I
>> realized why I've been missing your point.  (Something about the smell of
>> onion bagels?)
>>
>> I hope they tasted good :-)
>>
>>
>>
>> You are saying that the deputy submits the request with the user's VC.
>> Is that right?
>>
>> In ABAC the entity is called the PEP (policy enforcement point). But in
>> your terminology it is a deputy since the user asks it to do something on
>> its behalf.
>>
>>
>> There are two problems with that.  First,  it's a gross violation of the
>> Principle of Least Privilege,
>>
>> No its not, because prior to this step, the user requested to do
>> something, and the PEP returned its LP policy, saying if you want to do
>> this, then I need the following VCs from you. So LP has already been
>> enforced because the PEP is required (in Europe at least due to GDPR) to
>> only request those claims that are needed for the task in hand. (DIF has
>> produced a draft spec for this request, called Presentation Exchange, to
>> which the user returns a VP).
>>
>>
>> because the deputy can use any of the user's permissions.
>>
>> Again you are missing the point that the PEP is a trusted component of
>> the resource site. So it would not request the wrong action on behalf of
>> the user, and it could not use the user's VCs itself because it cannot
>> prove possession of them.
>>
>>
>> Second, it only avoids confused deputy in the simplest case where there
>> is only one argument.  You can still have a confused deputy when there are
>> multiple arguments, and some need the permissions of the user and the
>> others the permissions of the deputy.
>>
>> Now you are confusing me, because in the ABAC model the deputy never uses
>> its own permissions to enact the task requested by the user (other than the
>> ambient authority as we have agreed). If the user wants to perform a series
>> of tasks, then the entire process is repeated so that least privileges is
>> ensured for each action through the different VCs that the user presents to
>> the PEP each time.
>>
>> Kind regards
>>
>> David
>>
>>
>> --------------
>> 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
>>>>>
>>>>>>