An Authorization Evidence Challenge for High-Risk Agent Actions

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

Table of Contents

1. Introduction

Evidence formats describe artifacts such as receipts, permits, attestations, and logs. They do not by themselves define the live interaction that follows when a relying party finds the presented evidence insufficient. Without a common challenge, each agent protocol invents its own vocabulary for missing evidence, acceptable presentations, freshness, status checking, and retry.¶

This document defines the challenge as an application data model, independent of HTTP, a particular agent protocol, and any one evidence format. The nearest prior art is OAuth step-up authentication [RFC9470], which lets a resource identify stronger authentication requirements. AE-CHALLENGE applies the interaction shape to authorization evidence about an exact proposed action.¶

A challenge is a refusal with information. It is not an authorization decision, reservation, capability, ownership transfer, or promise of execution. Satisfying it causes the relying party to evaluate a new presentation under its live local policy.¶

2. Transport-Neutral Core Data Model

The AE-CHALLENGE-v1 data model is independent of its carrier. A transport binding MUST preserve every member that the relying party uses when registering and later consuming the challenge. A binding MUST also provide authenticated integrity and peer identification, or carry the challenge in an authenticated envelope that provides those properties.¶

The JSON format defined by [RFC8259] is the reference serialization of the core model. A non-JSON binding MUST define an unambiguous mapping to the same members and value types.¶

{
  "@version": "AE-CHALLENGE-v1",
  "challenge_id": "7a3120d1-...",
  "nonce": "<single-use unpredictable value>",
  "action_digest": "sha256:<relying-party-derived digest>",
  "action_profile": "https://example.net/action/payment-v3",
  "audience": "https://gateway-b.example",
  "policy_id": "https://gateway-b.example/policies/high-risk-v4",
  "policy_digest": "sha256:<relying-party policy digest>",
  "required_evidence": [
    {
      "requirement_id": "human-approval",
      "type": "https://example.net/e/authorization-receipt",
      "profiles": ["https://example.net/profiles/receipt-v1"],
      "max_age_sec": 300,
      "status": "current"
    }
  ],
  "present_as": ["https://example.net/p/ep-aec-v1"],
  "obtain_hints": [
    {
      "requirement_id": "human-approval",
      "mechanism": "https://example.net/flows/approval-v1",
      "uri": "https://approver.example/tasks/123"
    }
  ],
  "retry_timing": {
    "not_before": "2026-08-09T23:50:30Z",
    "jitter_sec": 20
  },
  "expires_at": "2026-08-10T00:05:00Z"
}

3. HTTP Binding

An HTTP origin server that refuses an action because authorization evidence is missing, stale, or unverifiable SHOULD return 403 Forbidden as defined by [RFC9110]. The response body MUST be an application/problem+json Problem Details object as defined by [RFC9457]. Status 428 is not used: it is defined for requests that the origin server requires to be conditional, not for authorization-evidence negotiation.¶

If temporary overload is the sole reason for refusal, the origin server MUST NOT fabricate an authorization-evidence challenge. It uses 503 Service Unavailable, or another response appropriate to the actual failure, and MAY use Retry-After as defined by [RFC9110]. A 403 AE-CHALLENGE is appropriate when evidence is actually insufficient, including when load pressure also makes pacing the corrected presentation necessary.¶

HTTP/1.1 403 Forbidden
Content-Type: application/problem+json
Cache-Control: no-store
Date: Sun, 09 Aug 2026 23:50:00 GMT
Retry-After: 30

{
"type":"https://iana.org/assignments/http-problem-types#ae-required",
  "title": "Authorization Evidence Required",
  "status": 403,
  "detail": "Required evidence is unavailable.",
  "evidence_challenge": {
    "@version": "AE-CHALLENGE-v1",
    "challenge_id": "7a3120d1-...",
    "nonce": "...",
    "action_digest": "sha256:...",
    "action_profile": "https://example.net/action/payment-v3",
    "audience": "https://agent.example",
    "policy_id": "https://resource.example/policies/high-risk-v4",
    "policy_digest": "sha256:...",
    "required_evidence": [
      { "requirement_id": "human-approval",
        "type": "https://example.net/e/authorization-receipt",
        "max_age_sec": 300,
        "status": "current" }
    ],
    "present_as": ["https://example.net/p/ep-aec-v1"],
    "obtain_hints": [],
    "retry_timing": {
      "not_before": "2026-08-09T23:50:30Z",
      "jitter_sec": 20
    },
    "expires_at": "2026-08-10T00:05:00Z"
  }
}

The Problem Details type and title MUST have the values shown above. The HTTP status code and the optional status member MUST both be 403. The core challenge MUST appear in the evidence_challenge extension member. Human-readable detail text is advisory and MUST NOT be parsed for protocol semantics.¶

The origin server MUST send Cache-Control: no-store. A generic intermediary can still transform an HTTP response, so a client MUST validate the Problem Details object and the authenticated origin before acting on hints or presenting evidence.¶

When the core challenge contains retry_timing, the origin server SHOULD send a Retry-After field as defined by [RFC9110]. Its HTTP-date or delay-seconds value MUST NOT permit a follow-up request earlier than not_before. If the header and core member identify different lower bounds, a client MUST use the later bound and then apply jitter_sec. Retry-After does not carry the jitter value and does not change the challenge expiry, authorize the action, or make a retry safe after an uncertain effect.¶

4. Informative DMSC Gateway Profile

Agent gateways can carry the transport-neutral challenge during federation or handoff. The receiving gateway is the relying party: it derives the exact action, applies its own trust anchors and policy, and issues a challenge when evidence is missing, stale, or unverifiable. The sending gateway or agent can obtain evidence and return a new presentation using a DMSC-defined extension point or error carrier.¶

If a gateway rewrites or translates the proposed action, the next gateway re-evaluates that locally derived action and, when necessary, issues its own binding. The prior gateway's action digest does not survive the rewrite as the receiving gateway's binding. Any claim that the two actions are equivalent requires a separately defined mapping or transformation proof.¶

When a receiving gateway refuses an action because required authorization evidence is missing, stale, or unverifiable, it may return a structured evidence challenge identifying the exact action, outstanding evidence requirements, applicable freshness or status constraints, and supported presentation profiles. The challenge does not authorize the action or transfer admission ownership; conserved admission across gateway boundaries remains the separate requirement described in Section 7.8 of the proposed next revision of [DMSC-GAPS].¶

In particular, AE-CHALLENGE does not prevent Gateway A and Gateway B from admitting the same single-use right. It does not copy, fence, or relinquish consumption state and does not establish which gateway owns admission during a partition. The separate handoff property is not a race to decide which gateway admitted first; it is an invariant that committed capacity is not over-allocated under any interleaving of admissions and releases. A DMSC handoff profile MUST solve that property separately. If the receiving gateway cannot establish the required exclusivity, its safe result is refusal or indeterminate, not acceptance based on the challenge.¶

5. Security Considerations

Challenge forgery and evidence exfiltration. A forged challenge cannot authorize an action, but it can redirect a presenter, induce unnecessary approval work, or solicit sensitive evidence. Presenters MUST authenticate the relying party and audience before following obtain hints or disclosing evidence. A bare JSON object copied outside its authenticated carrier has no origin authenticity.¶

Action substitution. The relying party computes the challenge action digest from the action it would execute and recomputes that binding before admission. A digest supplied by the presenter or an action profile selected by the presenter defeats the purpose of the protocol.¶

Replay and denial of service. Durable body-bound nonce registration is required before challenge exposure. Consumption before evidence evaluation prevents concurrent replays, but an attacker who can submit a structurally valid response can consume a challenge. Deployments therefore need authenticated presenters, rate limits, short expiries, and a cheap path to issue a replacement challenge.¶

Retry synchronization and load amplification. A precise challenge tells a presenter how to correct a request, so a population receiving similar refusals can retry in a synchronized burst. An issuer under pressure SHOULD combine recipient-specific retry timing, a non-zero jitter interval, admission control, and rate limiting. A presenter SHOULD retain exponential backoff or equivalent local load control even when a challenge supplies a lower bound. Timing guidance paces only a new evidence presentation and MUST NOT be interpreted as evidence satisfaction or authorization.¶

Information disclosure. Evidence requirements, policy identifiers, action profiles, and obtain hints can reveal sensitive policy structure. A relying party SHOULD disclose only the minimum information needed for remediation. The HTTP binding requires Cache-Control: no-store.¶

Stale facts and uncertain effects. A satisfied challenge proves only that the relying party's evidence requirement was met at evaluation time. It does not prove that external facts remain true, that an action executed, or that an uncertain action is safe to retry. Status rechecking, execution custody, effect observation, and reconciliation remain separate controls.¶

Gateway split brain. An authenticated challenge from a receiving gateway does not transfer a single-use authorization or its consumption ledger. Implementations MUST NOT claim cross-gateway double-admission prevention merely because both gateways implement this challenge.¶

6. IANA Considerations

IANA is requested to add the following entry to the "HTTP Problem Types" registry established by [RFC9457]. That registry uses the Specification Required policy defined by [RFC8126]; this request does not require IETF Review or Standards Action.¶

Type URI:

https://iana.org/assignments/http-problem-types#ae-required¶

Title:

Authorization Evidence Required¶

Recommended HTTP status code:

403¶

Reference:

This document.¶

This revision withdraws the earlier request for a new application/authorization-evidence-challenge+json media type. The HTTP binding reuses the registered application/problem+json media type. Non-HTTP bindings define their own carriage without changing the core data model.¶

7. Interoperability Questions for Review

This revision resolves the transport layering, HTTP status and media type, gateway-ownership boundary, acquisition-protocol coupling, retry synchronization, and per-hop binding questions raised through revision -03. Review is requested on the following remaining choices:¶

• Which Agent2Agent and AgentProto error carriers can preserve the complete challenge, authenticated issuer, audience, and retry timing, and whether either protocol needs an additional attempt identifier.¶
• Whether a DMSC gateway profile should carry the core object directly or reference it by an authenticated, digest-bound URI.¶

8. Acknowledgments

Thanks to Sumit P. Ahuja for identifying synchronized retry and load amplification as a consequence of precise challenge guidance, and for suggesting retry timing and jitter. Thanks to Guigui Wang for implementation feedback on structured error payloads, per-hop action rebinding, and the separation of capability discovery from local authority. Thanks to Henri Sirkkavaara for review of replay ordering, concurrent-presentation behavior, diagnostic ordering, and portable identifier semantics.¶

9. Changes since -03

• Adds optional transport-neutral retry timing with an absolute lower bound and independently selected per-challenge jitter.¶
• Maps the lower bound to HTTP Retry-After while retaining jitter in the core challenge.¶
• Defines retry synchronization and load amplification as a denial of service concern without making a challenge an overload response.¶
• Recommends structured refusal or error payloads while preserving transport-neutral carrier semantics.¶
• Requires each delegation or rewriting hop to re-evaluate its local action and issue its own binding.¶
• Separates capability discovery from authority and local evidence sufficiency.¶
• Requires portable absolute-URI identifiers for evidence types, action profiles, and presentation profiles.¶
• Checks action agreement before expiry and nonce consumption, and defines a concurrent duplicate during evidence evaluation as a replay that cannot trigger a second evaluation or admission.¶
• States conserved admission as a committed-capacity invariant over every admission and release interleaving while leaving that mechanism outside AE-CHALLENGE.¶

Appendix A. Relationship to Existing Mechanisms

CAID [CAID] is one mechanism for deriving and mapping exact material actions. AEB [AEB] defines executor-side evidence verification, refusal, and one-time consumption. Bounded Capability Receipts [BCR] define durable single-domain reservation and consumption. AEC [AEC] is one possible presentation profile. None is required by the core challenge, and the challenge does not extend any of them across independently operated admission domains.¶

Appendix B. Implementation Status

The EMILIA Protocol repository contains a same-team reference implementation of the AE-CHALLENGE-v1 core lifecycle, including relying-party-derived action binding, policy-derived requirements, durable body-bound registration, single-use consumption, expiry, follow-up challenges, and action-swap refusal. Revision -03 added a serializer and parser for the RFC 9457 HTTP binding and tests that pin status 403, application/problem+json, Cache-Control: no-store, and the evidence_challenge extension.¶

Revision -04 specifies retry timing, per-hop rebinding, discovery separation, carrier semantics, portable absolute-URI identifiers, and action-before-consumption replay ordering. These additions are based in part on external implementer review, including experience with structured error payloads and per-verifier decision bindings. They are not yet implemented by the same-team reference implementation and are not claimed as an independent implementation of this specification.¶

This is same-team implementation evidence. No independent implementation or interoperability is claimed. The implementation does not yet provide a DMSC carrier or conserved-admission mechanism. Its current local evidence and presentation identifiers are not the absolute URIs required by this revision.¶

Author's Address