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

>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>
Sent: Thursday, June 24, 2021 7:44 AM
To: Alan Karp <alanhkarp@gmail.com>
Cc: W3C Credentials CG (Public List) <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<mailto: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