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

Thanks for saying that Nikos -- "Whether the claims included in a VC are
“properties”, or “permissions” is a conceptual/higher layer thing."  A
verifiable credential is a data container with some very interesting/useful
properties (notably the three/four properties that are cryptographically
proven when presented and verified; removal of issuer from presentation). I
think the VC spec. including some of those higher layer concepts adds to
the confusion (e.g. the use of "subject" in the spec) stemming from
early use cases, but VC usage is getting beyond that.

On Thu, Jun 24, 2021 at 2:22 PM Nikos Fotiou <fotiou@aueb.gr> wrote:

> AFAIU there is no such thing “kind of VC”. Whether the claims included in
> a VC are “properties”, or “permissions” is a conceptual/higher layer thing.
> Also I don’t understand why “Alice delegates to Bob” is translated into
> “Alice issues a VC to Bob” (Kyle’s example). This makes things complicated.
> IMHO that should translate into “Alice asks her issuer to generate a VC for
> Bob”, e.g., “Alice the manager asks her company to generate a manager VC
> for Bob while she is on vacation”, “Alice the file owner asks cloud storage
> X to generate a “read access” VC for Bob”.
>
>
>
> In any case, my point is that Manu wrote that “it's so complicated (and
> thus dangerous) to use VCs as permissions tokens” and suggested OAuth/RAR
> as an alternative. But I really don’t see any difference between a RAR
> token and a VC. Note also that OAuth/RAR does not support “attenuated
> delegation of permissions”, at least the way you describe them.
>
>
>
> Best,
>
> Nikos
>
>
>
> *From:* Alan Karp <alanhkarp@gmail.com>
> *Sent:* Thursday, June 24, 2021 11:39 PM
> *To:* Nikos Fotiou <fotiou@aueb.gr>
> *Cc:* Manu Sporny <msporny@digitalbazaar.com>; W3C Credentials CG (Public
> List) <public-credentials@w3.org>
> *Subject:* Re: PROPOSALs for VC HTTP API call on 2021-06-22
>
>
>
> On Thu, Jun 24, 2021 at 11:05 AM Nikos Fotiou <fotiou@aueb.gr> wrote:
>
> I don't understand why an OAuth/RAR token is different from a VC. At least
> to
> me the example here
> https://datatracker.ietf.org/doc/html/draft-ietf-oauth-rar-05#section-7 is
> very similar to a VC. Moreover, AFAIU, OAuth/RAR does not consider
> delegation
> hence Kyle's example cannot be implemented using OAuth/RAR (and this leads
> me
> to the question, why do we need delegation in VCs?)
>
>
>
> Which kind of VC are you referring to?  A claims VC, e.g., Alice has
> passed her driver's test, or a permission VC, e.g., this token grants
> permission to drive this specific car.  Typically, you don't know who will
> verify a claims VC, e.g., any traffic cop, but you do know for a
> permissions VC, the car.
>
>
>
> Delegating a claim depends on policy.  It doesn't make sense to allow
> Alice to delegate her driver's license, but Alice may wish to delegate her
> position as manager to Bob while she is on vacation.
>
>
>
> It always makes sense to allow attenuated delegation of permissions.
> Alice, with permission to read and write a particular file, may want Bob to
> be able to read it.  If she can't delegate that subset of her permissions,
> she will have to share whatever credential, e.g., OAuth access token, she
> uses.  In that case, Bob gets permissions Alice would rather he not have,
> and there is no way to know which requests were made by Bob and not Alice.
>
>
> --------------
> Alan Karp
>


-- 

Stephen Curran
Principal, Cloud Compass Computing, Inc. (C3I)
Trustee, Vice Chair - Sovrin Foundation (sovrin.org)

*Schedule a Meeting: **https://calendly.com/swcurran
<https://calendly.com/swcurran>*