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

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

> 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.
>
> Not so. First with VCs, you do not log in to your account. There is no
> need. (Login is usually the opposite of least privileges and requires
> maximum privileges.) Second, you request access to a particular resource
> (say by clicking on its icon) and it sends you its policy for which VC(s)
> are needed to be granted access, and you return these VC(s) directly to the
> PEP. Once the PEP has validated your VCs (by calling the PDP), it will then
> (using ambient authority) request access to the resource on your behalf.
>
Instead of login I should have said, "when you present your claims VC
proving you have permission to use the account."

In general, the claims VC you submit to the PEP specifies identity, role,
or attributes, which the PDP maps to a wide set of permissions, typically
granting access to everything you have stored there.  You can design a VC
system with fine-grained permissions, but then you've got capabilities.

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


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

>
> On 13/09/2022 18:01, Alan Karp wrote:
>
> 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.
>
> Not so. First with VCs, you do not log in to your account. There is no
> need. (Login is usually the opposite of least privileges and requires
> maximum privileges.) Second, you request access to a particular resource
> (say by clicking on its icon) and it sends you its policy for which VC(s)
> are needed to be granted access, and you return these VC(s) directly to the
> PEP. Once the PEP has validated your VCs (by calling the PDP), it will then
> (using ambient authority) request access to the resource on your behalf.
>
> Kind regards
>
> David
>
>   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
>>>>>>>
>>>>>>>>