Re: Signs of adoption of CCG specifications

For privacy and human rights reasons, delegation should be the default. The
alternative enables the kind of surveillance that our community is
committed to avoiding.

-Adrian


On Thu, Jul 31, 2025 at 2:30 PM David Chadwick <d.w.chadwick@truetrust.co.uk>
wrote:

>
> On 30/07/2025 20:43, Dave Longley wrote:
>
> On Wed, Jul 30, 2025 at 3:03 PM Adrian Gropper <agropper@healthurl.com> <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.
>
> Of course, if the authz service front ends the resource, it can directly
> request the resource from the backend service, and return it directly to
> the requestor rather than sending it an authz token. This is how RBAC and
> ABAC systems often work. Its more efficient, especially when delegation is
> not needed.
>
> Kind regards
>
> David
>
>
>
> 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.
>
>
>