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

On Mon, Sep 12, 2022 at 9:58 AM David Chadwick <d.w.chadwick@truetrust.co.uk>
wrote:

>
> On 12/09/2022 17:26, Alan Karp wrote:
>
> You can have a confused deputy any time you separate designation from
> authorization.
>
> Could you please describe clearly how this can occur in the ABAC/PEP/PDP
> model please (assuming no buggy implementations).
>

Let's take the classic confused deputy example without VCs first.  You have
a service that takes an input resource and produces an output
resource, both chosen by the user.  In addition, your service updates a
billing resource on every invocation, a resource only your service has
permission to write.

The user invokes your service, which authenticates the user (identity,
role, attributes) to decide if it should honor the request.  Your service
(the deputy) then invokes a read operation on the input resource.  The PDP
needs some credential to decide whether or not to honor the request.  In a
non-VC environment, the only credential available is the service's
authentication.  That means your service needs permission to read any
resource the user might specify, a violation of Least Privilege.  (That's
the way many services work today.)

Your service then processes the input resource and produces the output
resource.  Again, the PDP needs a credential, and the only available
credential is that of your service.  All is good unless the user specifies
your billing resource as the output.  Norm Hardy was motivated to write the
confused deputy paper when this happened where he was working.

Some of these problems can be mitigated using claims VCs.  The user invokes
your service providing a claim that will grant read permission to the input
resource and write permission to the output resource.  (Most claims grant a
lot more than just that.)  Your service uses those claims when reading the
input resource and producing the output resource, but it can use any other
permissions authorized by the claim.  Your service also must include a
claim VC of its own in order to write the billing resource.  There is no
confused deputy if those steps are invoked one-by-one.  However, there are
often good reasons (performance, reliability, legacy) that's not done.

If the requests are combined into a single invocation, the PDP gets two
claims VCs to decide whether to honor your service's request, but it has no
way to know which claims go with which argument.  The result is that it may
allow your service to overwrite the billing resource with the output.  If
the PDP does know which claim goes with which argument, you are very close
to a capability system much in the way OAuth 2 is.  (OAuth 2 designates
with the URL and authorizes with the header.  As long as those two are kept
together, you've got a capability.)

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