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] <[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 <frederik.krogsdal= > [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] <[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] > > > _______________________________________________ > 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]
