- From: Dave Longley <dlongley@digitalbazaar.com>
- Date: Wed, 30 Jul 2025 15:43:04 -0400
- To: Adrian Gropper <agropper@healthurl.com>
- Cc: Alan Karp <alanhkarp@gmail.com>, Manu Sporny <msporny@digitalbazaar.com>, W3C Credentials CG <public-credentials@w3.org>
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.
Received on Wednesday, 30 July 2025 19:43:25 UTC