Workload Identity in Multi System Environments C. Hulea Internet-Draft Braincap SRL Intended status: Standards Track 1 November 2026 Expires: 5 May 2027 Verifiable Mandates for Agents Acting Across Administrative Domains draft-hulea-wimse-agent-mandate-01 Abstract This document defines how a relying party in one administrative domain validates the mandate under which a software agent, including an AI agent, acts for a principal in another domain. Its distinctive element is evidence of the delegator's authority: a statement from an authority source about which permissions the person or entity granting the mandate may delegate to agents, kept separate from the statement that the mandate was granted. The document specifies the mandate format with precisely defined limit semantics, a deterministic validation procedure driven by an explicit validation profile and kept separate from the relying party's authorization decision, the attribution of every validated claim to the issuer and role that asserted it, rules for enforcing the mandate after token exchange, and the boundary between this protocol and a trust framework. It reuses JSON Web Tokens, OAuth 2.0 Token Exchange, Rich Authorization Requests, WIMSE workload credentials and HTTP Message Signatures, Token Status Lists, and Entity Attestation Tokens. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on 5 May 2027. Hulea Expires 5 May 2027 [Page 1] Internet-Draft Agent Mandates November 2026 Copyright Notice Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Goals . . . . . . . . . . . . . . . . . . . . . . . . . . 4 1.2. Non-Goals . . . . . . . . . . . . . . . . . . . . . . . . 5 2. Conventions and Definitions . . . . . . . . . . . . . . . . . 5 3. Architecture Overview . . . . . . . . . . . . . . . . . . . . 6 4. Mandate Assertion . . . . . . . . . . . . . . . . . . . . . . 8 4.1. Claims . . . . . . . . . . . . . . . . . . . . . . . . . 8 4.2. Party Identifiers . . . . . . . . . . . . . . . . . . . . 9 4.3. Artifact References . . . . . . . . . . . . . . . . . . . 9 4.4. Permissions . . . . . . . . . . . . . . . . . . . . . . . 9 4.5. Constraints . . . . . . . . . . . . . . . . . . . . . . . 10 4.6. JSON Identity . . . . . . . . . . . . . . . . . . . . . . 12 4.7. Attenuation . . . . . . . . . . . . . . . . . . . . . . . 12 4.8. Sub-Delegation . . . . . . . . . . . . . . . . . . . . . 13 5. Authority Assertion . . . . . . . . . . . . . . . . . . . . . 14 6. Agent Instance Evidence . . . . . . . . . . . . . . . . . . . 15 6.1. Workload Identity Token . . . . . . . . . . . . . . . . . 15 6.2. Attestation Result . . . . . . . . . . . . . . . . . . . 16 6.3. Exposure Statement . . . . . . . . . . . . . . . . . . . 16 7. Mandate Presentation . . . . . . . . . . . . . . . . . . . . 17 7.1. Token Exchange Request . . . . . . . . . . . . . . . . . 17 7.2. Proof of Possession . . . . . . . . . . . . . . . . . . . 18 8. Validation Profile . . . . . . . . . . . . . . . . . . . . . 18 8.1. Type Profiles . . . . . . . . . . . . . . . . . . . . . . 20 9. Mandate Validation Procedure . . . . . . . . . . . . . . . . 21 9.1. Inputs . . . . . . . . . . . . . . . . . . . . . . . . . 21 9.2. Required and Optional Evidence . . . . . . . . . . . . . 22 9.3. Procedure . . . . . . . . . . . . . . . . . . . . . . . . 22 9.4. Authority Check . . . . . . . . . . . . . . . . . . . . . 26 9.5. Obligations . . . . . . . . . . . . . . . . . . . . . . . 27 9.6. Validation Result . . . . . . . . . . . . . . . . . . . . 28 10. Authorization and Enforcement . . . . . . . . . . . . . . . . 30 Hulea Expires 5 May 2027 [Page 2] Internet-Draft Agent Mandates November 2026 10.1. Authorization Decision . . . . . . . . . . . . . . . . . 30 10.2. Access Token . . . . . . . . . . . . . . . . . . . . . . 31 11. Attribution of Claims . . . . . . . . . . . . . . . . . . . . 32 12. Boundary with the Trust Framework . . . . . . . . . . . . . . 34 12.1. Provided by This Protocol . . . . . . . . . . . . . . . 34 12.2. Defined by a Trust Framework . . . . . . . . . . . . . . 34 12.3. Configured by the Relying Party . . . . . . . . . . . . 35 13. Security Considerations . . . . . . . . . . . . . . . . . . . 35 14. Privacy Considerations . . . . . . . . . . . . . . . . . . . 37 15. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 37 15.1. Media Types . . . . . . . . . . . . . . . . . . . . . . 37 15.2. JSON Web Token Claims . . . . . . . . . . . . . . . . . 37 15.3. OAuth Registrations . . . . . . . . . . . . . . . . . . 37 15.4. Agent Mandate Constraint Predicates . . . . . . . . . . 37 15.5. Agent Mandate Validation Codes . . . . . . . . . . . . . 38 15.6. Agent Exposure Event Types . . . . . . . . . . . . . . . 39 16. References . . . . . . . . . . . . . . . . . . . . . . . . . 39 16.1. Normative References . . . . . . . . . . . . . . . . . . 39 16.2. Informative References . . . . . . . . . . . . . . . . . 41 Appendix A. Example . . . . . . . . . . . . . . . . . . . . . . 44 Appendix B. Conformance Cases . . . . . . . . . . . . . . . . . 47 Appendix C. Relationship to Other Work . . . . . . . . . . . . . 52 Appendix D. Open Issues . . . . . . . . . . . . . . . . . . . . 54 Changes from -00 . . . . . . . . . . . . . . . . . . . . . . . . 55 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 56 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 56 1. Introduction Software agents increasingly act on behalf of people and organizations in systems those people and organizations do not operate. A treasury agent run by a company initiates a payment at the company's bank. An agent run by a broker submits an instruction to a custodian. In each case the relying party has to decide whether to accept an action from an agent configured, authorized, and operated in another administrative domain. Hulea Expires 5 May 2027 [Page 3] Internet-Draft Agent Mandates November 2026 Most building blocks exist. OAuth 2.0 Token Exchange [RFC8693] exchanges security tokens, including across security domains, and distinguishes the subject on whose behalf a request is made from the actor that makes it. Rich Authorization Requests [RFC9396] express fine-grained permissions. WIMSE workload credentials [I-D.ietf-wimse-workload-creds] bind a workload identifier to a key. Work on agents is advancing quickly: [I-D.ietf-wimse-aims] describes how existing standards apply to agent authentication and authorization, [I-D.asor-wimse-agent-delegation-chain] and [I-D.hamr-oauth-agent-delegation] define attenuated delegation chains, and [I-D.reece-wimse-cross-org-delegation] and [I-D.yossif-agent-mandate-problem] state requirements for cross- organization delegation and for verifiable mandates (Appendix C). What is not yet defined is evidence that the party at the root of a mandate was entitled to grant it. A chain that only narrows proves that no hop exceeded its parent. It does not prove that the root was within the delegator's own authority, for example within the powers of a company's legal representative. This document adds that evidence, validates it together with the mandate under explicit rules, and keeps each claim attributed to the issuer that made it. 1.1. Goals 1. *Interoperable mandate semantics.* Independent implementations understand and check the same things: the structure of the mandate, the semantics of its limits, the delegation chain, the binding to a key, and revocation status (Section 4, Section 4.5). 2. *Validation separate from authorization.* Given the same inputs, including the same validation profile, two conforming Validators produce the same Validation Result. The relying party then applies its own policy (Section 9, Section 10.1). 3. *Attribution of claims to issuers.* The delegator's authority, the grant of the mandate, the operator's statement about the agent instance, and the state of the runtime come from different issuers. A relying party can tell exactly who asserted what (Section 11). 4. *A clear boundary with the trust framework.* This document defines how evidence is expressed and verified. Which issuers are accepted, what assurance levels mean, and which obligations issuers assume belong to a trust framework (Section 12). Hulea Expires 5 May 2027 [Page 4] Internet-Draft Agent Mandates November 2026 1.2. Non-Goals This document does not: * determine whether an agent's reasoning or output is correct, or whether an action reflects the principal's present intent; * define a trust framework, assurance levels, or the legal effect of a mandate; * define how a delegator is shown a mandate or consents to it; * replace the relying party's authorization policy. 2. Conventions and Definitions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. Principal: The natural or legal person on whose behalf an agent acts. Delegator: The party that grants a root mandate: the principal itself, or a party holding authority to act for the principal. Authority Source: A party that asserts that a delegator holds authority to act for a principal, for example a register of legal representatives. Operator: The organization that runs an agent instance and controls its keys. Agent Instance: A running workload, identified by a workload identifier [I-D.ietf-wimse-arch], that holds a private key. Mandate Issuer: The entity that signs a root Mandate Assertion on the delegator's instruction. It may be the delegator itself. Mandate Assertion: A signed JWT expressing a mandate (Section 4). A root Mandate Assertion is signed by a Mandate Issuer; a sub- delegated one by the agent instance holding the parent mandate. Root, leaf: In a chain of Mandate Assertions linked by parent, the Hulea Expires 5 May 2027 [Page 5] Internet-Draft Agent Mandates November 2026 root is the assertion without parent, signed by a Mandate Issuer; the leaf is the assertion held by the presenting agent instance and sent as subject_token. A chain of one mandate has the same assertion as root and leaf. Authority Assertion: A signed JWT or SD-JWT [RFC9901] issued by an Authority Source (Section 5). Mandate Presentation: The artifacts an agent instance presents to a relying party (Section 7). Relying Party (RP): The entity in another administrative domain that receives the action request. In this document the RP's authorization server hosts the Validator and issues access tokens. Validator: The RP component that executes the Mandate Validation Procedure. Validation Profile: A versioned document that fixes every rule the Validator applies beyond this specification (Section 8). Trust Framework: The set of rules, identified by a URI, under which issuers are accepted and evidence is interpreted (Section 12). Obligation: A condition that the Validator cannot evaluate from its inputs and that the RP has to discharge before it allows the action. Budget: A named cumulative limit shared by all actions under the same root mandate that refer to it (Section 9.5). 3. Architecture Overview Hulea Expires 5 May 2027 [Page 6] Internet-Draft Agent Mandates November 2026 +-----------+ Authority +-----------+ | Authority |------------->| Delegator | | Source | Assertion +-----+-----+ +-----------+ | instructs v +-----------+ | Mandate | | Issuer | +-----+-----+ +-----------+ Workload | Mandate Assertion | Operator |------------->+-----v-----+ +-----------+ Identity | Agent | Token | Instance | +-----------+ Attestation | | | Verifier |------------->| | +-----------+ Result +-----+-----+ | Mandate Presentation, | signed HTTP request v +-----------+ Validation +-----------+ | Validator |------------->| RP | +-----------+ Result | Policy | +-----------+ Figure 1: Roles and artifacts 1. An Authority Source issues an Authority Assertion stating that the delegator may act for the principal within stated powers. 2. A Mandate Issuer, on the delegator's instruction, issues a root Mandate Assertion bound to the agent instance's key and referencing the Authority Assertion. 3. The operator issues the agent instance a Workload Identity Token (WIT) [I-D.ietf-wimse-workload-creds] for the same key. A RATS Verifier [RFC9334] MAY issue an attestation result. 4. The agent instance sends a token exchange request carrying the evidence and the requested action, signed with its key (Section 7). 5. The Validator executes the Mandate Validation Procedure under a Validation Profile. The RP applies its policy, discharges Obligations, and issues a single-use access token (Section 10). An agent instance MAY delegate a narrower mandate to another agent instance (Section 4.8). Hulea Expires 5 May 2027 [Page 7] Internet-Draft Agent Mandates November 2026 4. Mandate Assertion A Mandate Assertion is a JWT [RFC7519] signed as a JWS [RFC7515]. The JOSE header typ value MUST be mandate+jwt. Implementations MUST follow [RFC8725]. The algorithm MUST be one permitted by the Validation Profile. 4.1. Claims iss: REQUIRED. Identifier of the Mandate Issuer, or, for a sub- delegated mandate, the workload identifier of the delegating agent instance. sub: REQUIRED. Workload identifier of the agent instance that holds the mandate. jti: REQUIRED. Unique identifier of the assertion. iat, nbf, exp: REQUIRED. As defined in [RFC7519]. cnf: REQUIRED. Confirmation claim [RFC7800] containing a jkt member, the JWK SHA-256 thumbprint [RFC7638] of the holder's public key. principal: REQUIRED. A Party Identifier (Section 4.2) for the principal. delegator: REQUIRED. A Party Identifier for the delegator. In a sub-delegated mandate, a Party Identifier for the delegating agent instance. authority: In a root mandate, REQUIRED unless delegator equals principal, in which case it MUST NOT appear; an array of Artifact References (Section 4.3) to Authority Assertions. The references are alternatives: one supporting assertion establishes authority (Section 9.4). MUST NOT appear in a sub-delegated mandate. perms: REQUIRED. A non-empty array of Permission objects (Section 4.4). parent: REQUIRED in a sub-delegated mandate; MUST NOT appear in a root mandate. An Artifact Reference to the parent Mandate Assertion. max_depth: OPTIONAL. Non-negative integer: the number of further sub-delegations permitted below this mandate. Default 0. aud: OPTIONAL. Array of RP identifiers to which the mandate may be Hulea Expires 5 May 2027 [Page 8] Internet-Draft Agent Mandates November 2026 presented. status: OPTIONAL. Status reference as defined in [I-D.ietf-oauth-status-list]. The Validation Profile states when it is required. tf: REQUIRED. URI of the Trust Framework under which the assertion was issued. loa: OPTIONAL. Assurance level asserted by the issuer. Its meaning is defined by the Trust Framework; the Validator reports it and does not interpret it. 4.2. Party Identifiers A Party Identifier is a JSON object with two REQUIRED string members: id, and scheme, a URI naming the identifier scheme. Two Party Identifiers are equal if and only if both members are equal as sequences of Unicode code points. 4.3. Artifact References An Artifact Reference is a JSON object with a REQUIRED member dig, the base64url-encoded SHA-256 digest of the ASCII bytes of the referenced artifact's compact JWS serialization. For an SD-JWT, the digest is computed over the issuer-signed JWT only. The OPTIONAL members iss and jti are hints for locating the artifact; they play no part in matching. A reference matches an artifact if and only if the digests are equal. 4.4. Permissions A Permission object has the structure of an authorization details object [RFC9396]: a REQUIRED type member and type-specific members, including the common members locations, actions, datatypes, identifier, and privileges. It MAY also contain constraints, an array of Constraint objects (Section 4.5). [RFC9396] does not define a general way to compare two authorization details objects, because the meaning of their members depends on the API. This document therefore applies its matching and attenuation rules only to types listed in the Validation Profile, each with a Type Profile (Section 8.1). A request of an unlisted type does not match. Let the constrained members of P be the first reference tokens of the ptr values of P's constraints. A requested authorization detail R matches a Permission P at validation time T if and only if: Hulea Expires 5 May 2027 [Page 9] Internet-Draft Agent Mandates November 2026 1. R.type equals P.type, and the type is listed in the Validation Profile. 2. For each of locations, actions, datatypes, and privileges present in P, R contains the member and every element of R's array is identical (Section 4.6) to an element of P's array. 3. Every other member of P except constraints is present in R with an identical value. 4. Every top-level member of R is admitted by P: type, one of locations, actions, datatypes, and privileges, a member of P, a constrained member of P, or an admitted member of the Type Profile (Section 8.1). 5. Every stateless constraint in P is satisfied by R at time T. 6. For every stateful constraint in P, the pointer resolves in R to a value the predicate accepts: for sum_max, a string matching nonneg; for cosign_above, a string matching decimal. A Permission without one of locations, actions, datatypes, and privileges places no restriction on that dimension. Likewise, an admitted member of the Type Profile that P neither contains nor constrains may take any value. Rule 4 prevents a request from carrying any other member, which the mandate did not anticipate and which could change the meaning of the action. These rules, and those in Section 4.7, are fixed by this document. A Type Profile chooses which members are admitted; it cannot replace the comparison rules. Identity comparison and a registered set of predicates keep the result the same across implementations. 4.5. Constraints A Constraint object has the members pred (REQUIRED), ptr (a JSON Pointer [RFC6901] evaluated against the requested authorization detail; REQUIRED except for window), and value (REQUIRED). The sum_max predicate also has the REQUIRED members period and budget. Amounts are decimal strings matching the ABNF below, compared as exact decimal numbers. JSON numbers MUST NOT be used for amounts. decimal = ["-"] nonneg nonneg = ("0" / (%x31-39 *DIGIT)) ["." 1*DIGIT] Hulea Expires 5 May 2027 [Page 10] Internet-Draft Agent Mandates November 2026 period is an integer number of seconds, at least 1 and at most the framework's max_period in the Validation Profile (Section 8). budget is a string. The value of eq is any JSON value; of in, a non-empty array; of max, min, and cosign_above, a string matching decimal; of sum_max, a string matching nonneg; and of window, an object with the integer members nbf and exp, nbf less than exp. A constraint with a value of another type, a missing REQUIRED member, or a period that is not an integer of at least 1 makes its artifact malformed; a period above max_period gives lifetime_exceeded (Section 9.3). If a pointer does not resolve, or resolves to a value of the wrong type, the constraint is not satisfied. +==============+===========+======================================+ | pred | Kind | Satisfied when | +==============+===========+======================================+ | eq | stateless | resolved value is identical to value | +--------------+-----------+--------------------------------------+ | in | stateless | resolved value is identical to an | | | | element of value | +--------------+-----------+--------------------------------------+ | max | stateless | resolved decimal is less than or | | | | equal to value | +--------------+-----------+--------------------------------------+ | min | stateless | resolved decimal is greater than or | | | | equal to value | +--------------+-----------+--------------------------------------+ | window | stateless | value.nbf <= T < value.exp (no ptr) | +--------------+-----------+--------------------------------------+ | sum_max | stateful | resolved value matches nonneg; | | | | produces an Obligation | +--------------+-----------+--------------------------------------+ | cosign_above | stateful | produces an Obligation if resolved | | | | decimal exceeds value | +--------------+-----------+--------------------------------------+ Table 1: Initial constraint predicates Hulea Expires 5 May 2027 [Page 11] Internet-Draft Agent Mandates November 2026 For sum_max, value MUST match nonneg, and a negative resolved value does not satisfy the constraint. All sum_max constraints with the same budget in one Permission MUST have the same ptr, so that an action contributes a single, well-defined amount to each budget; a Permission that violates this makes its artifact malformed. Several sum_max constraints may still share a budget and pointer with different periods, for example a daily and a monthly limit on the same amount. Refunds, reversals, and other negative contributions are outside the scope of sum_max and need a separately defined predicate. A predicate not listed as supported in the Validation Profile makes the Permission not match. A constraint whose pred is not listed as supported is checked in step 2 (Section 9.3) only for the presence of pred and value; its other members and the type of its value are not checked, and in Section 4.7 no child constraint is at least as strict as it. 4.6. JSON Identity Two JSON values are identical if they have the same type and: strings are equal as sequences of Unicode code points; booleans are identical only if both are true or both are false; null is identical to null; arrays have the same length and identical elements in order; objects have the same member names and identical member values. JSON numbers SHOULD NOT be used in Permission members or constraint values; when used, they are identical only if their textual representations are identical. 4.7. Attenuation Attenuation is used for sub-delegation (Section 4.8) and for checking a root mandate against the delegator's powers (Section 9.4). A child Permission C is attenuated with respect to a parent Permission P if and only if: 1. C.type equals P.type. 2. For each of locations, actions, datatypes, and privileges present in P, C contains the member and C's array contains only elements identical to elements of P's array. 3. Every other member of P except constraints is present in C with an identical value. 4. Every top-level member of C other than type and constraints is admitted by P, in the sense of rule 4 of Section 4.4. Hulea Expires 5 May 2027 [Page 12] Internet-Draft Agent Mandates November 2026 5. Every constrained member of C is admitted by P. A constraint in C can therefore only narrow the values of a member that P already admits; it cannot admit a member that P rejects. 6. For every constraint in P, C contains a constraint with the same ptr that is at least as strict, per Table 2. Together these rules ensure that every request matching C also matches P. +==============+=============================================+ | Parent pred | Child constraint is at least as strict when | +==============+=============================================+ | eq | eq with identical value | +--------------+---------------------------------------------+ | in | in with value a subset, or eq with value an | | | element | +--------------+---------------------------------------------+ | max | max with value less than or equal | +--------------+---------------------------------------------+ | min | min with value greater than or equal | +--------------+---------------------------------------------+ | window | window with nbf not earlier and exp not | | | later | +--------------+---------------------------------------------+ | sum_max | sum_max with identical budget, value less | | | than or equal, period greater than or equal | +--------------+---------------------------------------------+ | cosign_above | cosign_above with value less than or equal | +--------------+---------------------------------------------+ Table 2: Attenuation rules The sum_max rule is sound because contributions are non-negative and the budget is shared (Section 9.5): the sum over the parent's period is at most the sum over the longer child period, which the child's constraint keeps at or below a value no greater than the parent's. A set of child Permissions is attenuated with respect to a set of parent Permissions if every child Permission is attenuated with respect to at least one parent Permission. 4.8. Sub-Delegation An agent instance whose mandate has max_depth of at least 1 MAY issue a sub-delegated Mandate Assertion. The sub-delegated assertion: Hulea Expires 5 May 2027 [Page 13] Internet-Draft Agent Mandates November 2026 * is signed with the private key whose thumbprint is the parent's cnf.jkt, and carries the corresponding public key in the jwk member of its protected JOSE header; * has iss equal to the parent's sub; * has principal and tf equal to the parent's; * has exp not later than the parent's; * has max_depth at most the parent's max_depth minus 1; * has aud, if the parent has aud, containing only elements of the parent's aud; * has perms attenuated with respect to the parent's perms. The key in the jwk header is not a trust anchor. It is accepted only because the already verified parent mandate binds its thumbprint. 5. Authority Assertion An Authority Assertion states that, according to the records of the Authority Source at the time of issuance, the delegator may delegate to agents, on behalf of the principal, the permissions described in powers. It is a statement about delegable powers, not merely about what the delegator may do in person: a delegator entitled to perform an action may still be barred from delegating it, and such an action does not appear in powers. It does not state that the delegator issued or intended any particular mandate. An Authority Assertion is a JWT with typ value authority+jwt, or an SD-JWT [RFC9901] with typ value authority+sd-jwt. It contains: * iss, jti, iat, exp (REQUIRED); * principal and delegator (REQUIRED Party Identifiers); * powers (REQUIRED): a non-empty array of Permission objects describing the permissions the delegator may delegate to agents. They MUST NOT contain stateful constraints; cumulative limits on the delegator's own authority are outside the scope of this version; * max_depth (OPTIONAL): the greatest max_depth a root mandate based on this assertion may carry. Default 0, which permits no sub- delegation; Hulea Expires 5 May 2027 [Page 14] Internet-Draft Agent Mandates November 2026 * tf (REQUIRED) and loa (OPTIONAL); * status (OPTIONAL). A sum_max constraint in a root mandate is therefore a limit on that mandate only. Two root mandates based on the same Authority Assertion have separate budgets, because accounting is keyed by the root mandate (Section 9.5). When the assertion is an SD-JWT, the claims listed above, including every member nested at any depth within powers, MUST be in the issuer-signed payload and MUST NOT be selectively disclosable. An Authority Assertion whose powers contain an _sd member or a ... array element is malformed. Only other claims about the delegator, such as a name or role title, may be selectively disclosable, and they never affect the Validation Result. Hiding a restriction on the delegator's powers would otherwise make those powers appear broader. A Validator evaluates these claims on the issuer-signed JWT alone. A claim present only in a disclosure is treated as absent; disclosures never affect the Validation Result. In the European Union, an Authority Source can derive Authority Assertions from electronic attestations of attributes concerning powers and mandates to represent natural or legal persons [EIDAS2]. This document does not require any particular source. 6. Agent Instance Evidence 6.1. Workload Identity Token The agent instance presents a WIT [I-D.ietf-wimse-workload-creds] issued by its operator. Under this specification the WIT MUST contain iss and iat; [I-D.ietf-wimse-workload-creds] makes iss optional and does not list iat, which is needed for the max_validity check of step 3 (Section 9.3). The WIT sub MUST equal the leaf mandate's sub, and the JWK SHA-256 thumbprint of the WIT's cnf.jwk MUST equal the leaf mandate's cnf.jkt. The WIT is referenced by digest; it carries no tf, and its issuer is checked against operator anchors accepted for the framework context (Section 9). The WIT asserts that the operator runs an agent instance with this identifier and key. It asserts nothing about the model, configuration, or behavior of the instance. Hulea Expires 5 May 2027 [Page 15] Internet-Draft Agent Mandates November 2026 6.2. Attestation Result An agent instance MAY present an attestation result from a RATS Verifier [RFC9334], encoded as a JWT-based EAT [RFC9711] with typ value eat+jwt and the claims iss, iat, exp, eat_profile, and cnf with a jkt member. The eat_profile value MUST be one accepted by the Validation Profile, which also fixes the meaning of the result. The cnf.jkt MUST equal the leaf mandate's cnf.jkt. An attestation result describes the Verifier's appraisal of evidence at the time the evidence was produced, not the state of the instance afterwards [RFC9334]. When the instance obtains model output from a remote service, the result covers the remote model only if the appraised evidence covered it. 6.3. Exposure Statement An agent instance MAY present an Exposure Statement: a JWT with typ value agent-exposure+jwt, signed by a control component that observes the instance's session (the observer), not by the agent instance. It contains: * iss, jti, iat, exp, and sub (the agent instance); * aud: the identifier of the single RP to which the statement may be presented; * cnf with a jkt member equal to the leaf mandate's cnf.jkt; * sid: an identifier, assigned by the observer, of the session it observed; * nonce: the value of the nonce parameter of the HTTP Message Signature of the request it accompanies (Section 7.2); * ad_hash: the base64url-encoded SHA-256 digest of the bytes of the authorization_details parameter value of that request, as sent; * exposure: an array of exposure event types from Section 15.6 that the observer recorded in session sid up to iat, sorted by code point, without duplicates. The agent instance obtains the statement from the observer for one specific request to one RP, supplying the RP identifier and the signature nonce it will use. The statement is single-use: * aud restricts it to one RP, so the same statement cannot be presented at a second RP; Hulea Expires 5 May 2027 [Page 16] Internet-Draft Agent Mandates November 2026 * the RP's authorization server consumes it, as described below, only after the Validator has accepted it for this presentation. The authorization server proceeds in this order: 1. It verifies the HTTP Message Signature and runs the Validator. 2. If the outcome is invalid, it rejects the request. No Exposure Statement is consumed. 3. Otherwise, it takes the deduplicated set of pairs (iss, jti) of the Exposure Statements listed in the result's evidence, and only those. In one atomic operation, if any pair in the set is already recorded, it rejects the request and records none of them; otherwise it records all of them, each with the statement's verified exp. 4. It then applies its policy and continues with authorization. A presentation that is invalid, and a statement the Validator rejected, therefore never change the record. A forged statement that copies a legitimate iss and jti, or an authentic statement presented with another key or nonce, cannot consume the legitimate one. Each record MUST be kept until the recorded exp plus max_clock_skew, independently of how long signature nonces are kept. A statement is consumed once recorded, even if the RP's policy later refuses the action. Consumption is tracked outside the Validator, which remains a deterministic function of its inputs. The statement describes the session the observer attributes to that request. exp minus iat MUST NOT exceed the Validation Profile's maximum for Exposure Statements. An empty exposure array means that no registered event was observed, not that the session was free of manipulation. The observer MAY be run by the operator, but its signing key MUST NOT be accessible to the agent instance. Each exposure_observer trust anchor lists the WIT issuers whose sessions it may observe. 7. Mandate Presentation This document profiles OAuth 2.0 Token Exchange [RFC8693]. The agent instance is the client of the RP's authorization server. 7.1. Token Exchange Request The request contains: * subject_token: the leaf Mandate Assertion; Hulea Expires 5 May 2027 [Page 17] Internet-Draft Agent Mandates November 2026 * subject_token_type: urn:ietf:params:oauth:token-type:agent- mandate; * actor_token: the agent instance's WIT; * actor_token_type: urn:ietf:params:oauth:token-type:jwt; * authorization_details: an array containing exactly one authorization details object [RFC9396], the requested action. This version authorizes one action per request and per token; * mandate_evidence: a JSON array of strings, each the compact serialization of a parent Mandate Assertion, an Authority Assertion, an attestation result, or an Exposure Statement. REQUIRED when the leaf is sub-delegated or references an Authority Assertion. 7.2. Proof of Possession The client MUST sign the request with HTTP Message Signatures [RFC9421] as profiled for workloads by [I-D.ietf-wimse-http-signature], using the key confirmed by the WIT. The signature MUST cover at least @method, @target-uri, the Content- Digest header field [RFC9530], and the Workload-Identity-Token header field, and MUST carry the created, expires, and nonce parameters. The Workload-Identity-Token header field MUST carry the same WIT as actor_token. expires minus created MUST NOT exceed the Validation Profile's max_pop_window. Because the request body carries the mandate, the evidence, and the requested authorization details, and Content-Digest covers the body, the signature binds the key, the RP endpoint, the mandate, and the requested action, and its parameters give freshness. The authorization server MUST reject a nonce it has already accepted within the signature's validity period. The Workload Proof Token [I-D.ietf-wimse-wpt] is not used because it does not cover the request body. The PoP outcome given to the Validator (Section 9.1) is ok if and only if all of these checks succeed; the verified nonce value is also given to the Validator. 8. Validation Profile The Validation Profile is a JSON document fixing every rule that influences the Validation Result and is not fixed by this specification. It is identified by a URI and by the base64url- encoded SHA-256 digest of its bytes. It contains at least: Hulea Expires 5 May 2027 [Page 18] Internet-Draft Agent Mandates November 2026 * iss: the identifier of the entity that issued the profile, usually the RP; * max_clock_skew, max_pop_window, max_token_lifetime, and max_status_age, in seconds; * max_chain_length, the greatest number of Mandate Assertions in a chain; * predicates: the supported constraint predicates; * status_values (optional): a mapping from Token Status List values other than 0x00, 0x01, and 0x02 to valid, revoked, or suspended; * types: the supported authorization details types, each with its Type Profile included in full (Section 8.1); * eat_profiles: the accepted eat_profile values; * frameworks: one entry per accepted Trust Framework URI, with: - algs: permitted signature algorithms; - party_schemes: accepted Party Identifier schemes; - self_schemes: the Party Identifier schemes under which a root whose delegator equals its principal is an accepted basis of authority (Section 9.4). An empty array admits no such root; - max_validity: an object whose members are typ values and whose values are the maximum of exp minus iat, in seconds, for artifacts with that typ. The members are mandate+jwt, authority+jwt, authority+sd-jwt, wit+jwt, eat+jwt, and agent- exposure+jwt; - max_period: the maximum period of a sum_max constraint, in seconds; - status_required: the typ values of the artifacts that MUST carry status; - authority_frameworks: the Trust Framework URIs whose Authority Assertions are accepted for mandates under this framework. The framework's own URI is accepted only if listed. The Validation Profile reflects the Trust Framework rules that a machine can check. It does not contain the RP's authorization policy. Hulea Expires 5 May 2027 [Page 19] Internet-Draft Agent Mandates November 2026 A Trust Framework MAY require the profile to be signed by its issuer or ratified by the framework's operator, with a JWS [RFC7515] with detached payload over the same bytes. The digest is computed over the profile's bytes alone, so a signature does not change the Validation Result. When the profile is signed or ratified, the signature lets an evaluator in another domain establish who issued or ratified it. Without a signature, iss is the profile's own statement of its issuer, and the digest fixes only the content. 8.1. Type Profiles A Type Profile is part of the Validation Profile document, so the profile's digest fixes it; it MUST NOT refer to external content that influences validation. It is the value of the type's member in types, an object with three members: * schema: a JSON Schema for requested authorization details of the type, included in full; * admitted: the admitted members, top-level members a request may carry without the Permission mentioning them, each of which is unrestricted unless a Permission contains or constrains it; * meaning: an object giving, for each admitted member, its meaning, so that "unrestricted" has a defined effect. The schema applies to the requested authorization detail; a request that does not conform gives request_malformed. Permissions are not validated against it, because they may omit members a request needs. A Permission member the schema forbids simply cannot be matched, since matching requires the conforming request to carry it. Schemas MUST use JSON Schema draft 2020-12 [JSON-SCHEMA-CORE] [JSON-SCHEMA-VALIDATION] and MUST declare it with the $schema keyword value https://json-schema.org/draft/2020-12/schema. A schema MAY use only the Core, Applicator, and Validation vocabularies and the Format-Annotation vocabulary; format is an annotation and never causes a request to fail validation. $ref MUST resolve within the same schema. A Validation Profile containing a schema that violates these rules, or a keyword outside those vocabularies, is unusable: a Validator MUST refuse to load it and MUST NOT validate under it. The dialect and the vocabularies are fixed because two independent Validators have to reach the same Validation Result, and they are listed so that the dependency on JSON Schema stays bounded. The two JSON Schema documents are therefore normative references although they are not RFCs. Hulea Expires 5 May 2027 [Page 20] Internet-Draft Agent Mandates November 2026 9. Mandate Validation Procedure 9.1. Inputs The procedure takes exactly these inputs: 1. the Mandate Presentation; 2. the bytes of the authorization_details parameter and its parsed value; 3. the validation time T; 4. the Validation Profile and its digest; 5. the Trust Anchor Set and its digest; 6. a set of Status List Tokens [I-D.ietf-oauth-status-list]; 7. the RP identifier; 8. the PoP outcome and the verified signature nonce (Section 7.2). The Trust Anchor Set is a JSON document, identified like the Validation Profile by a URI and by the base64url-encoded SHA-256 digest of its bytes, so that the anchors in force at T are fixed. It contains anchors, an array of objects, each with: * role: one of mandate_issuer, authority_source, operator, verifier, exposure_observer, and status_issuer; * iss: a non-empty array of the issuer identifiers the entity uses; * keys: a non-empty array of public keys as JWKs; * frameworks: the Trust Framework URIs for which the anchor is accepted; * for an exposure_observer anchor, observes: the WIT issuers whose sessions it may observe; for a status_issuer anchor, publishes_for: the artifact issuers for which it may publish status. Hulea Expires 5 May 2027 [Page 21] Internet-Draft Agent Mandates November 2026 An artifact verifies under an anchor of a role for a framework if the anchor has that role, lists the artifact's iss, is accepted for that framework, and has a key with which the signature verifies. A kid header is at most a hint for finding the key. If no anchor of the role satisfies all four conditions, the code is signature_invalid, unless a key that verifies the signature is found only under an anchor of another role, in which case it is role_mismatch. Two conforming Validators given identical inputs MUST produce identical Validation Results. A Validator MUST NOT consult any other input and MUST NOT apply local authorization policy. Status List Tokens are fetched before validation. 9.2. Required and Optional Evidence Required evidence is the leaf Mandate Assertion, its ancestors, the Authority Assertions referenced by the root and presented, and the WIT. The references in authority are alternatives: only an assertion that supports the root is needed, and Section 9.4 states when a problem with another referenced assertion is reported as a diagnostic instead of an error. An artifact in mandate_evidence that is neither a mandate in the chain, nor referenced by the root's authority, nor an attestation result or an Exposure Statement, is ignored and does not appear in the result. Optional evidence is attestation results and Exposure Statements. A problem with required evidence is an error. A problem with optional evidence, and the reason a Permission did not match a request, is a diagnostic. Only errors affect the outcome. 9.3. Procedure The Validator performs every step that can be performed and records every applicable code (Section 15.5); it does not stop at the first failure. 1. *Chain and context.* Starting from the leaf, follow parent references through the artifacts in mandate_evidence. A reference without a matching artifact gives chain_broken on the mandate carrying the reference. The Validator follows at most max_chain_length mandates, the leaf included. If the last mandate followed carries parent, the chain is longer: the Validator records chain_too_long, does not resolve that reference, records no chain_broken for it, and no root is reached. If a root is reached, the framework context is the root's tf; if that URI has no entry in the Validation Profile's frameworks, framework_not_accepted on the root. If the root does not parse or has no tf, the framework context is undetermined and tf in the result is null; Hulea Expires 5 May 2027 [Page 22] Internet-Draft Agent Mandates November 2026 framework_not_accepted is not recorded. If no root is reached, or the framework context is undetermined or not accepted, steps 3 to 5 and 7 are skipped, the authority check is not evaluated, and every optional evidence artifact is listed under rejected with evidence_rejected. If no root is reached, chain in the result lists the mandates that were recovered, starting with the highest recovered ancestor. 2. *Structure.* Each required artifact parses, has the expected typ, and contains its REQUIRED claims. Each claim that is present has the type and structure given for it in this document or in the specification that defines the artifact. It contains no claim this document forbids for it: authority in a sub- delegated mandate or in a root whose delegator equals its principal, and parent in a root. Every Constraint has the members and value types of Section 4.5, sum_max constraints that share a budget in one Permission share their ptr, and an Authority Assertion's powers contain no stateful constraint and, in an SD-JWT, no _sd member or ... array element. Otherwise malformed. Relations between artifacts, and limits set by the Validation Profile, are checked in later steps. 3. *Profile conformance.* Under the framework context: algorithms are permitted (alg_not_allowed); Party Identifier schemes are accepted (scheme_not_accepted); exp minus iat does not exceed the max_validity entry for the artifact's typ, and the period of every sum_max constraint does not exceed max_period (lifetime_exceeded); and every artifact whose typ is in status_required carries status (status_missing). 4. *Signatures and keys.* The root verifies under a mandate_issuer anchor for the framework context (Section 9.1). Each sub- delegated mandate carries a jwk header (key_missing), whose thumbprint equals the parent's cnf.jkt (key_mismatch), and verifies with it (signature_invalid). Each Authority Assertion verifies under an authority_source anchor for the assertion's own tf. The WIT verifies under an operator anchor for the framework context. An attestation result verifies under a verifier anchor for the framework context. A failed verification under an anchor gives the codes stated in Section 9.1. For a sub-delegated mandate the three checks are made in the order given, and the first that fails records its code and ends this step for that mandate. The thumbprint comparison needs the parent to have passed step 2; otherwise it is skipped and the signature is still verified with the jwk. Hulea Expires 5 May 2027 [Page 23] Internet-Draft Agent Mandates November 2026 5. *Framework compatibility.* Every mandate's tf equals the framework context, and every Authority Assertion's tf is in the context framework's authority_frameworks. Otherwise framework_mismatch. 6. *Time.* For each required artifact, nbf (when present) is at most T + max_clock_skew, and T is less than exp + max_clock_skew. Otherwise not_yet_valid or expired. 7. *Status.* The applicable framework of an artifact is its own tf for an Authority Assertion and the framework context for every other artifact. For each required artifact with status, the Status List Tokens in the inputs are filtered in three stages, in this order, and if no token remains after a stage, the code is that stage's: * subject: the token has typ statuslist+jwt, its sub is the status list URI referenced by the artifact's status, and its status_list decodes to a list with an entry at the referenced idx (status_unavailable); * anchor: some status_issuer anchor for the applicable framework, whose publishes_for lists the artifact's issuer, has a key with which the token's signature verifies and, if the token carries iss, lists it (status_untrusted); * time: the token's iat is at most T + max_clock_skew, its exp, when present, is later than T, and T minus its iat does not exceed max_status_age (status_stale). A token that fails two stages is counted at the first, so the code does not depend on the order in which a Validator checks. A token issued in the future gives status_stale, which means that no trusted token is valid in time at T, not only that the tokens are old. The tokens that pass all three stages are eligible. Let the candidates be the eligible tokens with the greatest iat. If they give different status values at the referenced idx, the code is status_conflict. Otherwise the Validator selects one candidate: the one with the latest exp, a token without exp counting as latest, and among those the one whose digest is first in code point order. The selection does not depend on the order of the inputs and is reported in status_evidence. The selected status value gives nothing if it is VALID (0x00), revoked if INVALID (0x01), and suspended if SUSPENDED (0x02). Any other value, including application-specific values, gives Hulea Expires 5 May 2027 [Page 24] Internet-Draft Agent Mandates November 2026 status_unrecognized, unless the Validation Profile's status_values maps it to one of these three. A later token showing reactivation prevails over an earlier suspension. 8. *Links.* Each sub-delegated mandate is checked against its parent (Section 4.8): its iss equals the parent's sub, its principal equals the parent's, its exp is not later than the parent's, and, if the parent has aud, it has aud containing only elements of the parent's (chain_inconsistent); its max_depth is at most the parent's minus 1 (depth_exceeded); its perms are attenuated with respect to the parent's (not_attenuated). Equality of tf is checked in step 5. Every code of this step carries the sub-delegated mandate. 9. *Authority.* See Section 9.4. 10. *Binding.* If the PoP outcome is not ok, pop_failed. If the leaf and the WIT each passed step 2 and the WIT does not match the leaf (Section 6.1), binding_mismatch. 11. *Audience.* For each mandate in the chain with aud, the RP identifier is an element of aud. Otherwise audience_mismatch. 12. *Action match.* The authorization_details array contains exactly one object and, if its type is listed in types, the object conforms to that Type Profile's schema. Otherwise request_malformed, and the rest of this step is not performed. An object of an unlisted type is not checked against a schema; it matches no Permission. The alternatives are all Permissions of the leaf that match the object at time T (Section 4.4). If there are none, action_not_permitted. For each Permission that does not match, the diagnostic perm_not_matching is recorded with the Permission's index. 13. *Optional evidence.* Each attestation result and Exposure Statement is checked as required evidence would be in steps 2 to 4, 6, and 7, and against Section 6.2 or Section 6.3. An Exposure Statement also needs aud equal to the RP identifier, nonce equal to the verified signature nonce, ad_hash equal to the digest of the authorization_details bytes, and an exposure_observer anchor whose observes lists the WIT's issuer. Failures are diagnostics (evidence_rejected), and the artifact is listed under rejected rather than evidence. If the leaf or the WIT failed step 2, or the PoP outcome is not ok, every optional evidence artifact is listed under rejected with evidence_rejected. Hulea Expires 5 May 2027 [Page 25] Internet-Draft Agent Mandates November 2026 A step whose premise is absent is skipped and records nothing. An artifact that failed step 2 is not examined by steps 3 to 8 and 10 to 13. If the root failed step 2, the authority check is not evaluated; for an Authority Assertion that failed step 2, the authority check reads only its parties (Section 9.4). Step 8 needs the mandate and its parent, the match of step 10 the leaf and the WIT, and steps 11 and 12 the leaf, each having passed step 2. The PoP part of step 10 is always performed, so a presentation without a WIT records pop_failed. An artifact passes a step if the step recorded no code for it; an artifact without status therefore passes step 7. Each error has an effect, invalid or indeterminate, given in the registry (Section 15.5). The five status codes of step 7, status_unavailable, status_untrusted, status_stale, status_conflict, and status_unrecognized, have the effect indeterminate: they mean that status could not be resolved, not that it was found negative. Every other error defined in this document has the effect invalid. The outcome is invalid if an error with the effect invalid was recorded; otherwise indeterminate if an error was recorded; otherwise valid. 9.4. Authority Check If the root's delegator equals its principal, the authority basis is self and no Authority Assertion is required. The basis is accepted only if the delegator's Party Identifier scheme is listed in the context framework's self_schemes; otherwise the Validator records self_not_permitted on the root. In both cases authority is self, so that the result shows which basis was tried. Otherwise, an assertion has matching parties if its principal and delegator, as presented, equal those of the root. The comparison does not depend on the outcome of steps 2 to 8; an assertion in which either claim is absent or unreadable has no matching parties. A referenced Authority Assertion supports the root if it passed steps 2 to 6, has matching parties, the root's perms are attenuated with respect to its powers (Section 4.7), and the root's max_depth does not exceed its max_depth. The authority check then has one of three results: * *Established*, if some supporting assertion also had no code recorded in step 7. No authority code is added. Hulea Expires 5 May 2027 [Page 26] Internet-Draft Agent Mandates November 2026 * *Supported, status unresolved* (supported_status_unresolved), if no supporting assertion is established but some supporting assertion's only codes from step 7 have the effect indeterminate. No authority code is added; those codes are already recorded, so the outcome is indeterminate, not invalid, unless another error with the effect invalid was recorded. * *Refuted*, otherwise. The Validator adds authority_missing if no referenced assertion was presented, authority_mismatch if none has matching parties, and authority_insufficient in all other cases. The references in authority are alternatives. When the result is established, the codes recorded in steps 2 to 7 for the other referenced assertions are reported as diagnostics, not errors. When the result is supported, status unresolved, the same holds for every referenced assertion that does not support the root; the codes from step 7 of the supporting assertions remain errors. A second assertion that is weaker, presented in addition, therefore never changes the outcome. When the result is refuted, those codes remain errors. For each reference in the root's authority that has no artifact in mandate_evidence, the Validator records the diagnostic authority_not_presented, with the reference as artifact, whatever the result of the check. authority_missing is the verdict on the root, recorded only when no referenced assertion was presented; authority_not_presented is the inventory of each reference that was not, so that a valid result never hides that some referenced assertions were not assessed. authority_missing, authority_mismatch, authority_insufficient, and self_not_permitted carry the root mandate as artifact, because it is the root whose authority was not established. 9.5. Obligations Each alternative carries the Obligations produced by its Permission's stateful constraints (Table 1), in the order of the constraints. An Obligation is a JSON object: * sum_max: members type ("sum_max"), constraint (index in the Permission), root (an Artifact Reference (Section 4.3) to the root mandate, equal to the first element of chain), budget, period, value, and amount (the resolved value of this request). Let A be the authorization time (Section 10.2). The sum of the contributions recorded under the same root and budget with a recording time t such that A minus period < t <= A, plus amount, MUST NOT exceed value. The contribution is recorded with time A. Hulea Expires 5 May 2027 [Page 27] Internet-Draft Agent Mandates November 2026 * cosign_above: present only when the resolved decimal exceeds value; members type ("cosign_above"), constraint, value, and amount. A second party designated by the RP's policy MUST approve the specific action. Alternatives are independent. Constraints in different Permissions share accounting only when they name the same budget, which lets a mandate issuer impose one limit across several Permissions. Because sub-delegated sum_max constraints keep the parent's budget (Table 2), actions taken under any mandate in a chain count against the same budget. The RP performs the check and records the contribution as one atomic operation at time A, so that concurrent requests cannot both pass against the same remaining budget, and a request validated earlier cannot use a window anchored at its validation time. Because each token authorizes one action, each token records exactly one contribution per budget. If the token expires unused, the RP MAY remove the contribution. A sum_max constraint is a cumulative bound. From the chain alone, the Validator establishes only that a child's sum_max is no wider than its parent's (Section 4.7); whether a request keeps the total within value can be known only where the running total for the budget and period is held. The Validator therefore never reports such a limit as satisfied; it returns an Obligation. An RP that neither holds that total nor has the action authorized by a component that does cannot discharge the Obligation, and MUST deny the request (Section 10.1). [I-D.asor-wimse-agent-delegation-chain] applies the same rule to its cumulative constraint types. 9.6. Validation Result The Validation Result is a JSON object with the members: * outcome: valid, invalid, or indeterminate; * profile: an object with the string members uri, the Validation Profile URI, and dig, its base64url-encoded SHA-256 digest (Section 8); * anchors: an object with the same two members for the Trust Anchor Set (Section 9.1); * time: T; * tf: the framework context, or null if undetermined; Hulea Expires 5 May 2027 [Page 28] Internet-Draft Agent Mandates November 2026 * chain: Artifact References for the mandates, root first; * errors and diagnostics: arrays of entries, each with the member code and, as stated below, artifact (an Artifact Reference) and perm (index); * authority: self, established, supported_status_unresolved, refuted, or not_evaluated when no root was reached, the framework context is not accepted, or the root failed step 2; * claims: attributed claims (Section 11), each with claim, value, artifact, and role; * alternatives: an array of objects with perm (the leaf Permission index) and obligations, sorted by perm. It is empty when the outcome is invalid, because the RP has to deny the request then; * evidence and rejected: Artifact References for the optional evidence that was accepted or rejected; * status_evidence: for each artifact whose status was read from a selected Status List Token, an object with artifact (an Artifact Reference), token (the base64url-encoded SHA-256 digest of the selected token), iat and, when present, exp of the selected token, and required (true for required evidence, false for optional evidence), sorted by artifact.dig. Every entry in errors and diagnostics carries artifact, except entries with the codes chain_too_long, pop_failed, request_malformed, action_not_permitted, and perm_not_matching. artifact names the artifact the step was evaluating: for chain_broken, the mandate whose parent has no matching artifact; for key_missing, key_mismatch, chain_inconsistent, depth_exceeded, and not_attenuated, the sub- delegated mandate; for framework_not_accepted and the codes listed at the end of Section 9.4, the root; for authority_not_presented, the unresolved reference; for binding_mismatch, the WIT. For an artifact that does not parse, the digest is computed over the string as presented. perm appears only with perm_not_matching. An Artifact Reference in a Validation Result has exactly the member dig. The hints iss and jti of Section 4.3 are not copied, so that two results do not differ only in hints. claims contains only authenticated claims: claims of artifacts for which step 4, or step 13 for optional evidence, was performed and recorded no code. The claims of a sub-delegated mandate are authenticated only if step 4 was performed for it and for every mandate above it in chain and recorded no code for any of them. Hulea Expires 5 May 2027 [Page 29] Internet-Draft Agent Mandates November 2026 Claims of any other artifact are omitted; the artifact remains identified through chain, errors, or rejected. Subject to that rule, claims contains exactly the following, and nothing else: * for each mandate in chain, in order: iss, sub, principal, delegator, perms, and loa if present; * for each Authority Assertion that supports the root, in the order of the root's authority array: iss, principal, delegator, powers, max_depth, iat, exp, and loa if present; * for the WIT: iss and sub; * for each accepted attestation result, in evidence order: iss, eat_profile, and iat; * for each accepted Exposure Statement, in evidence order: iss, sid, exposure, and iat. Within an artifact, claims appear in the order listed. errors and diagnostics are sorted by code, then artifact.dig, then perm, comparing strings by code point and placing absent members first; duplicates are removed. evidence and rejected are sorted by dig. Two Validation Results are identical if they are identical JSON values (Section 4.6), except that every number in a result, including a number copied from an artifact into claims, is compared by mathematical value, not by its text, so that a Validator that re- serializes a result does not change it. This exception applies only to results; matching and attenuation of Permissions use Section 4.6 unchanged. 10. Authorization and Enforcement 10.1. Authorization Decision The RP decides by applying its own policy to the Validation Result and the request. That policy may, for example, accept only certain Trust Frameworks or loa values, require an attestation result for high-value actions, or react to exposure events. The RP: * MUST NOT allow an action when the outcome is invalid; * MUST treat indeterminate as a denial, unless its policy explicitly permits it for that type of action; Hulea Expires 5 May 2027 [Page 30] Internet-Draft Agent Mandates November 2026 * MUST select one alternative, discharge all of its Obligations at the authorization time A before issuing an access token, and record which alternative it relied on; * MUST deny the request if no alternative's Obligations can be discharged; * SHOULD retain the Validation Result, its decision, and the confirmation produced by the system that executed the action. 10.2. Access Token The authorization time A is read from the RP's clock inside the atomic operation that discharges Obligations and issues the token. A is not earlier than T. At A, the RP MUST check again that A is earlier than the exp of every mandate in the chain, of every supporting Authority Assertion, and of the WIT, plus max_clock_skew, and that every window constraint of the selected alternative is satisfied at A; otherwise it denies. At A, the RP also checks whether each token listed in status_evidence is still eligible: A minus its iat does not exceed max_status_age, and its exp, when present, is later than A. The treatment keeps the distinction between required and optional evidence: * If a token for required evidence is no longer eligible, the RP MUST either obtain fresh Status List Tokens and run the Mandate Validation Procedure again with T = A, or treat the outcome as indeterminate and apply its policy for that outcome. * If a token for optional evidence is no longer eligible, that evidence MUST NOT be relied on at A, and the RP applies its policy again without it. If the policy requires that evidence for the action, the RP denies or obtains fresh evidence and validates again. The Validation Result computed at T is kept unchanged as a record of that validation; the checks at A are recorded with the authorization decision. A Validation Result therefore cannot carry a revocation check past the freshness the Validation Profile allows, however long the RP takes to decide, for example while waiting for a co-signature. An access token issued under this specification: * MUST be sender-constrained to the key with the leaf's cnf.jkt; * MUST carry only the single authorization details object that was allowed; Hulea Expires 5 May 2027 [Page 31] Internet-Draft Agent Mandates November 2026 * MUST carry an act claim identifying the agent instance, and the jti of the leaf and root mandates; * MUST have an exp no later than the earliest of: the exp of every mandate in the chain, of every supporting Authority Assertion, and of the WIT, the exp of any window constraint in the selected alternative, and A plus max_token_lifetime; * MUST authorize a single execution of the action; the resource server MUST reject a second use of the same token. The bound on the token's exp ensures that the action cannot be executed after a time window or a mandate has ended. A revocation after issuance takes effect at the latest when the token expires; an RP that needs it to take effect sooner validates again at execution. 11. Attribution of Claims Each artifact carries only the claims its issuer is in a position to make. Hulea Expires 5 May 2027 [Page 32] Internet-Draft Agent Mandates November 2026 +===============+============+=====================+================+ | Artifact | Issuer | Asserts | Does not | | | role | | assert | +===============+============+=====================+================+ | Authority | Authority | delegator may | that any | | Assertion | Source | delegate the | mandate was | | | | stated powers for | issued or | | | | the principal, | intended | | | | per the source's | | | | | records | | +---------------+------------+---------------------+----------------+ | Root Mandate | Mandate | delegator granted | that the | | Assertion | Issuer | the permissions | delegator had | | | | to the key | authority | +---------------+------------+---------------------+----------------+ | Sub-delegated | Delegating | further | anything | | Mandate | agent | delegation within | beyond the | | Assertion | instance | the parent's | parent | | | | scope | | +---------------+------------+---------------------+----------------+ | WIT | Operator | instance | model, | | | | identifier bound | configuration, | | | | to the key | behavior | +---------------+------------+---------------------+----------------+ | Attestation | Verifier | appraisal of | later state; a | | result | | runtime evidence | remote model | | | | at a point in | unless covered | | | | time | | +---------------+------------+---------------------+----------------+ | Exposure | Observer | exposure events | absence of | | Statement | | recorded in the | manipulation | | | | session | | | | | attributed to one | | | | | presentation, up | | | | | to iat | | +---------------+------------+---------------------+----------------+ Table 3: What each artifact asserts A Validator MUST report each claim with the artifact and role it came from, and MUST NOT treat a claim as established by an artifact whose role does not cover it. In particular, a Mandate Assertion alone never establishes the delegator's authority. Trust anchors are role- specific; an entity holding several roles SHOULD use a distinct key for each. No artifact defined here asserts that the agent's reasoning is correct or that an action reflects the principal's present intent. Hulea Expires 5 May 2027 [Page 33] Internet-Draft Agent Mandates November 2026 12. Boundary with the Trust Framework 12.1. Provided by This Protocol * the formats of Mandate Assertions, Authority Assertions, and Exposure Statements, and the profiles of WIT and EAT; * the semantics of Permissions, constraint predicates, and attenuation; * the Validation Profile structure and the Mandate Validation Procedure, its codes, and its result; * the proof-of-possession profile and the rules for access tokens. 12.2. Defined by a Trust Framework A Trust Framework is identified by the URI in tf. It MUST define: 1. the entities accepted for each role and how their anchors are distributed; 2. the Party Identifier schemes accepted; 3. the meaning of each loa value and the evidence it requires; 4. the permitted algorithms; 5. maximum lifetimes and when status is required; 6. values or bounds for the Validation Profile parameters; 7. requirements on Authority Sources, including the records they rely on, and which other frameworks' Authority Assertions are accepted; 8. the obligations and liability of issuers, including revocation and incident timelines; 9. retention of Validation Results and handling of disputes; 10. the authorization details types and their Type Profiles; 11. how a Mandate Issuer establishes that the instruction to issue a mandate came from the delegator named in it, for example by requiring the delegator's signature over the mandate content; 12. whether and how RPs share accounting for budgets. Hulea Expires 5 May 2027 [Page 34] Internet-Draft Agent Mandates November 2026 The machine-checkable part of items 2 to 7 and 10 is expressed in the Validation Profile. The protocol verifies that the delegator holds authority, unless the Validation Profile admits self for the delegator's scheme, and that the Mandate Issuer states that the delegator granted the mandate. It cannot verify the link between the two inside the delegator's organization; that link rests on the Mandate Issuer, under item 11. A Trust Framework can be a bilateral agreement, a sector scheme, or a regulated scheme. This document takes no position on which. 12.3. Configured by the Relying Party * the Trust Frameworks and loa values it accepts per action; * the optional evidence it requires; * its treatment of indeterminate outcomes and exposure events; * its choice among alternatives and its discharge of Obligations. 13. Security Considerations *Issuer compromise.* Short lifetimes limit the use of a stolen credential but not an attacker who controls an issuer and can issue new artifacts. The exposure window depends on detection, withdrawal of trust in the issuer, and propagation of that decision. Transparency logs [RFC9162] make suspicious issuance visible but do not prevent it. Trust Frameworks need distrust procedures. *Replay.* Mandates are bound to a key; each request is signed with it, and the signature's nonce, time window, and body digest prevent reuse of a request. Access tokens are single-use. aud restricts where a mandate may be presented. *Broad mandates.* The format can express narrow mandates but cannot force issuers to write them. Trust Frameworks and RPs can require specific constraints for specific action types. *Cumulative limits across RPs.* An RP accounts only for actions it has allowed. A mandate accepted by several RPs that do not share state lets an agent, compromised or not, reach a budget at each RP. Mandates with sum_max constraints SHOULD therefore carry an aud naming exactly one RP, unless the Trust Framework defines shared accounting. Without either, a budget is a per-RP limit, not a limit on the mandate. Hulea Expires 5 May 2027 [Page 35] Internet-Draft Agent Mandates November 2026 *Prompt injection and confused deputies.* A valid mandate shows that an action is within delegated authority, not that the agent was not manipulated into requesting it. Exposure Statements, constrained agent outputs, and RP policy reduce but do not remove this risk. *Status availability.* When status cannot be resolved, the outcome is indeterminate and the RP denies by default. The code says why: no token, no trusted token, no token valid in time, conflicting tokens, or an unrecognized value. The Validation Profile makes status mandatory where the Trust Framework requires it, so an issuer cannot avoid revocation checks by omitting it. *Revoked alternatives.* When one referenced Authority Assertion establishes authority, the codes of the other referenced assertions, including revoked and expired, are diagnostics (Section 9.4). A revocation by an Authority Source is a signal that the delegator's powers were withdrawn, and the RP sees it only if the withdrawn assertion was presented: the agent instance selects what it presents, so a withdrawn assertion can simply be omitted, and the Validator then records authority_not_presented for it and has no artifact and no status to check. RP policy SHOULD examine diagnostics with the codes revoked, suspended, and authority_not_presented before allowing an action. *Trust Anchor Set.* The Validator trusts the anchors it is given. A substituted or extended Trust Anchor Set lets an artifact verify under a role and framework its issuer was never accepted for; the digest in the result shows which set was used at T, not who vouched for it. Distribution of anchors is defined by the Trust Framework. A Trust Framework MAY require the set to be signed, with a JWS [RFC7515] with detached payload over the same bytes, as for the Validation Profile; the digest is computed over the bytes alone. *Resource consumption.* max_chain_length bounds chain processing. Validators SHOULD bound the number and size of artifacts. *Exact comparison.* Amounts are decimal strings, pointers are exact, identity is defined on code points, and result arrays have a defined order, so independent implementations reach the same result. *Long-term verifiability.* Validation Results retained for disputes may need to be verifiable for years. This requires preserving validation data and renewing evidence [RFC4998], and migrating to new algorithms, including post-quantum algorithms, as Trust Frameworks permit them. Hulea Expires 5 May 2027 [Page 36] Internet-Draft Agent Mandates November 2026 *Remote models.* Attestation results cover what the Verifier appraised, not a model served by a third party unless that party's evidence was appraised. 14. Privacy Considerations Mandate Presentations disclose the principal and delegator to the RP. Issuers SHOULD use pairwise or role identifiers where the Trust Framework permits, and Authority Sources SHOULD use SD-JWT [RFC9901] for personal attributes of the delegator that do not affect validation. Digests and identifiers can correlate presentations across RPs. The privacy considerations of [I-D.ietf-oauth-status-list] apply. 15. IANA Considerations 15.1. Media Types This document requests registration of application/mandate+jwt, application/authority+jwt, application/authority+sd-jwt, and application/agent-exposure+jwt. Templates to be provided. 15.2. JSON Web Token Claims This document requests registration of the claims principal, delegator, authority, perms, parent, max_depth, tf, loa, powers, ad_hash, and exposure in the "JSON Web Token Claims" registry. The Exposure Statement reuses the registered sid and nonce claims with the meaning defined in Section 6.3. 15.3. OAuth Registrations This document requests registration of the token type URI urn:ietf:params:oauth:token-type:agent-mandate in the "OAuth URI" registry and of the parameter mandate_evidence in the "OAuth Parameters" registry. 15.4. Agent Mandate Constraint Predicates This document requests a new registry, "Agent Mandate Constraint Predicates", with Specification Required policy. Each entry contains the predicate name, its kind, its satisfaction rule, its attenuation rule, the value types it accepts, and a reference. Initial contents are given in Table 1 and Table 2. Hulea Expires 5 May 2027 [Page 37] Internet-Draft Agent Mandates November 2026 15.5. Agent Mandate Validation Codes This document requests a new registry, "Agent Mandate Validation Codes", with Specification Required policy. Each entry has: * the code; * "Recorded as": error, diagnostic, or both; * "Effect as error": invalid or indeterminate, for codes that can be recorded as errors; * "Members": whether entries with the code carry artifact and perm (Section 9.6); * the step that records it, and a reference. Initial entries recorded as errors, with the effect invalid: malformed, chain_broken, chain_too_long, framework_not_accepted, alg_not_allowed, scheme_not_accepted, lifetime_exceeded, status_missing, key_missing, key_mismatch, signature_invalid, role_mismatch, framework_mismatch, not_yet_valid, expired, revoked, suspended, chain_inconsistent, depth_exceeded, not_attenuated, self_not_permitted, authority_missing, authority_mismatch, authority_insufficient, binding_mismatch, pop_failed, audience_mismatch, request_malformed, action_not_permitted. Initial entries recorded as errors, with the effect indeterminate: status_unavailable, status_untrusted, status_stale, status_conflict, status_unrecognized. Of these, the codes recorded in steps 2 to 7 can also be recorded as diagnostics for a referenced Authority Assertion, as stated in Section 9.4. Initial entries recorded only as diagnostics: perm_not_matching, evidence_rejected, authority_not_presented. The members of each initial entry are those stated in Section 9.6. A new entry MUST state all the fields above, and the specification requesting it MUST state in which step the code is recorded. The designated experts SHOULD reject an entry with the effect indeterminate that does not describe evidence that could not be resolved, so that registrations cannot change what indeterminate means. Hulea Expires 5 May 2027 [Page 38] Internet-Draft Agent Mandates November 2026 15.6. Agent Exposure Event Types This document requests a new registry, "Agent Exposure Event Types", with Specification Required policy. Initial values: * external_content: the session processed content retrieved from outside the operator's domain that was not on an allow list; * unauthenticated_tool: the session invoked a tool or service whose identity was not authenticated; * untrusted_agent_input: the session processed output from an agent instance whose mandate was not validated. 16. References 16.1. Normative References [I-D.ietf-oauth-status-list] Looker, T., Bastian, P., and C. Bormann, "Token Status List (TSL)", Work in Progress, Internet-Draft, draft-ietf- oauth-status-list-21, 21 June 2026, . [I-D.ietf-wimse-http-signature] Salowey, J. A. and Y. Sheffer, "WIMSE Workload-to-Workload Authentication with HTTP Signatures", Work in Progress, Internet-Draft, draft-ietf-wimse-http-signature-08, 20 October 2026, . [I-D.ietf-wimse-workload-creds] Campbell, B., Salowey, J. A., Schwenkschuster, A., Sheffer, Y., and Y. Rosomakho, "WIMSE Workload Credentials", Work in Progress, Internet-Draft, draft- ietf-wimse-workload-creds-03, 30 October 2026, . [JSON-SCHEMA-CORE] JSON Schema, "JSON Schema: A Media Type for Describing JSON Documents, Draft 2020-12", June 2022, . Hulea Expires 5 May 2027 [Page 39] Internet-Draft Agent Mandates November 2026 [JSON-SCHEMA-VALIDATION] JSON Schema, "JSON Schema Validation: A Vocabulary for Structural Validation of JSON, Draft 2020-12", June 2022, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC6901] Bryan, P., Ed., Zyp, K., and M. Nottingham, Ed., "JavaScript Object Notation (JSON) Pointer", RFC 6901, DOI 10.17487/RFC6901, April 2013, . [RFC7515] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Signature (JWS)", RFC 7515, DOI 10.17487/RFC7515, May 2015, . [RFC7519] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token (JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015, . [RFC7638] Jones, M. and N. Sakimura, "JSON Web Key (JWK) Thumbprint", RFC 7638, DOI 10.17487/RFC7638, September 2015, . [RFC7800] Jones, M., Bradley, J., and H. Tschofenig, "Proof-of- Possession Key Semantics for JSON Web Tokens (JWTs)", RFC 7800, DOI 10.17487/RFC7800, April 2016, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC8693] Jones, M., Nadalin, A., Campbell, B., Ed., Bradley, J., and C. Mortimore, "OAuth 2.0 Token Exchange", RFC 8693, DOI 10.17487/RFC8693, January 2020, . [RFC8725] Sheffer, Y., Hardt, D., and M. Jones, "JSON Web Token Best Current Practices", BCP 225, RFC 8725, DOI 10.17487/RFC8725, February 2020, . Hulea Expires 5 May 2027 [Page 40] Internet-Draft Agent Mandates November 2026 [RFC9396] Lodderstedt, T., Richer, J., and B. Campbell, "OAuth 2.0 Rich Authorization Requests", RFC 9396, DOI 10.17487/RFC9396, May 2023, . [RFC9421] Backman, A., Ed., Richer, J., Ed., and M. Sporny, "HTTP Message Signatures", RFC 9421, DOI 10.17487/RFC9421, February 2024, . [RFC9530] Polli, R. and L. Pardue, "Digest Fields", RFC 9530, DOI 10.17487/RFC9530, February 2024, . [RFC9711] Lundblade, L., Mandyam, G., O'Donoghue, J., and C. Wallace, "The Entity Attestation Token (EAT)", RFC 9711, DOI 10.17487/RFC9711, April 2025, . [RFC9901] Fett, D., Yasuda, K., and B. Campbell, "Selective Disclosure for JSON Web Tokens", RFC 9901, DOI 10.17487/RFC9901, November 2025, . 16.2. Informative References [COSAI-AIAM] Coalition for Secure AI (CoSAI), "Agentic Identity and Access Management, Version 1.0", 20 March 2026, . [EIDAS2] European Parliament and Council of the European Union, "Regulation (EU) 2024/1183 of the European Parliament and of the Council amending Regulation (EU) No 910/2014 as regards establishing the European Digital Identity Framework", 11 April 2024, . [I-D.asor-wimse-agent-delegation-chain] Asor, R., "Verifiable Attenuated Delegation for AI Agent Chains", Work in Progress, Internet-Draft, draft-asor- wimse-agent-delegation-chain-03, 27 October 2026, . Hulea Expires 5 May 2027 [Page 41] Internet-Draft Agent Mandates November 2026 [I-D.hamr-oauth-agent-delegation] Hassan, A., "An Attenuated Delegation Profile for Automated Agents", Work in Progress, Internet-Draft, draft-hamr-oauth-agent-delegation-03, 22 October 2026, . [I-D.ietf-wimse-aims] Kasselman, P., Lombardo, J., Rosomakho, Y., Campbell, B., Steele, N., and A. Parecki, "AI Identity Management System", Work in Progress, Internet-Draft, draft-ietf- wimse-aims-00, 15 September 2026, . [I-D.ietf-wimse-arch] Salowey, J. A., Rosomakho, Y., and H. Tschofenig, "Workload Identity in a Multi System Environment (WIMSE) Architecture", Work in Progress, Internet-Draft, draft- ietf-wimse-arch-08, 6 July 2026, . [I-D.ietf-wimse-wpt] Campbell, B. and A. Schwenkschuster, "WIMSE Workload Proof Token", Work in Progress, Internet-Draft, draft-ietf- wimse-wpt-02, 27 August 2026, . [I-D.konda-agentproto-evaluation-state] Konda, G., "Preserving Evaluation State in Agent Protocol Decisions", Work in Progress, Internet-Draft, draft-konda- agentproto-evaluation-state-02, 19 October 2026, . [I-D.reece-wimse-cross-org-delegation] Reece, M., "Cross-Organizational Delegation for Workload and Agent Identity: Problem Statement and Requirements", Work in Progress, Internet-Draft, draft-reece-wimse-cross- org-delegation-02, 31 August 2026, . [I-D.sweeney-wimse-credential-delegation] Sweeney, K., "Credential Delegation Protocol for AI Agents in Multi-System Environments", Work in Progress, Internet- Hulea Expires 5 May 2027 [Page 42] Internet-Draft Agent Mandates November 2026 Draft, draft-sweeney-wimse-credential-delegation-02, 30 October 2026, . [I-D.tanase-ain-authoritative-resolution] Tănase, E., "Authoritative Resolution and Pre-Interaction Verification of Persistent Digital Agent Identities", Work in Progress, Internet-Draft, draft-tanase-ain- authoritative-resolution-01, 27 October 2026, . [I-D.wadkins-agentproto-action-determinability] Wadkins, D. L., "Independent Determinability of Agent Actions", Work in Progress, Internet-Draft, draft-wadkins- agentproto-action-determinability-00, 11 September 2026, . [I-D.yossif-agent-mandate-problem] Yossif, M. K., "Problem Statement: Verifiable Human Mandates for Autonomous Agent Actions", Work in Progress, Internet-Draft, draft-yossif-agent-mandate-problem-00, 22 July 2026, . [OIDF-AGENTIC] OpenID Foundation, "Identity Management for Agentic AI", October 2025, . [RFC4998] Gondrom, T., Brandner, R., and U. Pordesch, "Evidence Record Syntax (ERS)", RFC 4998, DOI 10.17487/RFC4998, August 2007, . [RFC9162] Laurie, B., Messeri, E., and R. Stradling, "Certificate Transparency Version 2.0", RFC 9162, DOI 10.17487/RFC9162, December 2021, . [RFC9334] Birkholz, H., Thaler, D., Richardson, M., Smith, N., and W. Pan, "Remote ATtestation procedureS (RATS) Architecture", RFC 9334, DOI 10.17487/RFC9334, January 2023, . Hulea Expires 5 May 2027 [Page 43] Internet-Draft Agent Mandates November 2026 Appendix A. Example A company's treasury agent holds a mandate from the company's financial director and delegates part of it to a reconciliation agent, which initiates a payment at the company's bank. Payloads are shown decoded and unsigned; identifiers are fictional; digests, keys, and some values are elided as "...". Signed vectors for this example under -00 have been published independently; they are expected to be regenerated for this revision. The bank's Validation Profile includes a Type Profile for payment_initiation whose admitted members are instructedAmount, creditorAccount, and remittanceInformation. A Permission that does not constrain one of them leaves it unrestricted. Authority Assertion from a company register, stating which payments the director may delegate to agents: { "iss": "https://register.example", "jti": "aa-5c1e", "iat": 1792800000, "exp": 1824336000, "principal": {"id": "J40/0000/2020", "scheme": "urn:example:reg"}, "delegator": {"id": "p-41f9", "scheme": "urn:example:pairwise"}, "powers": [{ "type": "payment_initiation", "constraints": [ {"pred": "eq", "ptr": "/instructedAmount/currency", "value": "EUR"}, {"pred": "max", "ptr": "/instructedAmount/amount", "value": "100000.00"} ] }], "max_depth": 1, "tf": "https://tf.example/finance" } Root Mandate Assertion to the treasury agent: Hulea Expires 5 May 2027 [Page 44] Internet-Draft Agent Mandates November 2026 { "iss": "https://mandates.treasury.example", "sub": "spiffe://treasury.example/agents/payments-7", "jti": "ma-90b2", "iat": 1792886400, "nbf": 1792886400, "exp": 1795478400, "cnf": {"jkt": "..."}, "principal": {"id": "J40/0000/2020", "scheme": "urn:example:reg"}, "delegator": {"id": "p-41f9", "scheme": "urn:example:pairwise"}, "authority": [{"dig": "...", "iss": "https://register.example"}], "perms": [{ "type": "payment_initiation", "actions": ["initiate"], "locations": ["https://bank.example/payments"], "constraints": [ {"pred": "eq", "ptr": "/instructedAmount/currency", "value": "EUR"}, {"pred": "max", "ptr": "/instructedAmount/amount", "value": "20000.00"}, {"pred": "in", "ptr": "/creditorAccount/iban", "value": ["RO49AAAA1B31007593840000", "DE89370400440532013000"]}, {"pred": "sum_max", "ptr": "/instructedAmount/amount", "value": "50000.00", "period": 2592000, "budget": "monthly-out"}, {"pred": "cosign_above", "ptr": "/instructedAmount/amount", "value": "10000.00"} ] }], "max_depth": 1, "aud": ["https://bank.example"], "tf": "https://tf.example/finance", "loa": "substantial" } Protected header of the sub-delegated mandate, carrying the treasury agent's public key: { "typ": "mandate+jwt", "alg": "EdDSA", "jwk": {"kty": "OKP", "crv": "Ed25519", "x": "..."} } Sub-delegated Mandate Assertion to the reconciliation agent: Hulea Expires 5 May 2027 [Page 45] Internet-Draft Agent Mandates November 2026 { "iss": "spiffe://treasury.example/agents/payments-7", "sub": "spiffe://treasury.example/agents/reconcile-2", "jti": "ma-17c4", "iat": 1792890000, "nbf": 1792890000, "exp": 1792976400, "cnf": {"jkt": "..."}, "principal": {"id": "J40/0000/2020", "scheme": "urn:example:reg"}, "delegator": {"id": "spiffe://treasury.example/agents/payments-7", "scheme": "urn:example:workload"}, "parent": {"dig": "..."}, "perms": [{ "type": "payment_initiation", "actions": ["initiate"], "locations": ["https://bank.example/payments"], "constraints": [ {"pred": "eq", "ptr": "/instructedAmount/currency", "value": "EUR"}, {"pred": "max", "ptr": "/instructedAmount/amount", "value": "5000.00"}, {"pred": "eq", "ptr": "/creditorAccount/iban", "value": "DE89370400440532013000"}, {"pred": "sum_max", "ptr": "/instructedAmount/amount", "value": "20000.00", "period": 2592000, "budget": "monthly-out"}, {"pred": "cosign_above", "ptr": "/instructedAmount/amount", "value": "5000.00"} ] }], "aud": ["https://bank.example"], "tf": "https://tf.example/finance" } Requested authorization detail: { "type": "payment_initiation", "actions": ["initiate"], "locations": ["https://bank.example/payments"], "instructedAmount": {"currency": "EUR", "amount": "4000.00"}, "creditorAccount": {"iban": "DE89370400440532013000"} } Validation Result, abbreviated. The amount does not exceed the co- signature threshold, so the only Obligation is the shared budget: Hulea Expires 5 May 2027 [Page 46] Internet-Draft Agent Mandates November 2026 { "outcome": "valid", "profile": {"uri": "https://bank.example/profiles/agents/3", "dig": "..."}, "anchors": {"uri": "https://bank.example/anchors/7", "dig": "..."}, "time": 1792972800, "tf": "https://tf.example/finance", "chain": [{"dig": "..."}, {"dig": "..."}], "errors": [], "diagnostics": [], "authority": "established", "claims": ["..."], "alternatives": [{ "perm": 0, "obligations": [{ "type": "sum_max", "constraint": 3, "root": {"dig": "..."}, "budget": "monthly-out", "period": 2592000, "value": "20000.00", "amount": "4000.00" }] }], "evidence": [], "rejected": [], "status_evidence": [] } At authorization time A, the bank checks again that both mandates, the Authority Assertion, and the WIT are unexpired, records 4000.00 against budget monthly-out of the root mandate, identified by its digest, in the same atomic operation, and issues a single-use token whose exp is no later than 1792976400, the exp of the sub-delegated mandate. Appendix B. Conformance Cases Each case lists the expected outcome, the errors, and, where relevant, the diagnostics and other members of the result. Signed test vectors exist for some of the authority cases under -00 and are planned for every case. +=============================+=================================+ | Case | Expected result | +=============================+=================================+ | Valid chain with two | valid | | delegations; keys in jwk | | | headers | | +-----------------------------+---------------------------------+ | Sub-delegated mandate | invalid, key_missing | Hulea Expires 5 May 2027 [Page 47] Internet-Draft Agent Mandates November 2026 | without jwk header | | +-----------------------------+---------------------------------+ | Authority Assertion under a | invalid; framework_mismatch, | | framework not in | authority_insufficient | | authority_frameworks | | +-----------------------------+---------------------------------+ | Request matching two | valid; two alternatives, each | | Permissions with different | with its own Obligations | | sum_max | | +-----------------------------+---------------------------------+ | Valid mandate plus | valid; evidence_rejected | | attestation result with a | diagnostic | | bad signature | | +-----------------------------+---------------------------------+ | Child sum_max with period | valid; Obligation of type | | longer than the parent's | sum_max with the child's | | | budget, period, and value | +-----------------------------+---------------------------------+ | Request whose sum_max | invalid, action_not_permitted; | | pointer resolves to a | perm_not_matching with perm 0 | | negative amount, the leaf | | | having only that Permission | | +-----------------------------+---------------------------------+ | SD-JWT Authority Assertion | invalid; malformed, | | with _sd inside powers | authority_insufficient | +-----------------------------+---------------------------------+ | No Status List Token | indeterminate, | | presented for a mandate's | status_unavailable | | required status | | +-----------------------------+---------------------------------+ | No Status List Token | indeterminate, | | presented only for the | status_unavailable; authority | | supporting Authority | is supported_status_unresolved; | | Assertion | no authority error | +-----------------------------+---------------------------------+ | Two eligible Status List | invalid, revoked | | Tokens for a mandate; later | | | one revokes | | +-----------------------------+---------------------------------+ | Two eligible Status List | indeterminate, status_conflict | | Tokens for a mandate with | | | equal iat and different | | | status | | +-----------------------------+---------------------------------+ | Child adds a constraint on | invalid, not_attenuated | | a member the parent does | | | not admit | | +-----------------------------+---------------------------------+ Hulea Expires 5 May 2027 [Page 48] Internet-Draft Agent Mandates November 2026 | Root constrains a member | valid | | admitted by the Type | | | Profile but absent from | | | powers | | +-----------------------------+---------------------------------+ | Root max_depth greater than | invalid, authority_insufficient | | the Authority Assertion's | | +-----------------------------+---------------------------------+ | Exposure Statement reused | evidence_rejected diagnostic | | with a new signature nonce | | +-----------------------------+---------------------------------+ | Exposure Statement | evidence_rejected diagnostic | | presented at a second RP | (aud mismatch) | +-----------------------------+---------------------------------+ | Forged Exposure Statement | evidence_rejected; consumption | | copying a legitimate iss | record unchanged | | and jti | | +-----------------------------+---------------------------------+ | Authentic Exposure | evidence_rejected; later | | Statement presented with | legitimate presentation | | another agent's key or | succeeds | | nonce | | +-----------------------------+---------------------------------+ | Accepted Exposure Statement | invalid, binding_mismatch; | | in a presentation that is | request rejected; statement not | | invalid | consumed | +-----------------------------+---------------------------------+ | Accepted Exposure | statement remains consumed | | Statement, action later | | | refused by RP policy | | +-----------------------------+---------------------------------+ | Two Status List Tokens with | token with later exp selected, | | equal iat and status, | regardless of input order | | different exp | | +-----------------------------+---------------------------------+ | Only an optional evidence | evidence not relied on; RP | | status token too old at A | policy reapplied; outcome | | | unchanged | +-----------------------------+---------------------------------+ | Exposure Statement reused | request rejected by the | | at the same RP after the | authorization server (consumed | | first signature expired | jti) | +-----------------------------+---------------------------------+ | Status List Token for a | fresh validation at A, or | | mandate fresh at T but | indeterminate path | | older than max_status_age | | | at A | | +-----------------------------+---------------------------------+ Hulea Expires 5 May 2027 [Page 49] Internet-Draft Agent Mandates November 2026 | Two sum_max with the same | invalid, malformed | | budget and different ptr in | | | one Permission | | +-----------------------------+---------------------------------+ | Validation Profile with a | profile refused; no validation | | schema lacking $schema | | | 2020-12 | | +-----------------------------+---------------------------------+ | Chain without a reachable | invalid, chain_broken; | | root | authority is not_evaluated | +-----------------------------+---------------------------------+ | Mandate in the chain with | invalid, signature_invalid on | | an invalid signature | that mandate; its claims and | | | those of every mandate below it | | | omitted | +-----------------------------+---------------------------------+ | Status issuer of a mandate | indeterminate, status_untrusted | | accepted only under another | | | framework | | +-----------------------------+---------------------------------+ | Status value 0x03 for a | indeterminate, | | mandate with no mapping in | status_unrecognized | | status_values | | +-----------------------------+---------------------------------+ | Two requests validated at | second denied at authorization | | the same T, both within | time A | | budget alone | | +-----------------------------+---------------------------------+ | Token used after the sub- | rejected at the resource server | | delegated mandate's exp | | +-----------------------------+---------------------------------+ | Root perms broader than the | invalid, | | referenced assertion's | authority_insufficient; | | powers | alternatives empty | +-----------------------------+---------------------------------+ | Root references one | invalid, authority_missing; | | Authority Assertion that is | authority_not_presented | | not presented | diagnostic | +-----------------------------+---------------------------------+ | Root references one | invalid; expired, | | Authority Assertion that is | authority_insufficient | | past its exp | | +-----------------------------+---------------------------------+ | Root references two | valid; authority_not_presented | | Authority Assertions, one | diagnostic | | established and one not | | | presented | | +-----------------------------+---------------------------------+ Hulea Expires 5 May 2027 [Page 50] Internet-Draft Agent Mandates November 2026 | Root references two | valid; expired diagnostic | | Authority Assertions, one | | | established and one expired | | +-----------------------------+---------------------------------+ | Only Status List Token for | indeterminate, status_stale | | a mandate older than | | | max_status_age | | +-----------------------------+---------------------------------+ | Only Status List Token for | indeterminate, status_stale | | a mandate issued after T + | | | max_clock_skew | | +-----------------------------+---------------------------------+ | Only Status List Token for | indeterminate, status_untrusted | | a mandate both from an | | | issuer not accepted and too | | | old | | +-----------------------------+---------------------------------+ | sum_max with period above | invalid, lifetime_exceeded | | the framework's max_period | | +-----------------------------+---------------------------------+ | Sub-delegated mandate whose | invalid, chain_inconsistent | | principal differs from the | | | parent's | | +-----------------------------+---------------------------------+ | Sub-delegated mandate whose | invalid, chain_inconsistent | | exp is later than the | | | parent's | | +-----------------------------+---------------------------------+ | Root with delegator equal | invalid, self_not_permitted; | | to principal under a scheme | authority is self | | not in self_schemes | | +-----------------------------+---------------------------------+ | Root with delegator equal | invalid, malformed; authority | | to principal that carries | is not_evaluated | | authority | | +-----------------------------+---------------------------------+ | Root tf without an entry in | invalid, framework_not_accepted | | frameworks | only; authority is | | | not_evaluated; claims empty | +-----------------------------+---------------------------------+ | Request whose type has no | invalid, action_not_permitted; | | Type Profile | perm_not_matching for each | | | Permission | +-----------------------------+---------------------------------+ | Request that fails its Type | invalid, request_malformed; no | | Profile schema | perm_not_matching | +-----------------------------+---------------------------------+ Hulea Expires 5 May 2027 [Page 51] Internet-Draft Agent Mandates November 2026 Table 4: Conformance cases Appendix C. Relationship to Other Work [RFC8693], RFC: Overlap: token exchange across domains, subject and actor. Reused as transport; this document adds a mandate token type and evidence of the delegator's authority. [RFC9396], RFC: Overlap: fine-grained authorization details. Reused for Permissions; this document adds predicates, Type Profiles, and matching rules. [I-D.ietf-wimse-aims], WG draft: Overlap: applying existing standards to agents. Complementary; this document addresses acceptance of mandates across domains. [I-D.asor-wimse-agent-delegation-chain], individual draft: Overlap: attenuated delegation chain, RAR, hash-linked parents, typed constraints, deterministic verification. Its verification shows that no hop exceeded the root, and it states that it cannot show that the root was right; this document supplies evidence for the root. The correspondence between the two constraint vocabularies is given below. [I-D.sweeney-wimse-credential-delegation], individual draft: Overlap: delegation of credentials to agents, with constraint ceilings shared with the asor chain. Complementary; this document adds evidence of the delegator's authority. [I-D.hamr-oauth-agent-delegation], individual draft: Overlap: delegation chain in HTTP Message Signatures, independent attestations. Different transport; this document adds evidence of the delegator's authority. [I-D.reece-wimse-cross-org-delegation], individual draft: Overlap: requirements for cross-organization delegation. This document proposes a mechanism for several of its requirements. [I-D.yossif-agent-mandate-problem], individual draft: Overlap: problem statement for verifiable mandates. This document proposes a mechanism for binding actions to signed limits. [I-D.tanase-ain-authoritative-resolution], individual draft: Overlap: resolution of an agent's authority and state to competent sources, and evidence at decision time. Complementary: there evidence is resolved from sources, here the agent presents it. Hulea Expires 5 May 2027 [Page 52] Internet-Draft Agent Mandates November 2026 Resolution is one way a Trust Framework could supply the Trust Anchor Set. The status codes of step 7 keep apart the unavailable, stale, and conflicting status evidence that its Section 10.9 distinguishes; the value not_evaluated of authority reports a check skipped for a failed prerequisite. [I-D.wadkins-agentproto-action-determinability] and [I-D.konda-agentproto-evaluation-state], individual drafts: Overlap: determining afterwards what an action relied on, and keeping evaluation state that could not be established apart from a negative finding. The Validation Result fixes the Validation Profile and the issuer it names, the Trust Anchor Set, the mandates in the chain, and the evidence it relied on or rejected, by digest; it reports how fresh the selected status evidence was, and keeps unresolved status apart from revocation. The first of these documents states four requirements: DET-1 (action and transition binding), DET-2 (decision-time binding), DET-3 (independent retrospective determination), and DET-4 (negative, transferred, and incomplete transitions). This addresses the part of DET-2 that concerns validation at T. It does not yet define the record of the authorization decision, a binding of that record outside the RP's control, or the retention of the referenced bytes, which the rest of DET-2 and DET-3 need. On DET-1, the retained result does not yet identify the request that was matched or the RP that decided; that comes with the decision record. On the completeness clause of DET-4, authority_not_presented reports every referenced Authority Assertion that was not presented. [OIDF-AGENTIC] and [COSAI-AIAM], industry papers: Overlap: agent identity, delegation, cross-domain trust. This document gives concrete formats and validation for one part of that space. The common thread in the chain proposals is that verification proves the chain narrows from its root and treats the root issuer's authority as given. This document's distinct contribution is the evidence for that root: who the delegator is, what powers an Authority Source attests, and how a Validator checks the root against those powers under an explicit Validation Profile. The chain mechanics in Section 4.8 overlap with [I-D.asor-wimse-agent-delegation-chain]. The intended direction is to carry the chain in that format and keep this document's scope to Authority Assertions, attribution, the Validation Profile, the Validation Result, and the trust framework boundary. This revision keeps its own chain and predicates because three predicates have no counterpart among the asor constraint types today. The author of the asor draft has indicated that its constraint type registry could take Hulea Expires 5 May 2027 [Page 53] Internet-Draft Agent Mandates November 2026 two types defined by this document: decimal amounts located by JSON Pointer, and a per-period measurement scope. cosign_above would remain a requirement on the RP, outside the chain algorithm. The predicates of this document correspond to the asor types as follows: eq and in: Correspond to one_of, with a single element for eq. Values are compared by the identity in Section 4.6. max and min: Correspond to the per-action max and min. This document compares decimal strings exactly and does not allow JSON numbers for amounts; the asor types compare JSON numbers. window: No counterpart. The asor chain bounds time through token validity. sum_max: No counterpart. It bounds a total over a period, such as a monthly limit; the asor max_lifetime bounds a total per token, and max_subtree a total per subtree. cosign_above: No counterpart. It produces an Obligation that the RP discharges, not a permit or a denial. The constrained value: A ptr here is a JSON Pointer resolved in the request; an asor key names the constrained dimension. The asor types not_one_of, prefix, and rank have no counterpart here. Appendix D. Open Issues * Carrying the chain in the format of [I-D.asor-wimse-agent-delegation-chain], intended for the next revision: an amount type and a per-period type defined here and registered in its constraint type registry, cosign_above kept as a requirement on the RP outside the chain constraints, and a decision on window. * The record of the authorization decision, its binding outside the RP's control, and the retention of the bytes that Validation Results reference, planned for the next revision. * Fixing in the Validation Result the set of Status List Tokens presented, not only the one selected, so that an unresolved status can be checked afterwards. * Whether claims should report the powers of an authenticated Authority Assertion that does not support the root, so that the RP sees what produced authority_insufficient. Hulea Expires 5 May 2027 [Page 54] Internet-Draft Agent Mandates November 2026 * A CBOR/CWT encoding. * Presentation outside OAuth Token Exchange. * Shared budget accounting across RPs. * Cumulative limits on a delegator's authority across root mandates, for example a budget identifier issued by the Authority Source. * Several actions in one request or token, with atomic reservation for the whole batch. * A predicate for refunds and reversals. * Signed test vectors for every conformance case. * A human-readable rendering of mandates for delegator consent. Changes from -00 * Validation Result: anchors fixes the Trust Anchor Set by URI and digest; status_evidence and the claims of supporting Authority Assertions carry iat and exp; every entry in errors and diagnostics has a defined form; references carry only dig; alternatives is empty when the outcome is invalid; numbers are compared by value. * Trust Anchor Set: defined as a JSON document. Anchors list issuer identifiers, and "verifies under an anchor" is defined once. * Validation Profile: iss added, with an optional detached signature; max_lifetime renamed max_validity and keyed by typ, to avoid a clash with the asor constraint type of the same name; max_period moved out of it into a member of its own; self_schemes added; Type Profile members named. * Status: status_unavailable now means only that no token for the list was presented. status_untrusted, status_stale, status_conflict, and status_unrecognized report the other cases that -00 reported as status_unavailable, with the same outcome. * Authority check: the references in authority are alternatives; codes of other referenced assertions become diagnostics when authority is established; authority_not_presented lists each reference not presented; self is restricted by self_schemes; the value unknown is renamed supported_status_unresolved. Hulea Expires 5 May 2027 [Page 55] Internet-Draft Agent Mandates November 2026 * Procedure: step 2 checks the content rules of Section 4 and Section 5; step 8 checks every condition of Section 4.8, with the new code chain_inconsistent; skipped steps and requests of unlisted types are defined; the outcome follows the effect of each code. * Constraints: the value type of each predicate is fixed; a value of another type is malformed; a sum_max period above max_period is lifetime_exceeded. * Authorization: the checks at A and the access token's exp also respect the WIT's exp; an RP that cannot discharge a sum_max Obligation denies; a cosign_above Obligation appears only above its threshold. * Procedure, further: chain_too_long means no root is reached; when no accepted framework context exists, optional evidence is rejected; artifacts in mandate_evidence that are neither in the chain nor referenced are ignored; pop_failed is recorded even without a WIT; the WIT requires iat; step 4 names the verifier anchor and the order of checks for a sub-delegated mandate; step 7 checks the token's typ, sub, and list entry; SD-JWT disclosures are ignored; the claims of a sub-delegated mandate need every ancestor verified. * Budgets are keyed by a reference to the root mandate, not its jti. * Registry of validation codes: "Recorded as", "Effect as error", and members per code. * Conformance cases corrected and extended. Acknowledgments Douglas Wadkins asked that the evidence a decision relied on, and its freshness, be determinable afterwards. J S He found the gaps in the authority check, proposed the authority cases in Appendix B, and published the first signed vectors for this document. Kieran Sweeney pointed out the clash of max_lifetime with the asor constraint type. Girish Konda and Elena Tanase asked that missing, stale, and conflicting status be reported apart. Rafael Asor indicated that the constraint type registry of his draft could take the decimal amount and per-period types defined here. Author's Address Hulea Expires 5 May 2027 [Page 56] Internet-Draft Agent Mandates November 2026 Claudiu Hulea Braincap SRL Bucharest Romania Email: claudiu.hulea@braincap.ro Hulea Expires 5 May 2027 [Page 57]