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]
