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