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

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.

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.

> 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

>