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

On Tue, Sep 13, 2022 at 1:16 AM David Chadwick <
david.chadwick@crosswordcybersecurity.com> wrote:

> I should have said there is no separate deputy entity. The PEP is of
> course the deputy using your terminology. So we have resolved this issue
>
I do not agree.  Many services mediate your requests.  When you log into
your account at Dropbox and ask to see a particular file, your request does
not go directly to the PEP.  A component of the web server makes the
request on your behalf.  That component is a deputy.  The same is true in a
microservices architecture.  Your request may pass through dozens of
microservices before the resource you specify is accessed.

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


On Tue, Sep 13, 2022 at 1:16 AM David Chadwick <
david.chadwick@crosswordcybersecurity.com> wrote:

> I should have said there is no separate deputy entity. The PEP is of
> course the deputy using your terminology. So we have resolved this issue
>
> Kind regards
>
> David
> On 12/09/2022 19:16, Alan Karp wrote:
>
> 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
>>>>>>
>>>>>>>