Verifiable Credentials (VCs) and the confused deputy

[Alan Karp]

David Chadwick and I just had a long exchange on one of the W3C lists about this subject.  Most of the time we were talking past each other, but I finally understood the point he was making.

In the confused deputy example, the user makes a request of the deputy, which invokes an operation on a resource designated by the user.  The vulnerability arises because there is no way for the deputy to say to check the user's permissions rather than the deputy's.  David, it turns out, was asking, "What if you could?"

In a system with verifiable credentials, the user will receive a digital certificate signed by some organization stating certain properties of the user.  Canonical examples are such things as digital driver's licenses and diplomas.  A verifier will accept the certificate if it trusts the issuer.  

David is suggesting that VCs can also specify authentication information, such as identity, role, or attributes.  In this case, a system administrator would provide the user with a VC specifying the authentication.  The user could then designate the resource and pass its VC to the deputy.  The deputy could then use the VC when invoking the resource so that the access decision can be based on the user's permissions.  No confused deputy even though you've separated designation from authorization.  Is that right?

The downside is that the deputy gets all the user's permissions.  I consider that a showstopper, but David claims you should only invoke deputies you trust.  We left it there.

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

[Kevin Reid]

On Tue, Sep 13, 2022 at 3:51 PM Alan Karp <alan...@gmail.com> wrote:

The downside is that the deputy gets all the user's permissions.  I consider that a showstopper, but David claims you should only invoke deputies you trust.

That's really the heart of the thing, I think. The original confused deputy is “program acts on the user's designation using administrative permissions". The system you described is “program acts on the user's designation (we hope) using the user's permissions". This is the same as the usual “run a program with the permissions of your user account” (except that the deputy may have other permissions too) or “give the service your password broad-scoped token” model.

[Tony Arcieri]

I remember talking to some of the Verifiable Credentials people many years ago. They seemed sort of interested in Macaroons at the time, which can solve this problem via offline attenuation (adding caveats to the Macaroon prior to giving it to the deputy). Alas, it seems like no such features made it into VC.

[Alan Karp]

On Fri, Sep 16, 2022 at 4:45 PM Tony Arcieri <bas...@gmail.com> wrote:

I remember talking to some of the Verifiable Credentials people many years ago. They seemed sort of interested in Macaroons at the time, which can solve this problem via offline attenuation (adding caveats to the Macaroon prior to giving it to the deputy). Alas, it seems like no such features made it into VC.

The benefit of using VCs as capabilities is the reuse of the encryption/signing infrastructure that's been implemented to support claims VCs.  Macaroons wouldn't be able to use all that stuff.  Perhaps that's why it wasn't included.

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