Re: Signs of adoption of CCG specifications

 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.

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