Tania — A qualified yes: a Mission should be able to carry an optional, opaque provenance reference — but only if the reference distinguishes the standing policy or delegation behind an approval from the specific decision that authorized this action.
Two anchors from draft-luna-eagf-agent-delegation-semantics-00. REQ-2 requires an Action to reference the organizational Decision that authorized it, or an explicit rule that no Decision was required; an agent Recommendation alone does not satisfy it. And the draft's security considerations add that Decision references must be bound to scope and time, so a past Decision cannot authorize a later, different Action. That second point is where an untyped pointer fails, in my view: 1. A reference to standing policy proves a class was permitted. It does not prove this action instance was adopted under it. That is the same class/instance collapse seen in the WIMSE approval-reuse discussion, where approval granted for one action was consumed by another with identical requester and delegation. 2. Procurement makes the two levels observable. A standing policy may grant order-class authority up to a cap; the decision adopting this order, at this price, from this supplier is a separate fact. The UC7 case you cite has the same shape: payment authority traces to an adjudication decision, not only to the delegation path. 3. Opacity is what keeps this inside OAuth's remit: the governance layer stays outside the artifacts; only a checkable pointer travels. Concrete suggestion: type the reference — policy-ref versus decision-ref — and for a decision-ref, require the scope-and-time binding the Luna draft already states. My question back: if a Mission can carry only one provenance pointer, would the group prefer it to name the decision instance, with the standing policy reachable from that decision record out of band? Jiahui Miao Founder, vertciti (VERTCITY LLC) On Wed, 21 Oct 2026 07:08:59 -0700, Tania Aizenman <[email protected]> wrote: > Hi all, > > Ahead of the Mission interim on 26 Oct, here is a pointer and a question. I > work with Alygn, and our colleague David Luna is the author of an > individual Internet-Draft (work in progress), not a standard and not > endorsed by the IETF, posted on Monday, 19 October: > > draft-luna-eagf-agent-delegation-semantics-00 > https://www.google.com/url?q=https://datatracker.ietf.org/doc/draft-luna-eagf-agent-delegation-semantics/&source=gmail&ust=1792678139638000&sa=E > > It states requirements from EAGF, an open candidate specification under > public review (not a standard). It defines no protocol, token format or > claim. > > Why it may be relevant here: Mission-00 §6.2 lists "approval-authority > provenance (the standing policy or delegation an administrator or headless > approval traces back to)" as out of scope and "left to a governance layer". > The draft tries to state what that layer must preserve: > > - REQ-2 (Decision Reference): an Action taken for an organization > references the organizational Decision that authorized it, or an explicit > rule that no Decision was required. An agent recommendation alone does not > satisfy it. > - REQ-6 (Accountable Owner): an agent that receives authority through > delegation has an identifiable accountable owner. Accountability is not > inferred solely from causality or from who performed the Action. > > The use-cases draft's UC7 (insurance claim) shows the same gap. The payment > authority comes from the insurer's adjudication decision, not only from the > Customer -> A -> B -> C -> D delegation path. > > Question for the group: should a Mission be able to carry an optional, > opaque reference (for example a digest) to the decision or policy behind a > delegated approval, so a relying party can check provenance out of band? Or > is that better kept entirely outside OAuth artifacts? > > Critique is very welcome, on list or at the interim. > > Thanks, > Tania > Alygn · [email protected] _______________________________________________ OAuth mailing list -- [email protected] To unsubscribe send an email to [email protected]
