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

On Tue, Sep 13, 2022 at 10:10 AM David Chadwick <
david.chadwick@crosswordcybersecurity.com> wrote:

> , but then the deputy could use that claim anywhere for any purpose,
> effectively impersonating the user.
>
> Not so for two reasons
>
> a) proof of possession. The VC contains the public key of the user and the
> VP contains the user's signature for PoP on a nonce provided by the deputy
> along with the deputy's name. So the deputy is not able to pass the VP to
> anyone else, nor prove possession to a third party of the VC because it
> cannot put the third party's nonce into the VP and sign it.
>
I'm not saying the deputy can pass the claims VC to anyone else.  I'm
saying the deputy can submit the claim to the PEP/PDP asking for any
resource the claim grants permission to.

> b) the user should only provide their VCs to trusted RPs (PEPs/Deputies).
> We are building the TRAIN trust infrastructure precisely for this purpose.
>
 That's still a serious violation of least privilege.  The risk is far less
if you use capabilities.

> The other problem then is what permissions the claim authorizes.  In
> general, claims are specifying things such as identity, role, or attributes
> of the holder.  The PDP uses that authentication to find the set of
> permissions the holder has, which is typically a lot.
>
> You cannot say that. The permissions are whatever the RP wants them to be
> for the particular claims. The RP sets the PDP's policy.
>
If the claims are of identity, role, or attributes, then the permissions
are typically quite extensive.  If it's possible to create a claim with
only the permissions needed for the request, then you have a capability.

> For example, it may include all permissions the user has at the resource
> server.  That means the deputy could specify a different resource than the
> one the user did.
>
> Not so because the PEP/deputy is a trusted component of the RP.
>
 You keep saying that, but the PEP is not the deputy I'm talking about.
You invoke a photo processing service and tell it to enhance a particular
photo at the place that holds all your photos.  The photo service's access
of the photo goes to the PEP.  In this scenario, the photo processing
service is the deputy.

> If the claim grants very few permissions, say to a single resource, then
> you have a capability.
>
> Brilliant. So if a VC with a specific claim is a capability, we do not
> need another standard to define the syntax of a capability. The VC DM will
> do nicely.
>
As long as the VC explicitly specify whether it is a claim or
authorization.  The reason is that there are differences in what the two
types specify.  For example, an authorization VC must specify a particular
resource, but a claims VC most likely does not.  Also, the revocation
mechanisms are quite different.  You don't know who might verify a claims
VC, so you need something like a CRL.  Since an authorization VC specifies
a specific resource, you know who to tell to revoke.

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

>