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

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

Best,
Nikos

-----Original Message-----
From: Manu Sporny <msporny@digitalbazaar.com>
Sent: Thursday, June 24, 2021 8:22 PM
To: public-credentials@w3.org
Subject: Re: PROPOSALs for VC HTTP API call on 2021-06-22

On 6/24/21 12:57 PM, Alan Karp wrote:
> That has been my concern all along, but I believe the complexity is
> manageable if we carefully define which fields of a VC must and must
> not be used when creating a permission token.

This requires people to understand the nuances... and this thread is a good
example of very informed people not grasping the nuances, complexity, and
dangers of what's being proposed.

Good technology shouldn't require a tremendous amount of explanation to
prevent harmful uses. If we are going to support authorization models being
expressed as VCs, we are going to end up with a lot of people mis-using the
technology.

In other words, VCs-as-permission-tokens are a foot-gun[1]... we should warn
against that use and instead nudge people towards using other capability
systems that are designed to address the use cases (OAuth/RAR, GNAP/RAR,
ZCAPs, etc.)

VCs-as-attribute-based-permission-tokens are a really dangerous idea.

-- manu

[1]https://news.ycombinator.com/item?id=17393292

--
Manu Sporny - https://www.linkedin.com/in/manusporny/
Founder/CEO - Digital Bazaar, Inc.
News: Digital Bazaar Announces New Case Studies (2021)
https://www.digitalbazaar.com/