Re: PROPOSALs for VC HTTP API call on 2021-06-22

On Thu, Jun 24, 2021 at 2:18 PM Nikos Fotiou <fotiou@aueb.gr> wrote:

> AFAIU there is no such thing “kind of VC”. Whether the claims included in
> a VC are “properties”, or “permissions” is a conceptual/higher layer thing.
> Also I don’t understand why “Alice delegates to Bob” is translated into
> “Alice issues a VC to Bob” (Kyle’s example). This makes things complicated.
> IMHO that should translate into “Alice asks her issuer to generate a VC for
> Bob”, e.g., “Alice the manager asks her company to generate a manager VC
> for Bob while she is on vacation”, “Alice the file owner asks cloud storage
> X to generate a “read access” VC for Bob”.
>

You are correct.  I proposed that such a distinction is needed when someone
suggested using VCs as authorization tokens.

You have described the two ways to do delegation of permission tokens.  If
they are certificates, Alice can create one herself, an approach described
in several places including zcap-ld.  If they are opaque, such as OAuth
bearer tokens, Alice must ask her issuer to create one for Bob, a process
called "token exchange" in the OAuth world.

>
>
> In any case, my point is that Manu wrote that “it's so complicated (and
> thus dangerous) to use VCs as permissions tokens” and suggested OAuth/RAR
> as an alternative. But I really don’t see any difference between a RAR
> token and a VC. Note also that OAuth/RAR does not support “attenuated
> delegation of permissions”, at least the way you describe them.
>

I don't either.  I view RAR as a means to describe which permissions token
to give out.  That's why it doesn't bother me that RAR doesn't support
attenuated delegation of permissions.

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