Re: Signs of adoption of CCG specifications

Thanks, Dave. I agree with your general summary. In our specific HIE of One
implementation, the authorization server and resources are running RFC
9635-GNAP. The VC is never used for authorization so I think we are all in
total agreement and no standards crime is being committed.

What is more interesting these days as we continue to push the boundaries
of standards for personal agency is the interaction of agents and protected
resources via MCP and A2A. The need for attenuated delegation when using
powerful LLM-enabled agents as authorization servers to protect one's
resources seems to be beyond the scope of current standards work.
Agntcy might be a place to have this discussion.

Adrian


On Wed, Jul 30, 2025 at 3:43 PM Dave Longley <dlongley@digitalbazaar.com>
wrote:

> On Wed, Jul 30, 2025 at 3:03 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.
>
> As a general response to how to put VCs and authorization capabilities
> together:
>
> An authorization request should result in one or more authorization
> capabilities that can be invoked at specific resources. It's fine (and
> expected) to present one or more VCs as part of an authorization
> request made to some service that applies a policy to evaluate the
> VC(s) (and maybe other information) to determine whether authorization
> should be granted to particular resources. But the result of that
> request should be one or more authorization capabilities that can then
> be (cryptographically) invoked at the resources they specify. They can
> also then be delegated (with optional attenuation) or revoked.
>
> If you have a system that isn't yet able to use authorization
> capabilities to gain their cryptographic, delegation, or revocation
> benefits, a stop gap measure is to instead return action- and
> resource-bound access tokens (this can be done with scopes with
> oauth2, for example). This is an improvement over access tokens that
> are either unscoped or too widely scoped, but you still generally have
> a bearer token that can't be delegated with attenuation or (usually)
> simply revoked.
>
> --
>
> Dave Longley
> CTO
> Digital Bazaar, Inc.
>