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

In my view, the confused deputy happens when the deputy (or the
verifier here in VC parlance) doesn't fully know what the issuer
actually authorized -- because the authorization doesn't designate
*what* it's for, it only states some power that the subject has to act
on *something*. That means that the deputy is left to figure out what
that something is on their own -- or to dangerously accept whatever
the presenter says it should be.

This is the core problem with trying to shoehorn authorizations into
VCs. VCs are intended to just be statements made by an issuer about
some subject. This information can be used by some verifier to help
them decide what to do. But it's the verifier that is making the
decision about what kind of authority to grant to the presenter of the
VC.

With authorization capabilities, it is the issuer of the root
capability (allowing for a delegated chain of attenuated capabilities)
that is granting authority to do X with Y. In fact, this root issuer
and the verifier are the *same party*. The issuer creates a root
capability and hands it to someone, who may delegate it (with optional
attenuation) to someone else, who ultimately brings it back to the
root issuer to use it -- where the root issuer plays the role of
verifier.

With VCs, the expectation (but not a requirement) is that the issuer
and verifier are different parties. Since the issuer is happy for many
different verifiers to consume and use their VCs, they do not
designate a specific target where the VC is to be used. Therefore, the
responsibility falls to each verifier to decide what authority it
ought to grant in exchange for a VC.

Now, could we take an authorization capability technology, e.g. ZCAPs,
that is intended to push this responsibility to issuers -- and map it
onto the VC data model? I imagine it could be done with some level of
awkwardness and perhaps some extra overhead we wouldn't otherwise
need. After all, a VC can say anything about anything. It's just that
you don't need that kind of extensibility with authorization
capabilities, nor do you want to decouple root issuers and verifiers
... because each of these things adds unnecessary attack surface.

But, yes, I'm sure we could make a VC where the issuer says "This is a
capability that authorizes action X to be taken with target Y". Having
a VC talk about a capability (to keep with the natural modeling of
VCs) vs. *be* the capability would also be an unnecessary additional
layer for an authz system. There would be a bit of work to make sure
you can chain these together for delegation and attenuation as well
(including crypto proofs) -- but perhaps someone could work out the
simplest way to map ZCAPs onto VCs to accomplish that.

At the end of the day we'd have to ask ourselves if taking this
approach was worth whatever the benefits are vs. just using a simpler
model to represent delegatable authorization capabilities.

--
Dave Longley
CTO
Digital Bazaar, Inc.

Received on Thursday, 8 September 2022 15:48:41 UTC