W3C home > Mailing lists > Public > public-credentials@w3.org > June 2021

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

From: Alan Karp <alanhkarp@gmail.com>
Date: Wed, 23 Jun 2021 10:30:37 -0700
Message-ID: <CANpA1Z3c5wGtaCQq=eXgDk1qTDaQ-_CRF5udHCh42QVZF5Z=zg@mail.gmail.com>
To: David Chadwick <d.w.chadwick@verifiablecredentials.info>
Cc: "W3C Credentials CG (Public List)" <public-credentials@w3.org>
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.

> 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
Received on Wednesday, 23 June 2021 17:31:19 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 23 June 2021 17:31:23 UTC