Agent Authority Transition Receipts for Agentic Systems

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.¶

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

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 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.¶

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.¶

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

{
  "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.¶

• 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.¶

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.¶

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.¶

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.¶

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.¶

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