Hi Gareth, I think the problem of delegation of claims would be great to solve and that this is an elegant design for the short-lived delegation use case.
What I'm a little bit more concerned about is revocation for longer lived delegation. For agentic uses this is probably not that relevant, but thinking about e.g. power of attorney use cases I can imagine that this would quickly become a problem. You call this out in the draft and the presentation of course, but do you have any ideas for how we could solve this beyond saying that the lifetime should be short? I think leaving it at that limits the use cases quite a lot (or it could lead people to use this for flows where it is not really appropriate if they don't think about it enough). Cheers, Frederik On Thu, 25 Jun 2026 at 18:12, Gareth Oliver <[email protected]> wrote: > Hi everyone, > > I would like to bring an individual draft, "Delegate SD-JWT," to the > working group's attention and request your feedback, with the eventual goal > of considering it for WG adoption. > > *Overview of the Draft:* This document specifies an extension to > Selective Disclosure JSON Web Tokens (SD-JWT) to support delegation from a > Holder to a Delegate Holder. It achieves this by allowing the Key Binding > JWT (KB-JWT) to also function as an SD-JWT in its own right. This composite > structure enables chaining these SD-JWTs together, optionally allowing the > Delegate Holder their own cryptographic proof-of-possession. > > *Context: * > > Two use cases for the Delegate SD-JWTs: > > *Agentic Systems (e.g. AP2, and Verifiable Intent):* The original driver > for this extension is establishing "Verifiable Intent" for AI and agentic > systems, particularly within the context of the Agent Payment Protocol > (AP2) protocol. > > The architecture here is that the user has a credential issued to them as > an SD-JWT+KB and wishes to delegate it to an Agent under some set of > constraints. The Agent can then autonomously re-present a subset of these > constraints to prove it is authorized to make a purchase without needing to > bring the user back into the loop. (e.g., authorize the payment using a > particular form of payment up to $100 at one of five merchants when an item > comes back into stock, without revealing the other merchants). Delegating > the already-issued Digital Payment Credential (or other User Credential) > provides a mechanism for solving this problem using something that is > already useful for non-agentic payments. > > *Delegated Credentials* > > Another potential use case involves traditional VDCs where a Holder wishes > to give the limited use of a Credential (e.g., Powers of Attorney, shared > motor vehicle certificate) without involving the individual issuer. > > *Links* > > - > > *Datatracker:* > https://datatracker.ietf.org/doc/draft-gco-oauth-delegate-sd-jwt/ > - > > *GitHub:* https://github.com/GarethCOliver/gco-delegate-sd-jwt > - > > Attached OSW presentation > > I would appreciate it if folks could review the draft. I'm looking forward > to hearing your thoughts on the approach and whether the WG would be > interested in adopting this work. > > Thanks, > > Gareth Oliver > _______________________________________________ > OAuth mailing list -- [email protected] > To unsubscribe send an email to [email protected] >
_______________________________________________ OAuth mailing list -- [email protected] To unsubscribe send an email to [email protected]
