Hi Gareth, As discussed at OSW, I believe this is an important and interesting topic, especially in the age of everything becoming an agent!
Imho the bigger open discussion points when using a chained credential approach are: - policy language (how to restrict usage of a delegated credential) - revocation (how to withdraw the delegation) - notifications (but this is probably more on the protocol than on the credential format side) But those are topics are mentioned in the draft and we can solve them over time - the current draft is imho a good starting point. Best Regards, Christian > On 25. Jun 2026, at 18:07, 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 > > <Delegate SD-JWTs.pdf>_______________________________________________ > 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]
