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

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
>
>