Re: Signs of adoption of CCG specifications

Joe Andrieu
President
joe@legreq.com
+1(805)705-8651
------------------------------
Legendary Requirements
https://legreq.com


On Wed, Jul 30, 2025, 2:49 PM Gabe Cohen <gabe.cohen@toolsforhumanity.com>
wrote:

> IOW: it’s a lifecycle issue
>
> If a relying party decides the lifecycle of their auth needs matches that
> of a VC I don’t see an issue with the approach, though it’s easier to
> reason about a system that creates distinct artifacts for distinct purposes.
>


Respectfully,  I think there is something deeper going on here,  something
fundamental about language.

A linguist once told me there are four distinct types of utterances:
declarations of fact, imperative orders, questions, and exclamations.

RDF and therefore VCs represent statements of fact.  In particular,
statements of predication, where a subject is linked via a predicate to
(optional) objects.

Joe is mean.
Manu is nice.
Adrian is a physician by training.

VCs are designed to communicate these kinds of declarative assertions.

They were not designed for, nor IMO, should they be used for, statements of
command.

Even an RDF statement like
<Joe> <commandsYou> <Smile>
Is problematic.

Is that saying Joe continously commands everyone who reads this to Smile?

It is a statement that Joe commands You to smile. But is that statements
itself a command? I'd say no. It is a description of an action Joe takes,
without a way to describe to whom or when it is commanded.

In particular,  someone other than Joe can make that statement about such a
command.  E.g., Manu says "Joe commands you to smile".

Is Manu's statement a command?

It's a statement about a command. Neither Manu nor Joe is making that
command Manu might even be incorrect and the command was never uttered. The
statement about a command cannot be the command itself.

VCs are not particularly well suited to authorization, which requires both
a statement of what is authorized AND a statement that triggers that action.

They also aren't well suited to exclamations and questions. You *could* use
declarative statements to describe that a person
(a) is allowed to trigger something
(b) has triggered that something
(c) that anyone reading this statement should take it as a trigger pulling
action and do the action.

However,  none of these deal with the semantic nuance that an object
capability like zCaps or UCANs enable. In a VC like (c) for example, how do
you know if the trigger is a directive to the reader? When I see such a VC,
should I activate the triggerred action? VCs don't have a mechanism to
detect if it's already been triggered. zCaps solve that.

So... you could build in the semantics of a framework of authorization
through declarative statements, but you still have the quirkiness of how
you know that THIS signed object is a trigger at a point in time of a
particular authorized action.

In other words,  echoing Dave's comments, VCs don't deal with the
functionality you need for authorization.

zCaps, a proto- standards track effort at the w3c, can express this kind of
semantic. They also have well thought out mechanisms for decentralized
delegation and attenuation.

So if you want standards, we're working on them.  Help is welcome.

>
> On Jul 30, 2025 at 1:46:01 PM, Alan Karp <alanhkarp@gmail.com> wrote:
>
>> On Wed, Jul 30, 2025 at 12:01 PM Adrian Gropper <agropper@healthurl.com>
>> wrote:
>>
>>> Which spec are we overloading?
>>>
>>
>> According to the spec that Manu has devoted the better part of his life
>> to, a Verifiable Credential is designed to carry claims about a subject.
>> It was not designed to be used as an authorization token.
>>
>> --------------
>> Alan Karp
>>
>>
>> On Wed, Jul 30, 2025 at 12:01 PM Adrian Gropper <agropper@healthurl.com>
>> wrote:
>>
>>> Which spec are we overloading? As an authorization endpoint I want to
>>> know who is accountable for the authorization request and on what basis
>>> they will be accountable.
>>>
>>> The model we use in HIE of One is "Break the glass" in a typical
>>> hospital environment. Almost any employee can request access to a patient's
>>> resources and if they agree to Break the glass then that request is logged
>>> for audit and maybe they are authorized. The request is implicitly signed
>>> by their being logged in to the hospital system and the hospital tracks
>>> whatever credentials are associated with the requesting party.
>>>
>>> In a case like HIE of One, where the authorization server is autonomous
>>> in the sense that it is controlled by the resource owner rather than a
>>> hospital institution creating a log that will be acceptable in a court of
>>> law or professional board. This could be done manually using a public
>>> notary. In a more decentralized context, the logs have to be kept
>>> separately by all parties. Verification of requesting party credentials and
>>> the associated authentication is up to the authorization server.
>>>
>>> What spec are we overloading by using VC as part of the RqP request? As
>>> far as DIDs, we don't implement them yet because we don't want to force
>>> users to install random wallets. We use Passkeys for authentication to
>>> limit password sharing in order to improve the authenticity of logs. What
>>> would you suggest?
>>>
>>> Adrian
>>>
>>>
>>>
>>> On Wed, Jul 30, 2025 at 1:09 PM Alan Karp <alanhkarp@gmail.com> wrote:
>>>
>>>> The problem is in the details, delegation and revocation in
>>>> particular.  Consider a VC that is making a claim, such as that you are
>>>> licensed to drive a truck.  What does delegation even mean?  Also, you
>>>> don't know who might need to verify that claim, so you need something like
>>>> a revocation list.  Now consider a certificate authorizing the holder to
>>>> query and update a specific resource.  Delegating the query permission
>>>> makes perfect sense, and you know that only the resource needs to validate
>>>> the certificate.  Overloading one spec for both purposes is a recipe for
>>>> confusion.
>>>>
>>>> --------------
>>>> Alan Karp
>>>>
>>>>
>>>> On Wed, Jul 30, 2025 at 9:37 AM Adrian Gropper <agropper@healthurl.com>
>>>> wrote:
>>>>
>>>>> Please help me understand this. I think I get the difference between
>>>>> authentication and authorization. When someone or something shows up at an
>>>>> authorization endpoint with some request (e.g. RFC 9396 - RAR) that request
>>>>> could include a VC and be signed by the requester.
>>>>>
>>>>> This is the model we've always used in the HIE of One demo. If the
>>>>> requester is a physician, they present one or more VCs and authenticate
>>>>> with a Passkey that is somehow linked to the VC. If the requester is a bot
>>>>> operated by OpenAI, why would anything be different from the authorization
>>>>> server's perspective?
>>>>>
>>>>> Adrian
>>>>>
>>>>> On Wed, Jul 30, 2025 at 12:02 PM Manu Sporny <
>>>>> msporny@digitalbazaar.com> wrote:
>>>>>
>>>>>> On Wed, Jul 30, 2025 at 11:29 AM Alan Karp <alanhkarp@gmail.com>
>>>>>> wrote:
>>>>>> > I've read several papers/specs over the past few months where
>>>>>> agentic AI systems are using VCs for permissions.  I believe this choice is
>>>>>> a mistake for reasons that I have articulated several times.
>>>>>>
>>>>>> Yes, it's a mistake. At present, this is the statement we have in the
>>>>>> VC spec about using VCs for authorization:
>>>>>>
>>>>>> https://www.w3.org/TR/vc-data-model-2.0/#authorization
>>>>>>
>>>>>> ... which literally says: "Authorization is not an appropriate use for
>>>>>> this specification". :)
>>>>>>
>>>>>> What we need to do is get the Authorization Capabilities spec onto the
>>>>>> standards track, because that's what these agentic AI systems should
>>>>>> be using to do delegated actions on behalf of their controllers...
>>>>>> that Verified Bots stuff that Cloudflare is doing is something along
>>>>>> these lines (so all isn't hopeless).
>>>>>>
>>>>>> > There are so many of these projects from so many organizations that
>>>>>> there's no way I can explain the issues to them one by one.  Is there
>>>>>> something the VC standards group can do?
>>>>>>
>>>>>> Speaking from a practical point of view -- no, not right now, because
>>>>>> we have too many other higher priority items that need to get done.
>>>>>> The only thing that solves that are more people volunteering to do
>>>>>> work around authorization capabilities and push that work forward, and
>>>>>> unless that happens, we'll just see another wave of
>>>>>> well-meaning-but-misguided young developers misusing authentication
>>>>>> technology for authorization use cases.
>>>>>>
>>>>>> I have suggested to W3C that they create a security technologies group
>>>>>> that can move the Data Integrity and ZCAP stuff forward, but they'd
>>>>>> need to hire more staff and the budget just isn't there to do that
>>>>>> right now.
>>>>>>
>>>>>> So, we're left with where we are right now -- the folks that get specs
>>>>>> done will have to get the higher priority ones done and when those are
>>>>>> done, move the authorization capability stuff forward. No one likes
>>>>>> that plan, but realistically, that's where we are right now without
>>>>>> more volunteers (on the CCG/VCWG side) and funding (on the W3C side).
>>>>>>
>>>>>> All that said, I completely understand and empathize with your
>>>>>> frustration, Alan... I'm in the same boat as you. We can't engage with
>>>>>> everyone that mixes up authentication with authorization and tries to
>>>>>> use VCs for both of those things.
>>>>>>
>>>>>> -- manu
>>>>>>
>>>>>> --
>>>>>> Manu Sporny - https://www.linkedin.com/in/manusporny/
>>>>>> Founder/CEO - Digital Bazaar, Inc.
>>>>>> https://www.digitalbazaar.com/
>>>>>>
>>>>>>