Fwd: Signs of adoption of CCG specifications

[Alan Karp]

A recent exchange on a W3C mailing list.

--------------
Alan Karp

---------- Forwarded message ---------
From: Manu Sporny <msp...@digitalbazaar.com>
Date: Wed, Jul 30, 2025 at 9:00 AM
Subject: Re: Signs of adoption of CCG specifications
To: Alan Karp <alan...@gmail.com>
Cc: W3C Credentials CG <public-cr...@w3.org>

On Wed, Jul 30, 2025 at 11:29 AM Alan Karp <alan...@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/

[John Carlson]

I heard someone was offering OAuth for AI agents.  Like 5 kinds of OAuth.

Sounded like they figured it out, but I didn’t seek further.

Maybe this is it, 18 hours ago:  

https://youtu.be/EXxIeOfJsqA

John 

--
You received this message because you are subscribed to the Google Groups "cap-talk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to cap-talk+u...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/cap-talk/CANpA1Z0rP%2Bm91UjAqGNZKr%3DQs_zhc2rYakjQzvXptHK368HULA%40mail.gmail.com.

[Alan Karp]

As they say in the video, they are using OAuth 2.1, which is OAuth 2.0 with all the mistakes removed.  Well, not all, since 2.1 still uses Client Secret.

It's clear to me that they don't quite grasp the possibilities.  For one example, they talk about an AI agent acting on behalf of an enterprise employee.  The agent is allowed to use 20 different MCP tools, so they simply give it that much permission, independent of which employee is using it.  That might include sensitive databases that only some employees are allowed to use.  A properly designed system would give the employee capabilities for the 10 tools she's allowed to use and have her delegate the subset she wants used to the AI agent.

--------------
Alan Karp

To view this discussion visit https://groups.google.com/d/msgid/cap-talk/CAGC3UEkcEZj4Xd4wz8RvdCjZfV-WRdOgVmm5X70YR-dd5CycSg%40mail.gmail.com.

[John Carlson]

That makes sense.  Like I try to say to my wife.

To view this discussion visit https://groups.google.com/d/msgid/cap-talk/CANpA1Z1Oj1oTZBrdsyoPW-bmnz4rPbQaMfPkLvtfwa2X8nFw3w%40mail.gmail.com.

[Alan Karp]

(Adding cap-talk back into the discussion. My bad for dropping it.)

--------------
Alan Karp

On Mon, Aug 4, 2025 at 12:23 PM David Chadwick <d.w.ch...@truetrust.co.uk> wrote:

On 04/08/2025 18:06, Alan Karp wrote:

Is there a reason you didn't continue the discussion on cap-talk?

On Sun, Aug 3, 2025 at 2:14 PM David Chadwick <d.w.ch...@truetrust.co.uk> wrote:

Because you can invoke a method with one capability granted to you and another capability delegated to you by whoever invoked you.

You are missing the point. The requestor sends a bunch of VCs to the gatekeeper asking for access to resource X, who, in your case gets a capability back. The requestor then sends this capability to X to access the resource and gets the result back. In my case, the gatekeeper accesses resource X and returns the result back to the requestor. This is more efficient.

So there is no confused deputy in either case, or there is in both cases. There is no difference except in efficiency

What if X is something that Alice has asked the requestor to access? 

Alan, please access the bank and send me the money. Does this sound like something you would do for me? I think not.

That's almost exactly what happens when you present a check to Alan the bank teller.  The check is your authorization (capability) to collect the specified amount of money from that account.  You can make it work with ACLs, but you'd probably need to set up an account at my bank.

The access decision is based on the requestor's credentials, not Alice's.  In many cases, you want the requestor to forward the result to Alice, e.g., a web server, but there are times when the decision should be based on Alice's credentials, not the requestor's.  While there are many checks you can do to prevent the error, it's a hazard that you must deal with.

There are lots of scenarios we can think of where users can do dumb (or illegal) things, or programmers can program in errors by mistake. You cannot avoid this. You are simply specifying one of them.

I call them "hazards' because they're something your system needs to deal with.  In my recent Stanford talk I walk through about 10 of them and describe how you can handle them either with ACLs or with capabilities..  In every case, the ACL approach can be made to work but with much more complexity than with capabilities (or in one case violating the law).  For example, you can implement delegation by changing the ACL, but logs generally only show who made the change, not who asked for it.  As a result, you don't know who has permission to revoke access.

You earlier stipulated a "no delegation" scenario, but I think delegation is impossible to avoid.  We give permissions to people, but they are not in the computer; the programs they run are.  That means you are delegating every time you run a program.  In today's non-mobile OSs, that takes the form of impersonation, a particularly crude form of delegation.  Polaris did better than that without capabilities at some cost in complexity.  Things are far easier if the OS and applications are capability aware, as shown by CapDesk.

--------------
Alan Karp