Evidence-Bounded Authorization for Agentic Systems: Evidence Qualification Receipts

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

Autonomous agents increasingly act on premises derived from model inference, retrieved memory, external tools, telemetry, documents, and other agents. Authentication can establish an actor's identity. Delegation can establish on whose behalf that actor operates. Authorization can establish whether a requested operation is permitted. None of those steps, by themselves, establish whether the proposition used to justify the action is adequately supported.¶

This creates a failure mode that is easy to miss in otherwise well-designed authorization systems: a correctly authenticated and correctly authorized agent can still execute an action because an unsupported, stale, contradictory, or merely speculative premise was treated as though it were established evidence.¶

This document defines an Evidence Qualification Receipt (EQR). An EQR binds an exact proposition digest to a versioned evidence-requirements profile, evidence digests, contradiction state, temporal context, and one of three evaluation results: PASS, FAIL, or INDETERMINATE. It is intended to be consumed by an authorization system as one input among identity, delegation, policy, action, and resource context.¶

The design follows four non-collapse rules:¶

• Integrity is not admissibility.¶
• Evidence is not authority.¶
• Qualification is not authorization.¶
• Authorization is not execution.¶

In particular, a cryptographically valid EQR with evaluation status PASS does not grant a capability, mint an access token, or require a resource server to execute an operation.¶

This document is deliberately transport-neutral. It does not define a replacement for OAuth, workload identity, RATS, SCITT, or agent communication protocols. Profiles can bind an EQR or an EQR digest to those systems.¶

2. Conventions and Terminology

The key words MUST, MUST NOT, REQUIRED, SHOULD, SHOULD NOT, and MAY 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.¶

Proposition

An exact declarative claim whose support state is being evaluated.¶

Evidence Profile

A versioned set of requirements defining what evidence, freshness, contradiction handling, comparison rules, and other checks are required for a proposition class.¶

Evidence Qualification Receipt (EQR)

An immutable result object binding a proposition, profile, evidence references, and evaluation outcome.¶

Issuer

The system that evaluates the declared profile and produces the EQR. Issuer identity is not proof that the evaluation is substantively correct.¶

Verifier

A component that validates an EQR's syntax, integrity, bindings, freshness, and local acceptability before making it available to authorization policy.¶

Authorization System

The component that decides whether an actor may perform an action on a resource. It can consume an EQR but remains authoritative for the permission decision.¶

PASS

All required profile checks are satisfied within the declared scope and tolerances.¶

FAIL

At least one required profile check is contradicted or violated.¶

INDETERMINATE

No required check has established FAIL, but one or more required inputs, bridges, freshness conditions, or contradiction resolutions are missing or unresolved.¶

3. Problem Statement and Non-Collapse Requirements

Current agent authorization work correctly focuses on identity, delegation, user consent, policy, transaction binding, and provenance. A separate question arises before a high-consequence action: what evidence supports the proposition that made the action appear necessary or appropriate?¶

Examples include a payment agent acting because it believes an invoice is overdue, an operations agent restarting a service because it believes a health check failed, or a research agent promoting a result because it believes an experiment met a preregistered criterion. The permission to perform an operation and the evidence supporting the premise for that operation are different objects.¶

An implementation conforming to this document MUST NOT interpret PASS as an authorization decision. It MUST NOT interpret receipt integrity as evidence sufficiency. It MUST NOT convert INDETERMINATE into PASS because an action is time-sensitive or because other authorization inputs are valid.¶

The following implication is therefore invalid:¶

 authenticated actor
       +
 valid delegation
       +
 permitted operation
       +
 signed evidence object
       |
       X  does not imply
       v
 "the triggering proposition is adequately supported"

EQR adds an explicit qualification step without changing which authorization system ultimately controls execution.¶

4. Architecture

          proposition + evidence + profile
                       |
                       v
              +------------------+
              | EQR Evaluator    |
              +------------------+
                       |
                PASS / FAIL /
                INDETERMINATE
                       |
                       v
              +------------------+
              | EQR Verifier     |
              +------------------+
                       |
              qualified input only
                       |
       +---------------+----------------+
       | identity | delegation | policy |
       | action   | resource   | EQR    |
       +---------------+----------------+
                       |
                       v
              +------------------+
              | Authorization    |
              | System           |
              +------------------+
                 ALLOW / DENY
                       |
                       v
                  execution

The evaluator and verifier can be the same deployment component, but their logical responsibilities are distinct. The evaluator determines the profile outcome. The verifier determines whether the receipt can be trusted and used in the current context.¶

An authorization system MAY require no EQR for low-consequence operations and a particular EQR profile for higher-consequence operations. This document does not define those local risk classes.¶

5. Evidence Qualification Receipt Data Model

An EQR payload is a JSON object as defined by [RFC8259]. Implementations that compute a digest over a JSON payload SHOULD use the JSON Canonicalization Scheme [RFC8785] before hashing. When an EQR binds a non-JSON proposition, evidence object, profile, context, or action, the applicable profile MUST define the canonical byte representation that is hashed.¶

The following members are defined:¶

version

String. This document defines version 1.¶

receipt_id

A URI identifying this immutable receipt, using URI syntax from [RFC3986].¶

issuer

A URI identifying the EQR issuer.¶

issued_at and expires_at

Timestamps bounding receipt freshness. They MUST use the Internet date/time format defined by [RFC3339].¶

profile

Object containing a stable profile identifier and digest of the exact profile bytes used.¶

claim

Object containing a stable claim identifier and digest of the exact proposition evaluated.¶

context_digest

Optional digest binding the evaluation to a declared snapshot, transaction, or other context.¶

action_digest

Optional digest binding the receipt to a proposed action. High-consequence profiles SHOULD require this member when the proposition is evaluated specifically to justify an action.¶

evaluation

Object containing status, requirements_satisfied, and the number or digests of unresolved blocking contradictions.¶

evidence

Array of evidence descriptors. Each descriptor binds at least a digest and evidence class; deployments can add local metadata such as freshness or an access-controlled retrieval reference. This document defines sha-256 as the mandatory-to-implement digest algorithm [RFC6234]. Digest values MUST use base64url encoding without padding as specified in [RFC4648].¶

supersedes

Optional receipt identifier of a predecessor EQR superseded by new evidence. The predecessor is not modified.¶

nonce

Optional verifier- or transaction-supplied value for replay resistance.¶

{
  "version": "1",
  "receipt_id": "urn:uuid:6ac9f8f0-30e1-4b4c-a142-9f5cb5ad58f1",
  "issuer": "https://qualifier.example",
  "issued_at": "2026-09-12T23:50:00Z",
  "expires_at": "2026-09-13T00:05:00Z",
  "profile": {
    "id": "https://example.org/profiles/invoice-overdue/v1",
    "hash_alg": "sha-256",
    "digest": "BASE64URL(PROFILE_DIGEST)"
  },
  "claim": {
    "id": "urn:example:claim:invoice-8472-overdue",
    "hash_alg": "sha-256",
    "digest": "BASE64URL(PROPOSITION_DIGEST)"
  },
  "context_digest": "BASE64URL(CONTEXT_DIGEST)",
  "action_digest": "BASE64URL(PROPOSED_ACTION_DIGEST)",
  "evaluation": {
    "status": "pass",
    "requirements_satisfied": true,
    "blocking_contradictions": []
  },
  "evidence": [
    {
      "class": "signed_invoice_record",
      "hash_alg": "sha-256",
      "digest": "BASE64URL(EVIDENCE_DIGEST)",
      "fresh_until": "2026-09-13T00:05:00Z"
    }
  ],
  "nonce": "t9mS6wqz2Dbf",
  "supersedes": null
}

6. Integrity Protection and Issuer Authentication

This document does not define a new signature format. An inter-domain EQR MUST be integrity protected and bound to an authenticated issuer using a mechanism acceptable to the verifier. JWS [RFC7515] and COSE Sign1 [RFC9052] are examples of existing mechanisms that can be profiled for this purpose.¶

A verifier MUST NOT infer substantive evidence quality from successful signature verification. Signature validation establishes integrity and issuer binding; it does not establish that the issuer used an adequate evidence profile or evaluated it correctly.¶

7. Receipt Production

Before producing an EQR, an issuer MUST bind the exact proposition and exact evidence profile. The profile MUST identify each required condition and the rule for handling missing values, stale values, contradictory evidence, and comparison tolerances.¶

Where a profile compares multiple representations of the same property, the profile MUST define the comparison space, units, transformation or bridge, snapshot alignment, and tolerance. A unit mismatch or incompatible comparison type is a profile failure. Missing or unresolved calibration is INDETERMINATE.¶

The issuer MUST NOT silently substitute a different proposition, evidence profile, evidence source, or action after evaluation. Such a change requires a new receipt.¶

8. Receipt Verification and Use

A verifier consuming an EQR MUST perform the following checks before exposing the receipt to authorization policy:¶

1. Validate syntax and the supported EQR version.¶

2. Validate required integrity protection and issuer authentication.¶

3. Validate receipt freshness and, when present, nonce or transaction binding.¶

4. Validate the proposition digest against the proposition used by the proposed action.¶

5. Validate the profile identifier and profile digest against an acceptable local profile.¶

6. Validate context and action digests when required by local policy.¶

7. Apply local trust policy to the issuer and evidence classes.¶

8. Expose the EQR evaluation status to the authorization system without rewriting it.¶

A verifier can classify a receipt as syntactically/integrity VALID while its embedded evaluation remains FAIL or INDETERMINATE. Receipt validity and proposition qualification are separate dimensions.¶

def qualifies_for_policy(eqr, local_policy, action):
    if not syntax_and_integrity_valid(eqr):
        return False

    if not fresh_and_bound(eqr, action):
        return False

    if eqr["evaluation"]["status"] != "pass":
        return False

    if eqr["evaluation"]["requirements_satisfied"] is not True:
        return False

    if eqr["evaluation"]["blocking_contradictions"]:
        return False

    return local_policy.accepts_evidence_qualification(eqr, action)

9. Integration with Authorization Systems

Authorization remains a separate function:¶

 authorization_decision =
     local_policy(
         principal,
         delegation,
         proposed_action,
         protected_resource,
         current_context,
         verified_evidence_qualification
     )

 execute only if authorization_decision == ALLOW

Existing agent authorization mechanisms can carry an EQR by value, by digest, or by a reference whose dereferencing and trust semantics are defined by a profile. For example, an OAuth deployment could bind an EQR reference to transaction-specific authorization state or to Rich Authorization Requests [RFC9396]. This document does not register an OAuth authorization-details type or token claim.¶

When an evidence challenge mechanism is used to request missing evidence, satisfying the challenge can result in a newly evaluated EQR. The new EQR is still not authorization and does not guarantee execution.¶

10. Append-Only Lifecycle and Supersession

EQR state is append-only. An implementation MUST NOT mutate an existing receipt from INDETERMINATE to PASS, from FAIL to PASS, or from PASS to another state after issuance.¶

New evidence, a corrected profile, a changed action, or a changed evaluation result requires a new EQR with a new receipt_id. The successor MAY identify its predecessor in supersedes. A verifier MUST NOT treat supersession as deletion of the predecessor.¶

 EQR:v1
 status = indeterminate
        |
        | new evidence
        v
 EQR:v2
 supersedes = EQR:v1
 status = pass

 EQR:v1 remains immutable historical evidence.

This lifecycle allows an audit system to reconstruct what was known, missing, or contradicted at the time of each authorization decision.¶

11. Failure and Error Semantics

Profiles and transports can define their own error codes, but implementations should preserve the following distinctions:¶

Collapsing INVALID, FAIL, INDETERMINATE, and authorization DENY into one generic "false" loses information useful for remediation and auditing.¶

12. Examples

13. Implementation Status

This section is non-normative and is included to provide transparency about the maturity of the design.¶

The author maintains a local Python reference package for a broader fail-closed theoretical profile. The currently frozen package executes finite boundary checks for three-valued prerequisite conjunction, missing and mistyped comparisons, uncertainty crossing tolerance, empty and tied selections, blocked fiction-to-empirical promotion, and unresolved-evidence promotion. The local verification report records 40 named checks passing. It also records that the package is a frozen theoretical candidate, not an empirical validation or deployment authorization.¶

The referenced local package digest is: e53b16656c9a98a4851bfc0b627bd7df189b83c4df77f753361b58b9b8cd7f33. No interoperable network implementation or independent reproduction is claimed by this -00 draft.¶

14. Relationship to Existing Work

AI-agent authentication and authorization work describes how existing identity and authorization standards can be applied to agents [I-D.aiagent-auth]. Agent Operation Authorization defines action-specific authorization proposals and tokens [I-D.agent-operation]. OAuth Authorization Evidence records user confirmation and audit evidence associated with access tokens [I-D.oauth-authz-evidence]. Authorization Evidence Challenge describes how a relying party can request missing authorization evidence [I-D.ae-challenge]. Agent Action Capsule provenance binding relates authorization, memory provenance, and recorded action outcomes [I-D.aac-provenance].¶

EQR is intended to be complementary. Its narrow question is: under a declared evidence profile, what is the current qualification state of the exact proposition being offered as a premise for an action? It neither replaces user consent evidence nor defines the authorization decision itself.¶

15. Security Considerations

EQR introduces an additional input to authorization systems and therefore creates new downgrade, replay, misbinding, and trust-confusion risks.¶

Authority laundering: A verifier MUST NOT treat a valid signature, reputable issuer, neighboring true statement, or PASS result under one profile as authority for a different proposition, profile, context, or action.¶

Replay: High-consequence deployments SHOULD bind receipts to a short validity interval and, where appropriate, a nonce, transaction, or action digest. Replaying an old PASS receipt after the relevant evidence became stale can cause unsafe authorization.¶

Profile substitution: Both a stable profile identifier and digest are included because a mutable profile URI alone permits semantic substitution. A verifier MUST reject a profile digest that does not match its accepted profile bytes.¶

Evidence reference attacks: Optional evidence retrieval references can create SSRF, access-control, and exfiltration risks. A verifier MUST NOT dereference arbitrary locations solely because they appear in a receipt. Retrieval policy is local.¶

Compromised issuer: Cryptographic integrity cannot make a dishonest or compromised issuer correct. Authorization systems need explicit issuer trust, profile acceptance, and evidence class policy.¶

Denial of service: Evidence graphs and contradiction sets can be large. Profiles should bound input sizes, recursion, remote lookups, and verification cost before evaluation begins.¶

Confused-deputy execution: A PASS EQR that is not bound to the intended proposition or action can be reused to justify a different action. Exact proposition and action bindings are recommended whenever an EQR participates in a high-consequence decision.¶

16. Privacy Considerations

Evidence supporting an agent decision can contain personal, confidential, financial, medical, location, behavioral, or proprietary information. EQR is designed to permit digest-only evidence descriptors so that an authorization path need not copy source data into every token or receipt.¶

Implementations SHOULD minimize the proposition text, evidence metadata, retrieval locations, and correlation identifiers exposed across trust boundaries. Where a proposition itself is sensitive, deployments should exchange a digest or privacy-preserving reference and reveal the plaintext only to components that require it.¶

Long-lived globally unique identifiers can create correlation risk. Deployments should scope receipt and claim identifiers to the smallest useful administrative domain unless cross-domain auditability is a requirement.¶

17. IANA Considerations

This document has no IANA actions. A future revision or companion profile that defines a registered media type, OAuth authorization-details type, token claim, or CBOR label will need corresponding IANA considerations.¶

18. Conclusion

Agent authorization systems need to distinguish the permission to act from the support for the proposition that motivated the action. EQR provides a small transport-neutral object for preserving that distinction. The governing rule is simple: evidence can qualify an authorization premise, but it cannot silently become authorization.¶

Appendix A. Acknowledgements

The author thanks the IETF community authors whose 2026 work on agent authentication, transaction authorization, authorization evidence, evidence challenge semantics, and action provenance helped clarify the specific non-collapse boundary addressed by this draft.¶

Author's Address