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

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.

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