Hi Yuan, Thanks for the interest! Regarding the other delegation-related drafts, I think they are operating on different layers. Those drafts describe how, using existing OAuth primitives, you can perform delegations within a protocol flow.
In contrast, the delegate SD-JWT draft describes a new format primitive (an extension to SD-JWT) which can then be utilized by protocols to perform delegation with selective disclosure. It's analogous to SD-JWT and JWT. Because it sits at the format layer, it is out of scope of the draft as to why a verifier would trust claims added by the holder or delegate holder. An example of how a protocol could use this can be found in AP2 Protocol <https://ap2-protocol.org/> and Verifiable Intent <https://verifiableintent.dev/> (now adopted by FIDO to be standardized). Here, the Holder is the owner of the payment instrument, and the added claims specify how they want their card to be used. The Holder is authoritative over this, so the merchant trusts these added claims and trusts that the presenter is the legitimate holder because they trust the initial issuer to have provisioned into a trustworthy wallet. This is how I'd expect to see this used in other digital identity use cases as well. There may also be interesting opportunities to use the delegate SD-JWT primitive within the Token Exchange model. Rather than using a JWT chain, using a delegate SD-JWT enables selective disclosure. Issuing an SD-JWT is essentially equivalent to issuing a new JWT for each possible permutation of disclosures. The main question is why you would want to issue this in advance, rather than simply going back and getting a tightly scoped JWT from the source when needed. In digital identity cases, this is done for privacy and availability; in the delegated agentic payment case, it was primarily about availability. Availability or performance, combined with privacy, might be a compelling reason. It's an interesting topic to consider, and having the delegate SD-JWT format available makes it possible, though it remains independent of this specific draft. The area of overlap I do see is in common constraint and policy declarations. The current delegate SD-JWT draft does not specify any policies, intentionally leaving that to the protocol and application layers. One of the requests we’ve received is for some common policy structures to be defined. We should make sure not to duplicate work here, ensuring that application-agnostic delegation policies are defined once and then referenced as needed across these drafts. Let me know if this makes sense, and if you have follow-up questions! Cheers, Gareth
_______________________________________________ OAuth mailing list -- [email protected] To unsubscribe send an email to [email protected]
