Re: Signs of adoption of CCG specifications

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