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

That explains it.  These questions are far easier to answer for permission
tokens.

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


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

> Hi Alan
>
> the complexity came from a number of different areas:
>
> i) different superiors delegating the same attribute(s) to a delegate
>
> ii) can a delegate merge attributes from multiple delegations into a
> single one and delegate onwards
>
> iii) when revoking, who should have the power, and should they be able to
> revoke all the delegations or just the one they issued themselves
>
> iv) what happens when a person resigns or the employment is terminated
>
> v) should transfer rather than delegation be included
>
> vi) how to handle cascading revocations
>
> vii) when delegation tree becomes a network...
>
> At the time we read quite a number of academic papers on the topic, and
> some had even more complex schemes than ours (and someone from Royal
> Holloway did an entire PhD on it, showing how complex it can become).
>
> Kind regards
>
> David
> On 24/06/2021 16:43, Alan Karp wrote:
>
> On Thu, Jun 24, 2021 at 1:51 AM David Chadwick <
> d.w.chadwick@verifiablecredentials.info> wrote:
>
>> Hi Kyle
>>
>>
>> the complexity comes not from whether it is a claim or a permission, but
>> from whether it is delegatable or not. Delegation is massively complex as I
>> know from our X.509 AC PERMIS implementation. So whether the token is
>> encoded as a VC, an X.509 AC or anything else is simply a question of
>> syntax and parsing. Since we already have use cases of delegation in VCs
>> (e.g. prescription handling) then I see no value in duplicating the effort
>> in two different W3C specifications.
>>
>
> Interesting.  We didn't find making delegation certificates any more
> complex than producing any other kind of certificate.  You created the new
> certificate and copied the certificate you were delegating from into the
> SAML 1.1 (that's how long ago we did the work) Authorization field.  You
> can see samples at
> https://www.hpl.hp.com/techreports/2007/HPL-2007-105.html.  Is the
> difference that you were doing it for claims tokens, and we did it for
> permission tokens?
>
> --------------
> Alan Karp
>
>
> On Thu, Jun 24, 2021 at 1:51 AM David Chadwick <
> d.w.chadwick@verifiablecredentials.info> wrote:
>
>> Hi Kyle
>>
>>
>> the complexity comes not from whether it is a claim or a permission, but
>> from whether it is delegatable or not. Delegation is massively complex as I
>> know from our X.509 AC PERMIS implementation. So whether the token is
>> encoded as a VC, an X.509 AC or anything else is simply a question of
>> syntax and parsing. Since we already have use cases of delegation in VCs
>> (e.g. prescription handling) then I see no value in duplicating the effort
>> in two different W3C specifications.
>>
>>
>> Also the use cases where holder NE subject significantly increases
>> complexity as well, and in some ways is related to delegation.
>>
>>
>> Kind regards
>>
>> David
>>
>>
>> On 24/06/2021 01:49, Kyle Den Hartog wrote:
>>
>> >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).
>>
>> This is my take on this too. However, I think where we differ is not
>> whether is possible, but rather whether it's the "right way to do it". For
>> me, I tend to think that using VCs as a claims token is an excellent use
>> case and fits squarely within the realm of their design. However,
>> permission token tends to lead to a lot of complexity on the verifier side
>> in a way that makes it difficult for them to build simple authorization
>> processors. For these reasons, I tend to lean towards not recommending the
>> usage of them in this way even though it's possible.
>>
>> -Kyle
>> ------------------------------
>> *From:* David Chadwick <d.w.chadwick@verifiablecredentials.info>
>> <d.w.chadwick@verifiablecredentials.info>
>> *Sent:* Thursday, June 24, 2021 7:44 AM
>> *To:* Alan Karp <alanhkarp@gmail.com> <alanhkarp@gmail.com>
>> *Cc:* W3C Credentials CG (Public List) <public-credentials@w3.org>
>> <public-credentials@w3.org>
>> *Subject:* Re: PROPOSALs for VC HTTP API call on 2021-06-22
>>
>>
>>
>> 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
>>
>>