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

"On Thu, Sep 8, 2022 at 12:16 PM David Chadwick <
d.w.chadwick@truetrust.co.uk> wrote:

> Hi Dave
>
> I appreciate your explanation, but what you omit to say that with the
> RBAC/ABAC model it is intentional that the issuer and verifier are separate
> entities, and that each has its own responsibilities, which makes it a more
> powerful model. The issuer is responsible for issuing roles and attributes
> to the subject and the verifier is responsible for determining which roles
> or attributes are needed to access which of its resources. So there is no
> chance of a confused deputy in this situation, since the verifier only uses
> the subject's roles/attributes to determine which resource the subject can
> access in which way.
>
That is not true.  See our paper  "From ABAC to ZBAC: The Evolution of
Access Control Models
<http://shiftleft.com/mirrors/www.hpl.hp.com/techreports/2009/HPL-2009-30.pdf>"
for a detailed explanation.  (The link to the published article is broken,
and HP Labs broke all links to old tech reports.)  The point is that the
user invokes the deputy, naming the resource.  The deputy does the
specified operation on that resource.  Hence, the verifier uses the
deputy's identity, role, or attributes when making the access decision.  In
fact, the verifier does not even know who the user is.  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.

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