Thanks a lot, really appreciate you taking a look! Totally agree, what I'm doing is pretty much a special case of Delegate SD-JWT, so I'd rather build on yours than reinvent it. I'll rework the delegation part on top of it for -01. Any plans to renew the draft? Would be great to be able to point to it.
And thanks for the AP2 tip, didn't know it had moved to FIDO. Feels like they fit together nicely: in B2B the invoice usually comes before the payment, so an agent could accept an invoice with an ITP mandate and then pay it with an AP2 one. Would love to see how we can line them up, happy to chat anytime. Cheers, Carlos > El 30 oct 2026, a las 10:58, Gareth Oliver <[email protected]> escribió: > > Hi Carlos, > Took a quick look through. Delegate SD-JWT should be a good fit, it is a > generalized form of what you are doing with regard to delegation (using an > existing SD-JWT and it's 'cnf' as the signer of a new SD-JWT) just formulated > a little different. You may be interested in taking a look at > https://ap2-protocol.org/, which is now undergoing further standardization > inside FIDO. It aims to solve this problem in the payments/commerce space > (albeit with a focus toward b2c. There is probably a lot we can adapt and > learn from one another. > > cheers, > Gareth > > On Fri, Oct 30, 2026 at 1:57 AM [email protected] > <mailto:[email protected]> <[email protected] > <mailto:[email protected]>> wrote: >> Hi Frederik, >> >> Thanks a lot for taking the time, this is super helpful! >> >> You're right about the audience claim, it's not clear enough. The idea is >> that counterparties don't check the limits themselves: they check the >> agent's signature plus the "delegated-issuer" and "operator-seal” signatures >> from the enforcing node, and trust that seal. Right now that's scattered >> across Sections 4 and 9, so I'll give it its own subsection in -01. >> >> Good to hear the delegation approach looks fine. If there are one or two of >> those other attempts you'd align with, I'd love to know. >> >> The privacy point is a great catch, and I think you're right it could block >> adoption. The worst case today is a delegated mandate, since it carries its >> parent with all its disclosures. Thanks for the Delegate SD-JWT pointer, >> I'll dig into it. >> >> On how the mandate is used, the presentation goes inside the signed envelope >> or status message, and the agent signs the whole thing with the key in "cnf" >> (Section 4). But I agree the draft needs a bit of context from the core up >> front, it doesn't really stand on its own yet. >> >> On reuse, the real protection is meant to be the one-time nonce in the Key >> Binding JWT, and the "use" window is just a backstop. The text makes it look >> the other way round, so I'll fix that and probably drop the window. >> >> And Deferred Token Response sounds like it could fit really well for the >> approval part. I'll wait for your -01 and take a proper look. >> >> Thanks again! >> Carlos >> >>> El 30 oct 2026, a las 8:28, Frederik Krogsdal Jacobsen >>> <[email protected] >>> <mailto:[email protected]>> escribió: >>> >>> Hi Carlos, >>> >>> I gave the draft a quick look, but didn't look into the other drafts >>> mentioned, so take these comments with a grain of salt :-) >>> >>> Regarding the audience claim, I think the draft is quite vague about how >>> the other parties process the mandate. At least it's not clear to me, so >>> perhaps some elaboration on that would make it easier to evaluate whether >>> it makes sense. >>> I think the attenuated delegation you describe is basically fine, though >>> the draft will probably need to eventually define the rules in some more >>> detail. I think there are a number of attempts at drafts for this type of >>> mechanism, but no real consensus on what to do yet. >>> The privacy considerations bring up a very valid point which I think might >>> be a pretty big blocker for adoption. It might be necessary for adoption to >>> think more about how to prevent systematic enumeration of the entire >>> purchasing policy. >>> You might get some inspiration in the (expired) Delegate SD-JWT draft: >>> https://datatracker.ietf.org/doc/draft-gco-oauth-delegate-sd-jwt/ >>> >>> It's not clear to me how the mandate is actually bound to the invoice >>> itself, i.e. how is it actually used? I assume the "use" claim is supposed >>> to go into the invoice itself somehow. But perhaps this is described in the >>> other drafts. I think some brief context would make this document more >>> readable. >>> I'm also not entirely convinced of the reuse protection since it allows for >>> a lot of clock drift. Perhaps a stricter one-time only mechanism would be >>> more appropriate for this use case? >>> >>> For the "approval by a person" feature, I would be interested in hearing >>> whether you think Deferred Token Response would fit your use case. It is >>> supposed to be a general-purpose mechanism for this kind of flow. We will >>> publish a -01 version with substantial changes soon (merging the DTR and >>> JAG-IR drafts), so I would wait a few days before looking at it in depth. >>> >>> Cheers, >>> Frederik Krogsdal Jacobsen >>> Staff Engineer, Identity Standards >>> IDURA <https://idura.eu/> >>> On Thu, 29 Oct 2026 at 19:34, [email protected] >>> <mailto:[email protected]> <[email protected] >>> <mailto:[email protected]>> wrote: >>>> Hi all, >>>> >>>> I've published draft-martinez-itp-agent-mandates, part of the Invoice >>>> Trust Protocol (ITP) drafts posted to DISPATCH this week: >>>> >>>> https://datatracker.ietf.org/doc/draft-martinez-itp-agent-mandates/ >>>> >>>> It lets a business authorize a software agent to issue, accept, reject or >>>> dispute invoices within limits it sets. The authorization is a >>>> mandate: an SD-JWT VC issued by the business to a key held by the agent, >>>> revocable through a status list, and enforced by a single named node that >>>> records every use, so the limits hold even if the agent misbehaves. >>>> >>>> I'm not asking the WG to take this on. I'd just like feedback from people >>>> who know these specs well, mainly on three points: >>>> >>>> 1. Using "aud" to name the enforcing node while other relying parties >>>> still process the mandate (Section 3). >>>> 2. Attenuated delegation from one agent to another (Section 6). >>>> 3. Whether this overlaps with work already going on here, such as Rich >>>> Authorization Requests or Token Exchange, in a way I've missed. >>>> >>>> Thanks, >>>> Carlos Martínez García-Villarrubia >>>> BeeL. >>>> _______________________________________________ >>>> OAuth mailing list -- [email protected] <mailto:[email protected]> >>>> To unsubscribe send an email to [email protected] >>>> <mailto:[email protected]> >>> _______________________________________________ >>> OAuth mailing list -- [email protected] <mailto:[email protected]> >>> To unsubscribe send an email to [email protected] >>> <mailto:[email protected]> >> >> _______________________________________________ >> OAuth mailing list -- [email protected] <mailto:[email protected]> >> To unsubscribe send an email to [email protected] >> <mailto:[email protected]>
_______________________________________________ OAuth mailing list -- [email protected] To unsubscribe send an email to [email protected]
