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

On Wed, Jun 23, 2021 at 12:45 PM David Chadwick <
d.w.chadwick@verifiablecredentials.info> wrote:

>
> But in the ABAC/RBAC models there is a level of indirection with
> permission tokens. This level of indirection provides a lot of advantages
> (as people who invented DIDs as the level of indirection between users and
> key IDs know very well). The resource server is conceptually split into
> two, the issuer and the consumer of the permission token. This allows the
> permission token to be used at a whole set of different
> resources/consumers. What you call a claim token is a privilege attribute
> token which bestows permissions on the user at a set of resource sites (the
> consumers). And this level of indirection means that different permissions
> at different consumers can be bestowed with the same privilege token. So to
> use your example, an educational institution certifies Alice as a machine
> operator and this can grant Alice permission to operate machines at a
> number of different sites (if the machines are configured to accept it).
> And it could also grant Alice permission to join the honorable society of
> machine operators.
>

ABAC and RBAC are good ways to decide who gets which permission tokens,
as are ACLs and claims tokens.  In our example, Alice might present her
claim token showing that she is trained to use a type of machine and get a
permission token to use a specific instance of that type.

The problem arises when identity, role, or attribute is used to decide
whether or not to honor a request.  You have no idea which permissions the
invoker wants to use, so you pick any that match the request.  This use of
"ambient authorities," permissions associated with the requester and not
the request, is the root cause of the confused deputy.

A claims token necessarily can be used by many consumers.  That should not
be the case for permission tokens.  Each capability must designate a
specific resource.  (Multi-audience tokens are one of the ways OAuth 2
tokens aren't capabilities.)  Things get complicated if it designates many.

> So this confirms my original thesis, that a VC can contain either a
> permission or a claim as it is essentially a statement of something made by
> an issuer. (But I think we already agreed this in the special CCG call that
> we had a few months ago). The VC essentially means that the statement is
> verifiable by the recipient (who could be the issuer or anyone else).
>
> I have been arguing that the spec specify that a VC may contain a
permission only if the system supports attenuated delegation.

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


On Wed, Jun 23, 2021 at 12:45 PM David Chadwick <
d.w.chadwick@verifiablecredentials.info> wrote:

>
> On 23/06/2021 18:30, Alan Karp wrote:
>
> On Wed, Jun 23, 2021 at 1:32 AM David Chadwick <
> d.w.chadwick@verifiablecredentials.info> wrote:
>
>> great conversation. Can you please clearly articulate the difference
>> between claim tokens and permission tokens.
>>
> A claims token describes a property of the subject, such as Alice is
> certified to operate this kind of machine.  The verifier is not known at
> the time the VC is created, e.g., the person interviewing Alice for a job
> as a machinist.
>
> A permission token authorizes an action on a resource, such as Alice has
> permission to view this photo.  The verifier is known at the time the token
> is created, e.g., the resource server or an agent it trusts.
>
> thanks for clarifying this.
>
> But in the ABAC/RBAC models there is a level of indirection with
> permission tokens. This level of indirection provides a lot of advantages
> (as people who invented DIDs as the level of indirection between users and
> key IDs know very well). The resource server is conceptually split into
> two, the issuer and the consumer of the permission token. This allows the
> permission token to be used at a whole set of different
> resources/consumers. What you call a claim token is a privilege attribute
> token which bestows permissions on the user at a set of resource sites (the
> consumers). And this level of indirection means that different permissions
> at different consumers can be bestowed with the same privilege token. So to
> use your example, an educational institution certifies Alice as a machine
> operator and this can grant Alice permission to operate machines at a
> number of different sites (if the machines are configured to accept it).
> And it could also grant Alice permission to join the honorable society of
> machine operators.
>
> So this confirms my original thesis, that a VC can contain either a
> permission or a claim as it is essentially a statement of something made by
> an issuer. (But I think we already agreed this in the special CCG call that
> we had a few months ago). The VC essentially means that the statement is
> verifiable by the recipient (who could be the issuer or anyone else).
>
> Kind regards
>
> David
>
> I also thought of an interesting use case last night.
>>
>> The VP contains an audience restriction property set to RP1. RP1
>> delegates to RP2 to get the VP verified. The Verification Service (Http
>> API) sees the VP is restricted to be only seen/used by RP1 but RP2 is
>> asking for it to be verified. Should the Verifier agree to RP2's request or
>> refuse it.
>>
> That sounds like a use case for a claims token, so I'm no expert.  I would
> think it would be allowed, since RP2 might be part of the RP1 trust domain,
> but there may be some conditions I'm not aware of.
>
> A permission token is submitted to the resource server which is in charge
> of getting the token verified, so I don't think this use case applies to
> them.
>
> --------------
> Alan Karp
>
>