Re: Signs of adoption of CCG specifications

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/
>>>
>>>