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

On Thu, Jun 24, 2021 at 4:25 AM David Chadwick <
d.w.chadwick@verifiablecredentials.info> wrote:

> 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 is simply not the case with VCs, which support selective disclosure
> and least privileges.
>
> The RP decides what subject attributes are required and sends these to the
> subject's wallet (as its policy). The wallet checks if it has the required
> VCs and asks the user to consent to their release.
>
> Consequently the RP gets exactly what it requested and knows the subject
> wanted to submit them.
>
> So there is no chance of a confused deputy or ambient permissions in this
> scenario
>
>
Selective disclosure of what's in a claims token is not the same thing as
subsetting the permissions in a permission token.  That means we are both
right.  You are right for claims tokens; I am right for permission tokens.

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


On Thu, Jun 24, 2021 at 4:25 AM David Chadwick <
d.w.chadwick@verifiablecredentials.info> wrote:

>
> On 23/06/2021 23:09, Alan Karp wrote:
>
> 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 is simply not the case with VCs, which support selective disclosure
> and least privileges.
>
> The RP decides what subject attributes are required and sends these to the
> subject's wallet (as its policy). The wallet checks if it has the required
> VCs and asks the user to consent to their release.
>
> Consequently the RP gets exactly what it requested and knows the subject
> wanted to submit them.
>
> So there is no chance of a confused deputy or ambient permissions in this
> scenario
>
> Kind regards
>
> David
>
>
>   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
>>
>>