Network Working Group D. Watts Internet-Draft Independent Researcher Intended status: Informational 12 September 2026 Expires: 16 March 2027 Agent Authority Transition Receipts for Agentic Systems draft-watts-agent-authority-transition-receipts-00 Abstract Autonomous agents increasingly act across administrative and security domains using workload identities, OAuth credentials, delegated authorization, attestations, and policy engines. Existing mechanisms can establish identity, delegation, or access rights, but deployments still lack a common artifact that records which policy and which evidence were evaluated when an operation moved into an authorized, denied, revoked, or expired authority state. This document defines an Agent Authority Transition Receipt (AATR), a signed, non-bearer receipt that cryptographically binds an agent operation to the principal, policy, evidence set, decision, audience, validity interval, and predecessor authority state used for that decision. AATR intentionally separates evidence from authorization and authorization from execution. Missing or indeterminate required evidence fails closed. AATR is designed to compose with OAuth, workload identity, remote attestation, transparency services, and agent-specific delegation protocols rather than replace them. 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 16 March 2027. Watts Expires 16 March 2027 [Page 1] Internet-Draft Agent Authority Transition Receipts September 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 2. Conventions and Requirements Language . . . . . . . . . . . . 3 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 4. Authority-State Model . . . . . . . . . . . . . . . . . . . . 4 5. AATR Claims Set . . . . . . . . . . . . . . . . . . . . . . . 4 6. Evidence Entries . . . . . . . . . . . . . . . . . . . . . . 6 7. Receipt Identifier and Canonicalization . . . . . . . . . . . 6 8. Signing and Verification . . . . . . . . . . . . . . . . . . 6 9. Normative Verification Algorithm . . . . . . . . . . . . . . 7 10. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 11. Composition with Existing Protocols . . . . . . . . . . . . . 8 12. Non-Bearer Semantics . . . . . . . . . . . . . . . . . . . . 9 13. Revocation and Staleness . . . . . . . . . . . . . . . . . . 9 14. Privacy Considerations . . . . . . . . . . . . . . . . . . . 10 15. Security Considerations . . . . . . . . . . . . . . . . . . . 10 16. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 17. Deployment and Incremental Adoption . . . . . . . . . . . . . 11 18. Relationship to Current Agent Authorization Work . . . . . . 11 19. Open Issues for Discussion . . . . . . . . . . . . . . . . . 11 20. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . 12 21. Normative References . . . . . . . . . . . . . . . . . . . . 12 22. Informative References . . . . . . . . . . . . . . . . . . . 12 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 13 Appendix B. Author's Address . . . . . . . . . . . . . . . . . . 14 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 14 Watts Expires 16 March 2027 [Page 2] Internet-Draft Agent Authority Transition Receipts September 2026 1. Introduction Agentic software can discover services, invoke tools, delegate work, and act asynchronously on behalf of people and organizations. The Internet security stack already provides strong mechanisms for authentication, authorization, delegation, workload identity, and remote attestation. However, a recurring operational gap remains: after a policy engine consumes one or more pieces of evidence and decides whether an operation is authorized, there is no broadly interoperable receipt format that binds the decision to the exact policy, evidence, action, and authority state evaluated at that time. This document addresses that gap with the Agent Authority Transition Receipt (AATR). AATR is not a new identity system, not a replacement for OAuth access tokens, not an attestation format, and not a delegation protocol. It is a decision receipt. The design follows a non-collapse rule: evidence is not authorization, authorization is not execution, and successful execution is not proof that authorization was valid. Each promotion between those layers requires an explicit decision and a verifiable artifact. 2. Conventions and Requirements Language 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. 3. Terminology Principal The human or organizational authority on whose behalf an agent operation is proposed. Agent A software workload capable of proposing or performing operations, directly or through delegated tools. Operation A bounded action request identified by a stable request identifier and a digest over its security-relevant parameters. Evidence Machine-verifiable input used by a policy decision, such as an attestation result, delegation object, workload identity assertion, risk signal, or provenance statement. Policy Decision Point (PDP) The component that evaluates an Watts Expires 16 March 2027 [Page 3] Internet-Draft Agent Authority Transition Receipts September 2026 operation, policy, and required evidence to produce an authority decision. Authority State One of PROPOSED, EVALUATED, AUTHORIZED, DENIED, REVOKED, or EXPIRED. AATR A signed, non-bearer receipt that records one authority-state transition for one operation. Required Evidence Evidence that the applicable policy declares necessary before a transition to AUTHORIZED can occur. 4. Authority-State Model AATR models authorization as a state transition rather than as a property inferred from successful execution. The normal decision sequence is: PROPOSED -> EVALUATED -> AUTHORIZED \-> DENIED AUTHORIZED -> REVOKED AUTHORIZED -> EXPIRED An implementation MUST NOT issue an AUTHORIZED transition if any required evidence is missing, invalid, failed, or indeterminate. Indeterminate evidence is not permission. AATR does not define execution-state transitions. An authorized operation can still fail to execute, and an executed operation can still be shown later to have relied on invalid or stale authority. Execution receipts can be layered separately. 5. AATR Claims Set The AATR Claims Set is a JSON object. The security-relevant claims defined by this document are shown below. Additional claims MAY be present, but a verifier MUST NOT treat an unknown extension as satisfying a required evidence predicate. +===============+==============+=================================+ | Claim | Requirement | Description | +===============+==============+=================================+ | ver | REQUIRED | AATR version. This document | | | | defines "1". | +---------------+--------------+---------------------------------+ | rid | REQUIRED | Receipt identifier derived from | | | | the canonical core claims. | Watts Expires 16 March 2027 [Page 4] Internet-Draft Agent Authority Transition Receipts September 2026 +---------------+--------------+---------------------------------+ | iss | REQUIRED | Identifier of the issuing PDP | | | | or authority service. | +---------------+--------------+---------------------------------+ | aud | REQUIRED | Intended relying party or | | | | resource audience. | +---------------+--------------+---------------------------------+ | principal | REQUIRED | Identifier of the represented | | | | principal. | +---------------+--------------+---------------------------------+ | agent | REQUIRED | Identifier of the acting agent | | | | or workload. | +---------------+--------------+---------------------------------+ | request_id | REQUIRED | Stable identifier for the | | | | proposed operation. | +---------------+--------------+---------------------------------+ | action_digest | REQUIRED | Digest over the security- | | | | relevant operation parameters. | +---------------+--------------+---------------------------------+ | from | REQUIRED | Previous authority state. | +---------------+--------------+---------------------------------+ | to | REQUIRED | New authority state. | +---------------+--------------+---------------------------------+ | policy | REQUIRED | Policy identifier, version, and | | | | digest. | +---------------+--------------+---------------------------------+ | evidence | REQUIRED | Array of evidence references | | | | and evaluation states. | +---------------+--------------+---------------------------------+ | iat | REQUIRED | Issuance time. | +---------------+--------------+---------------------------------+ | exp | REQUIRED for | Authority expiration time. | | | AUTHORIZED | | +---------------+--------------+---------------------------------+ | nonce | RECOMMENDED | Freshness value bound to the | | | | operation. | +---------------+--------------+---------------------------------+ | prev | OPTIONAL | Predecessor AATR identifier for | | | | chained transitions. | +---------------+--------------+---------------------------------+ | reason | RECOMMENDED | Stable machine-readable | | | | decision reason code. | +---------------+--------------+---------------------------------+ Table 1: AATR Claims Watts Expires 16 March 2027 [Page 5] Internet-Draft Agent Authority Transition Receipts September 2026 6. Evidence Entries Each evidence entry MUST identify the evidence type, digest, status, and the policy predicate it is intended to satisfy. The status vocabulary defined by this document is SATISFIED, FAILED, UNKNOWN, and MISSING. An AUTHORIZED AATR MUST contain only SATISFIED status for every evidence predicate marked required by the referenced policy. A relying party MUST reject an AUTHORIZED AATR if it cannot determine that all required predicates were satisfied. Raw evidence SHOULD NOT be embedded when a digest and an access- controlled reference are sufficient. This reduces correlation and disclosure risk. 7. Receipt Identifier and Canonicalization The receipt identifier is computed over a canonical JSON representation of the core claims using the JSON Canonicalization Scheme [RFC8785]. The rid claim itself and signature container are excluded from this calculation. core = AATR claims excluding "rid" and signature container canonical = JCS(core) digest = SHA-256(canonical) rid = "sha256:" || lowercase-hex(digest) SHA-256 is used as specified by [RFC6234]. Implementations that introduce other digest algorithms require an explicit algorithm identifier and downgrade protections. 8. Signing and Verification An AATR MUST be integrity protected by a signature mechanism that identifies the issuing authority. This document profiles JSON Web Signature (JWS) [RFC7515] for the initial representation. The JWS payload is the UTF-8 encoding of the AATR Claims Set including rid. A verifier MUST validate the signature, issuer, audience, time bounds, receipt identifier, predecessor linkage when present, action digest, policy digest, and evidence predicates before accepting the receipt. The alg value "none" MUST NOT be accepted. Algorithm agility follows the JOSE registries. Deployments SHOULD use algorithms that meet their current security policy and key-management requirements. Watts Expires 16 March 2027 [Page 6] Internet-Draft Agent Authority Transition Receipts September 2026 9. Normative Verification Algorithm 1. Parse the JWS and reject malformed input. 2. Verify the signature using a key trusted for the declared issuer. 3. Verify that aud identifies the current relying party. 4. Recompute rid from the RFC 8785 canonical core and compare it in constant time where practical. 5. Verify iat, exp, and local freshness policy. 6. Verify that request_id and action_digest match the operation under consideration. 7. Resolve the referenced policy and verify its identifier, version, and digest. 8. Determine the set of required evidence predicates from that policy. 9. Verify each evidence reference according to its evidence type. 10. If any required predicate is FAILED, UNKNOWN, MISSING, unverifiable, or stale, reject an AUTHORIZED transition. 11. Verify that the from to to transition is permitted by local transition policy and predecessor state. 12. Apply revocation checks required by the issuer, policy, or local deployment. 10. Example Watts Expires 16 March 2027 [Page 7] Internet-Draft Agent Authority Transition Receipts September 2026 { "ver": "1", "rid": "sha256:4f8e...d021", "iss": "https://authority.example.net/pdp", "aud": "https://api.example.com", "principal": "acct:alice@example.net", "agent": "spiffe://example.net/agent/finance-helper", "request_id": "req-7c91d4", "action_digest": "sha256:05bd...ab10", "from": "EVALUATED", "to": "AUTHORIZED", "policy": { "id": "payments.transfer", "version": "12", "digest": "sha256:c1aa...9204" }, "evidence": [ { "type": "delegation", "digest": "sha256:18c2...7731", "predicate": "principal_delegation", "status": "SATISFIED" }, { "type": "workload-attestation", "digest": "sha256:99a4...33ef", "predicate": "approved_runtime", "status": "SATISFIED" } ], "iat": 1789273200, "exp": 1789273260, "nonce": "CzX7wqYq2WmV0g", "reason": "policy-permit" } The example is illustrative. The receipt does not itself grant bearer access to the resource. The resource server can require an OAuth access token or another authorization credential in addition to the AATR. 11. Composition with Existing Protocols AATR is designed as a narrow composition layer. Watts Expires 16 March 2027 [Page 8] Internet-Draft Agent Authority Transition Receipts September 2026 * OAuth 2.0 Token Exchange [RFC8693] can represent delegated security tokens. Rich Authorization Requests [RFC9396] can carry fine-grained authorization details. AATR records the subsequent authority-state decision and the evidence/policy inputs used to make it. * Demonstrating Proof of Possession at the Application Layer (DPoP) [RFC9449] binds OAuth tokens to a key. AATR does not replace proof of possession. * RATS [RFC9334] defines roles and artifacts for remote attestation. An Attestation Result can be referenced as one AATR evidence input. * WIMSE work defines workload identity mechanisms for multi-system environments. AATR can identify the agent using a WIMSE- compatible workload identifier without defining a new workload identity scheme. * Agent delegation and operation-authorization proposals can supply delegation or operation evidence. AATR's distinct purpose is to record the policy transition from evaluated evidence to an authority state. 12. Non-Bearer Semantics An AATR is evidence of an authority decision, not a bearer credential. Possession of a valid AATR alone MUST NOT cause a resource server to grant access unless a separate protocol explicitly profiles AATR as part of its authorization exchange. This distinction prevents receipt laundering, where an audit artifact is replayed as though it were an access token. 13. Revocation and Staleness An issuer can revoke authority by issuing a later AATR that transitions the same operation or authority lineage to REVOKED. Relying parties that accept chained AATRs MUST define how they discover later receipts or revocation status. Evidence that was fresh when an earlier decision was issued can later become stale. Therefore a relying party MUST NOT assume that an old AUTHORIZED AATR remains usable beyond its expiration or local freshness policy. Watts Expires 16 March 2027 [Page 9] Internet-Draft Agent Authority Transition Receipts September 2026 14. Privacy Considerations AATR can correlate principals, agents, actions, policies, and evidence. Implementations SHOULD minimize receipt contents, avoid embedding natural-language prompts or raw private evidence, use audience restriction, and apply retention controls. Digests can still leak information when the underlying value comes from a low-entropy space. Implementations MUST NOT assume that a digest automatically anonymizes the referenced data. Cross-domain deployments should consider pairwise or scoped identifiers when a globally stable identifier is unnecessary. 15. Security Considerations AATR is security-sensitive because relying parties can use it to decide whether a prior authorization decision is trustworthy. Implementations must address at least the following threats. Replay Bind receipts to audience, operation digest, freshness values, and short validity windows. Confused deputy Verify both represented principal and acting agent; do not infer one identity from the other. Policy substitution Verify the exact policy digest and version, not only a human-readable policy name. Evidence substitution Verify type, digest, freshness, and required predicate for each evidence entry. Receipt laundering Do not treat AATR as a bearer token. Key compromise Support issuer key rotation, revocation, and bounded receipt lifetimes. Indeterminate evidence Unknown, missing, stale, or unverifiable required evidence must not be promoted into authorization. Log compromise Optional transparency logging can improve detection, but log inclusion alone does not establish policy correctness. 16. IANA Considerations This version of the document requests no IANA actions. A future revision that standardizes a dedicated media type or registry will specify those actions explicitly. Watts Expires 16 March 2027 [Page 10] Internet-Draft Agent Authority Transition Receipts September 2026 17. Deployment and Incremental Adoption AATR can be introduced without replacing an existing authorization stack. A deployment can begin by issuing receipts in audit-only mode, compare them against existing policy decisions, and later require verified receipts at selected high-consequence enforcement points. This incremental profile is particularly useful for agentic workflows spanning multiple trust domains, where identity, delegation, attestation, and authorization are already produced by different systems. 18. Relationship to Current Agent Authorization Work Multiple active Internet-Drafts address agent identity, delegation, authorization, and Internet architecture. The Delegation Receipt Protocol records user-to-operator delegation. Agent Operation Authorization defines an operation-specific authorization framework. WIMSE work addresses workload identity. Other proposals define agent identity and delegation tokens. AATR is deliberately narrower: it standardizes the verifiable record of a policy-mediated authority state transition and the evidence that the policy consumed. This separation is intended to make the mechanism composable rather than competitive. If existing authorization protocols later define equivalent receipt semantics, AATR can be profiled as a common claims model or folded into that work. 19. Open Issues for Discussion * Whether the initial representation should remain JWS-only or also define a COSE/CBOR profile. * Whether a standard transition-state registry is useful or local policy should define additional states. * How revocation discovery should compose with short-lived credentials and transparency services. * Whether receipt chaining should remain optional or become mandatory for multi-hop agent workflows. * Which IETF venue should own the work if the community finds the problem worth standardizing. Watts Expires 16 March 2027 [Page 11] Internet-Draft Agent Authority Transition Receipts September 2026 20. Conclusion Agentic systems increasingly combine identity, delegation, attestation, policy, and automated execution. AATR adds a narrow missing object: a verifiable receipt that says which authority state changed, for which operation, under which policy, using which evidence. By keeping evidence, authorization, and execution distinct, deployments can make high-consequence agent actions easier to audit, revoke, compare across domains, and reason about without requiring a new identity system or a new authorization token format. 21. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC7515] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Signature (JWS)", RFC 7515, DOI 10.17487/RFC7515, May 2015, . [RFC8785] Rundgren, A., Jordan, B., and S. Erlandsson, "JSON Canonicalization Scheme (JCS)", RFC 8785, DOI 10.17487/RFC8785, June 2020, . [RFC6234] Eastlake, D. and T. Hansen, "US Secure Hash Algorithms (SHA and SHA-based HMAC and HKDF)", RFC 6234, DOI 10.17487/RFC6234, May 2011, . 22. Informative References [RFC8693] Jones, M., Nadalin, A., Campbell, B., Bradley, J., and C. Mortimore, "OAuth 2.0 Token Exchange", RFC 8693, January 2020, . [RFC9396] Lodderstedt, T., Campbell, B., and J. Bradley, "OAuth 2.0 Rich Authorization Requests", RFC 9396, May 2023, . Watts Expires 16 March 2027 [Page 12] Internet-Draft Agent Authority Transition Receipts September 2026 [RFC9449] Fett, D., Campbell, B., Bradley, J., Lodderstedt, T., and M. Jones, "OAuth 2.0 Demonstrating Proof of Possession (DPoP)", RFC 9449, September 2023, . [RFC9334] Birkholz, H., Thaler, D., Richardson, M., Smith, N., and W. Pan, "Remote ATtestation procedureS (RATS) Architecture", RFC 9334, January 2023, . [I-D.nelson-agent-delegation-receipts] Nelson, R., "Delegation Receipt Protocol for AI Agent Authorization", Work in Progress, Internet-Draft, draft- nelson-agent-delegation-receipts-10, June 2026, . [I-D.liu-agent-operation-authorization] Liu, D., Zhu, H., and S. Krishnan, "Agent Operation Authorization", Work in Progress, Internet-Draft, draft- liu-agent-operation-authorization-02, March 2026, . [I-D.ietf-wimse-arch] "Workload Identity in a Multi System Environment (WIMSE) Architecture", Work in Progress, Internet-Draft, draft- ietf-wimse-arch-08, July 2026, . [I-D.daniel-ai-agent-internet-architecture] Park, S. D., "Architectural Requirements for Supporting AI Agents on the Internet", Work in Progress, Internet-Draft, draft-daniel-ai-agent-internet-architecture-00, August 2026, . Appendix A. Acknowledgments The author thanks the IETF community members working on OAuth, workload identity, remote attestation, software transparency, and emerging agent authorization for the protocol foundations that make a narrow receipt layer possible. Watts Expires 16 March 2027 [Page 13] Internet-Draft Agent Authority Transition Receipts September 2026 Appendix B. Author's Address Deonte Watts Independent Researcher San Francisco, California, United States Email: deonte@goodshyt.fun ORCID: https://orcid.org/0009-0005-8586-3650 Author's Address Deonte Watts Independent Researcher San Francisco, California United States Email: deonte@goodshyt.fun URI: https://orcid.org/0009-0005-8586-3650 Watts Expires 16 March 2027 [Page 14]