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]> 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] > To unsubscribe send an email to [email protected]
_______________________________________________ OAuth mailing list -- [email protected] To unsubscribe send an email to [email protected]
