An Authorization Evidence Challenge for High-Risk Agent Actions

1.1. Boundary with OAuth Transaction Authorization

When local policy requires a transaction-specific native OAuth grant, an implementation MUST complete the applicable native OAuth flow. It MUST NOT substitute an AE-CHALLENGE, its nonce, or a successfully presented evidence object for that native challenge, its transaction identifier or equivalent correlation value, the authorization-server decision, or the resulting access token. Satisfying AE-CHALLENGE never satisfies a native OAuth grant requirement.¶

AE-CHALLENGE remains applicable outside OAuth and when a relying party needs evidence that a native authorization protocol does not itself negotiate, such as a current status proof, quorum receipt, hardware attestation, or separately verified policy artifact. An OAuth application profile MAY carry or reference both mechanisms, but that profile MUST define their exact action and audience join, which challenge is primary for each refusal, and how native grant state remains separate from AE-CHALLENGE replay state. Without such a profile, the mechanisms are separate and neither is silently converted into the other.¶

The single-use property in this document applies only to one evidence-presentation attempt under an AE-CHALLENGE nonce. It does not consume an OAuth transaction, invalidate an access token, reserve an action, or establish one-time admission at an executor.¶

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

1.3. Terminology

Relying party:

The component that decides whether evidence satisfies its requirements for a proposed action.¶

Presenter:

The agent, gateway, or other component that receives a challenge and may later present evidence.¶

Exact action:

The relying-party-derived material action that would be admitted, including every field its selected action profile treats as consequential.¶

Challenge:

A single-use, expiring description of evidence still required for one exact action.¶

Claim:

The authoritative transition that assigns one challenge nonce to one structurally valid, exact-action presentation attempt. A successful claim consumes the challenge even if later evidence or policy evaluation refuses the action.¶

Consumed challenge:

A challenge whose nonce has been claimed. Consumption does not mean that evidence was sufficient, that the action was authorized, or that any external effect was attempted.¶

2.1. Required Members and JSON Types

A core challenge MUST contain @version, challenge_id, nonce, action_digest, action_profile, audience, policy_id, policy_digest, required_evidence, present_as, and expires_at. The obtain_hints, retry_timing, and critical members are OPTIONAL. A member defined as an array MUST be a JSON array, not a scalar promoted by the recipient.¶

challenge_id and audience are non-empty JSON strings. nonce has the syntax defined in Section 2.2. The binding or profile defines the audience identifier namespace and comparison rule. action_profile and policy_id are absolute-URI strings. action_digest and policy_digest use the case-sensitive form sha256: followed by 64 lowercase hexadecimal digits using SHA-256 as defined by [RFC6234]. The action profile defines the canonical action bytes hashed for action_digest. The relying party defines a deterministic representation of its local policy for policy_digest; the digest identifies the policy state that produced the challenge and does not transfer that policy to the presenter.¶

Each required_evidence element is a JSON object whose required requirement_id and type members are strings. If present, profiles and proof_predicates are non-empty arrays of unique absolute-URI strings, max_age_sec is a non-negative integer, and status is a non-empty string. This document defines current; a recipient refuses any other status value unless an applicable profile defines it.¶

If present, obtain_hints is an array of JSON objects. Each object MUST contain string requirement_id, mechanism, and uri members; mechanism and uri are absolute URIs. If present, retry_timing is a JSON object with the members and types defined in Section 2.5. If present, critical is an array of unique non-empty JSON strings governed by Section 2.7.¶

2.2. Action and Policy Binding

@version MUST equal AE-CHALLENGE-v1. A recipient that does not implement this version MUST refuse automated processing.¶

challenge_id is a non-empty opaque correlation identifier. Authorization decisions MUST NOT depend on its global uniqueness. nonce MUST contain at least 16 random octets generated with a cryptographically secure random source consistent with [RFC4086]. It MUST be encoded as unpadded base64url as defined by Section 5 of [RFC4648], MUST contain 22 through 128 ASCII characters, and is compared as an exact, case-sensitive string. It MUST be single-use within the authenticated issuer's replay domain. The security replay key is the authenticated issuer identity and nonce; challenge_id is not part of that key. A live replay key MUST NOT be overwritten. Reuse of one replay key with a different authenticated body is an integrity or issuer collision failure, not a replay of the exact body.¶

Each binding or profile MUST define the stable authenticated issuer identity used in that replay key. Every alias, front end, and replica that can validate the same issuer-protected challenge MUST map it to the same issuer identity and authoritative replay domain. A presenter-controlled host name, forwarding field, routing hint, or unauthenticated alias MUST NOT select or split that identity.¶

Before exposing a challenge, the relying party MUST either register a durable record that binds the nonce to the complete challenge body, or protect the complete body with an issuer-authenticated, self-describing mechanism defined by the applicable profile. The latter mechanism MUST let the relying party reconstruct and validate the exact body without trusting presenter-supplied fields. A bare challenge body carried only under a transport session is not a self-describing mechanism after that session ends.¶

Each binding or profile MUST define one collision-resistant digest procedure with an output of at least 256 bits for the complete authenticated challenge body. The procedure MUST be domain-separated for AE-CHALLENGE bodies and MUST cover every core and extension member, including unknown members, after duplicate-member rejection. It MAY hash exact encoded bytes only when the binding guarantees those bytes are preserved; otherwise it MUST define a deterministic representation that preserves every data-model distinction accepted by the binding's parser. Stateful registration MUST pin the digest algorithm and canonicalization profile with the registered body; self-describing issuance MUST authenticate the same pins. Returned presentations MUST use those pinned procedures. A transport reserialization, member-order change, non-JSON mapping, or mutable local configuration MUST NOT silently switch digest or canonicalization procedures.¶

The reference HTTP helpers consume already decoded objects. They begin only after the carrier has applied a bounded raw-message parser and duplicate-member detection. Those helpers are not evidence that an ordinary JSON parser supplied by a generic HTTP framework satisfies these requirements.¶

Self-describing issuance can avoid retaining one record for every unanswered challenge. It does not remove single-use state. On the first returned presentation, the relying party still MUST claim the nonce through the compound authoritative transition in Section 2.6 before evidence evaluation.¶

action_digest MUST be computed by the relying party from the exact action it would admit. It MUST NOT be copied from the presenter or from presented evidence. action_profile MUST be present, MUST be an absolute URI as defined by [RFC3986], and identifies the canonicalization or mapping profile used to derive the digest. It is descriptive to the presenter; it does not let the presenter select or weaken that profile. If two parties cannot establish the same material action under an understood profile, the challenge cannot repair the disagreement and the relying party MUST refuse automated admission.¶

The security action binding is the ordered pair (action_profile, action_digest), not the digest alone. Every evidence correlation, continuation, comparison, and downstream admission profile that relies on this challenge MUST authenticate and compare both members. An implementation MUST NOT accept evidence merely because a digest produced under a different action profile has the same octets.¶

The relying party MUST pin the semantics of the selected action_profile for the lifetime of the challenge. It MUST NOT fetch mutable profile content at evaluation time and silently apply different canonicalization or material-field rules under the same profile identifier. A deployment using resolvable profile documents needs an immutable version, authenticated content digest, or equivalent local pin. An action profile that claims exact-action binding MUST include every input whose change can alter authorization, target or resource selection, the provider request, or an externally observable effect. If a profile omits such a material field, it MUST NOT describe its digest as an exact-action binding, and a relying party that requires exact-action binding MUST refuse to use it.¶

audience identifies the component that is expected to answer the challenge. A binding or authenticated envelope MUST let the presenter establish the challenge issuer and its own effective audience. Before following an obtain hint or disclosing evidence, the presenter MUST authenticate the issuer and verify that the effective audience identifies that presenter. On return, the relying party MUST authenticate the presenter and bind that identity to the effective audience before claiming the nonce. A profile that intentionally permits a transferable or anonymous presentation MUST state that exception and define its confidentiality, replay, and denial-of-service consequences. The audience identifier namespace, comparison procedure, alias mapping or mapping version, and resulting stable principal MUST be pinned for the lifetime of the challenge. Stateful registration MUST store those pins with the body; self-describing issuance MUST authenticate them. A mutable directory, configuration change, or alias update MUST NOT reinterpret the same audience string between issuance and return. If the pinned mapping is unavailable or has changed, the relying party MUST refuse the old presentation and MAY issue a fresh challenge under the new mapping when policy permits.¶

policy_id and policy_digest identify the local policy state from which the requirements were derived. They do not transfer policy authority to the presenter. At evaluation time the relying party MUST use its authenticated live policy and MUST NOT use a policy supplied in the response.¶

Delegation, translation, or task rewriting does not preserve one action binding across hops. Each receiving relying party MUST re-evaluate the action it is asked to admit under its own policy and action profile. If that relying party issues a challenge, it MUST derive a new action_digest and register its own challenge binding. A prior hop's challenge or decision record MAY be presented as evidence or context, but it MUST NOT substitute for the receiving relying party's binding to a rewritten action. A chain of per-hop records does not by itself prove that the actions at different hops are semantically equivalent.¶

2.3. Evidence Requirements and Presentation

Each required_evidence entry MUST contain a requirement_id and type. Requirement identifiers are unique within one challenge and correlate requirements with acquisition hints and diagnostics. Every evidence type, evidence profiles entry, and present_as entry MUST be an absolute URI as defined by [RFC3986] so that the same identifier has portable meaning across transport protocols and conformance corpora. Unless the defining specification says otherwise, these identifiers are compared as exact strings. A recipient MUST NOT infer security semantics from URI prefixes or substring matches; it uses only locally configured semantics for the complete identifier.¶

The relying party MUST pin, for the lifetime of the challenge, the security semantics of every evidence type, evidence profiles entry, proof_predicates value, status definition, and present_as profile used by that challenge. A deployment MUST use immutable versioned identifiers, authenticated content digests, or equivalent local version pins. It MUST NOT resolve the same identifier to weaker or otherwise different verification semantics at evaluation time. If any pinned semantic version changes, the relying party MUST refuse the old presentation and issue a fresh challenge under the new pins when policy permits.¶

An entry MAY contain profiles, proof_predicates, max_age_sec, and status. Every entry in required_evidence is a conjunctive requirement: the relying party MUST NOT treat the challenge as satisfied unless every entry is satisfied. Within one entry, profiles are alternatives, so one locally accepted listed profile is sufficient for that dimension. Every listed proof_predicates value is conjunctive and MUST be satisfied. The max_age_sec and status constraints, when present, are also conjunctive with the evidence type, selected profile, and proof predicates. An application profile that needs disjunction across evidence types MUST define a new evidence type or other explicit expression; it MUST NOT reinterpret the core array as disjunctive. max_age_sec is measured at the relying party's evaluation time using the issuance or observation time defined by the selected evidence profile. status equal to current requires a separately authenticated status result satisfying the relying party's freshness policy; it does not mean that absence from an unauthenticated revocation list is sufficient.¶

The evaluation-time source used for max_age_sec, status freshness, and policy replay MUST be selected by the relying party or its authoritative owner. A presenter, verifier worker, request field, or caller-supplied replay timestamp MUST NOT move that time backward or otherwise make stale evidence appear fresh. A binding or profile MUST define the trustworthy time source and the instant at which the evaluation snapshot is taken. An implementation using the owner-side transition in Section 2.6 can use the authoritative transaction time returned by the successful claim as that snapshot.¶

present_as lists alternative presentation profiles. The order expresses the relying party's preference, not a security ranking. Supporting a presentation profile does not imply support for every evidence type named by the challenge. The presenter selects one mutually supported profile and includes enough information for the relying party to match every component to a requirement. Each presentation-profile specification MUST define the response carrier or encoding, how the challenge or an immutable authenticated reference to it is returned, how the selected profile is identified, how presented components map to requirement_id values, how exact-action correlation authenticates both action_profile and action_digest, and either how the returning presenter is authenticated or how an explicitly anonymous or transferable profile satisfies the confidentiality, replay, and denial-of-service rules in this document. This core does not define a generic successful-response envelope.¶

A fresh challenge is evaluated from a complete authenticated evidence presentation under live policy. The core defines no implicit carry-over of evidence, verification results, or ambient verifier state from a consumed challenge. A separate continuation profile MAY omit already satisfied evidence only when the new authenticated challenge binds an immutable predecessor evaluation, the exact evidence and verification semantics relied upon, issuer, presenter or explicit transfer rule, the complete action-binding pair, policy, freshness and status observations, and applicable capacity state. The continuation state MUST participate in replay protection and state bounds. Without such a profile, every follow-up repeats the complete requirement set and the presenter re-presents all required evidence.¶

obtain_hints are untrusted routing hints. Following a hint, authenticating to its URI, or receiving an "approved" response confers no authority at the relying party. Evidence obtained through a hint remains subject to native verification, exact-action matching, freshness and status checks, policy evaluation, and one-time consumption. A presenter MUST NOT send credentials or evidence to a hinted endpoint unless its own policy independently authorizes the endpoint, scheme, redirect behavior, and disclosed material. Each hint requirement_id MUST identify an entry in the same challenge. An issuer MAY omit obtain hints when constructing a challenge. A carrier MUST NOT remove them from an already authenticated challenge body. Multiple hints for one requirement are unordered alternatives unless an application profile defines ordering.¶

Capability discovery MAY advertise evidence types, presentation profiles, or acquisition mechanisms that an implementation supports. Such discovery is not an authorization decision and does not establish that any advertised choice is sufficient for a particular action. The relying party MUST determine sufficiency using its authenticated local policy at evaluation time. A cached discovery response, a mutually supported profile, or a successful acquisition flow MUST NOT waive an unsatisfied local requirement.¶

2.4. Validation and Resource Limits

A JSON recipient MUST reject duplicate member names at every object depth before authenticating, hashing, registering, or evaluating a challenge. A self-describing profile MUST define one deterministic serialization or canonicalization for the complete authenticated body. Parser behavior that silently keeps the first or last duplicate member does not satisfy complete-body binding.¶

required_evidence and present_as MUST be non-empty arrays. Requirement identifiers MUST be non-empty and unique. profiles, proof_predicates, present_as, and critical arrays MUST contain unique values. The nested core objects in required_evidence, obtain_hints, and retry_timing are closed: a recipient MUST reject an unknown member in those objects unless the specification for the enclosing profile explicitly defines that member. max_age_sec and jitter_sec, when present, MUST be integers from 0 through 2147483647 inclusive. A recipient MUST refuse a requirement whose status or proof_predicates semantics it does not understand; it MUST NOT treat an unknown value as satisfied.¶

Every binding and implementation MUST enforce finite limits on the encoded message size, nesting depth, number of requirements and hints, array lengths, and string lengths before expensive cryptographic, native evidence, network-status, or policy work. A profile intended for interoperable deployment SHOULD publish those limits. State caps do not bound parser, canonicalization, signature-verification, or transport costs incurred before the owner-side state transition.¶

2.5. Lifecycle, Replay, and Retry

expires_at MUST be an Internet timestamp as defined by [RFC3339]. The relying party MUST refuse an expired challenge before evidence or policy evaluation. Challenge expiry does not extend the validity of any evidence and evidence expiry does not extend the challenge.¶

Evaluation is ordered: bounded parsing and structure; authenticated issuer and presenter-to-audience binding; validation of the registered or self-describing body; current exact-action agreement; authoritative routing; one atomic expiry-check, nonce-claim, and capacity-reservation transition; native evidence verification; and local policy evaluation. Before that transition, the relying party refuses without claiming a nonce or reserving refusal-path capacity when bounded syntax or structure fails, the issuer or returning presenter cannot be authenticated and bound as required, the challenge cannot be associated with a registered replay key or valid issuer-protected self-describing body, the presentation does not identify an advertised and understood presentation profile, or the current proposed action does not agree with the registered exact action. The relying party MUST rederive the action digest from the current proposed action it is being asked to admit. A stored challenge digest or a digest copied from the presentation is not that rederivation. Once pre-transition validation succeeds, Section 2.6 defines the indivisible owner-side transition that precedes evidence evaluation. For stateful issuance, authoritative equality between the returned body digest and the registered body digest is decided inside that transition. A non-authoritative cache comparison MUST NOT replace or preempt the transition's body-collision result. This comparison does not freeze the action for a later executor admission. An admission protocol using the result MUST independently rederive or fence the final action at its effect boundary; AE-CHALLENGE authorizes no effect.¶

A concurrent duplicate that arrives after another presentation has claimed the nonce, whether that first evaluation is still in flight or has completed, MUST be refused as a replay. It MUST NOT receive a second evidence evaluation, an indeterminate result merely because the first evaluation is in flight, or a second admission. An implementation MAY distinguish in-flight from completed consumption internally for operations and audit, but that distinction does not reopen the challenge. The claim binds the nonce to the registered challenge body, not to a digest of the presented evidence payload. A structurally valid, exact-action presentation therefore spends the one presentation attempt even when later evidence evaluation refuses it or the response is lost. The presenter starts a new interaction to obtain a fresh challenge; it does not replay the consumed nonce.¶

Every verifier instance that accepts presentations for one challenge issuer MUST use the same authoritative replay domain, or a deterministic partition in which exactly one authoritative shard owns each issuer-and-nonce replay key. A process-local cache or eventually consistent replica does not satisfy atomic nonce claim. If the authoritative replay domain is unavailable or its result is uncertain, the relying party MUST refuse without evidence evaluation or admission; it MUST NOT fall back to fresh local state.¶

A profile using deterministic partitioning MUST define how the authoritative owner is derived from issuer-protected challenge state. A presenter-controlled routing value outside the authenticated challenge body or authenticated issuer context MUST NOT select the owner. A front end or non-owning shard MUST route the claim to the owner before classifying the nonce. Only an authoritative owner result that the exact registered body was already claimed is a replay result. Failure, timeout, partition, or an uncertain result while reaching the owner is temporary unavailability, not replay, and MUST NOT be reported as an already-claimed nonce.¶

If evidence remains missing, stale, or unverifiable, the relying party MAY issue a follow-up challenge. Before doing so, it MUST rederive the current proposed action under its pinned action profile. If that digest no longer equals the consumed challenge digest, it MUST NOT issue a follow-up for the old action. A valid follow-up MUST use a fresh challenge identifier and nonce, MUST remain bound to the same locally rederived action digest and action profile, and MUST derive its requirements and policy identifiers from authenticated live policy. It MUST list the complete requirement set unless a continuation profile satisfying Section 2.3 is explicitly in use. It is a new refusal with new authoritative state, never an implicit continuation of the consumed nonce or ambient prior evidence.¶

An implementation that automatically issues follow-up challenges or restarts a challenge after a claimed presentation MUST enforce a finite reissue budget bound at least to the authenticated issuer, effective presenter or audience, action profile and digest, and policy. The budget applies to automatic follow-up issuance caused by a claimed presentation. An initial challenge, including a later initial challenge authorized through a separate out-of-band recovery decision, is not a reissue merely because it has the same action digest. Capacity policy therefore distinguishes initial issuance, presentation claim, and follow-up issuance. An implementation MUST NOT relabel an automatic follow-up as initial issuance to bypass an exhausted budget; a later initial challenge requires a separate authenticated policy or recovery decision.¶

A fresh challenge identifier or nonce does not reset the automatic reissue budget. A follow-up charged to that budget remains charged if it later expires without a presentation; removing its expired nonce record does not refund the reissue unit. When the budget is exhausted, the relying party MUST stop automatic reissue and use a generic refusal or a separately authorized out-of-band recovery path. Exhaustion ends the automatic recovery chain; it does not permanently prohibit a new initial authorization decision for the action. A deployment MAY begin a new budget generation only through authenticated owner-side policy or a separately authorized recovery operation. Presenter-controlled fields, including a fresh nonce, MUST NOT select that generation. The relying party MUST NOT reopen or reuse a consumed nonce.¶

retry_timing is OPTIONAL. When present, it MUST contain a not_before Internet timestamp as defined by [RFC3339] and MAY contain a non-negative integer jitter_sec. not_before MUST precede expires_at, and adding jitter_sec to not_before MUST still produce an instant before expires_at. A presenter that processes this member MUST NOT send the challenge response before not_before. When jitter_sec is greater than zero, the presenter SHOULD add an independently selected delay between zero and that many seconds. The selected delay SHOULD vary for each challenge and MUST NOT be treated as extending expires_at. The not_before value is only the earliest time to present corrected evidence. It is not a promise of capacity, evidence sufficiency, admission, or execution. After waiting, the presenter can receive the same refusal, a different refusal, or an overload response.¶

A relying party that expects many correlated refusals SHOULD issue recipient-specific or challenge-specific retry schedules rather than one common retry instant. It SHOULD provide a jitter interval wide enough for its expected population and recovery capacity. A presenter remains responsible for its own backoff and rate limits when timing is absent. A challenge MUST NOT be issued solely to signal overload when the carrying protocol has a distinct overload response. If evidence insufficiency and load pressure coexist, retry timing can pace the new evidence presentation without changing the refusal semantics. The presenter can therefore spend effort acquiring third-party evidence and still be refused or shed after the lower bound; timing guidance does not assert which constraint will be decisive later.¶

Ignoring retry_timing does not make evidence sufficient or authorize an action, but it can defeat the issuer's load-control goal. It does not change the semantic meaning of the challenge and therefore MUST NOT appear in critical. An issuer that relies on enforced pacing MUST enforce it through carrier-level overload handling, admission control, rate limiting, or refusal; it MUST NOT rely on retry_timing as an enforcement control. A presenter that cannot establish whether not_before has passed MUST NOT infer permission to send early; it uses its local backoff policy or declines automated retry.¶

Expiry is tested as part of the owner-side claim transition. A presentation claimed before expiry MAY finish evaluation after that instant, but challenge expiry never extends evidence validity or permits admission under stale policy. Implementations MUST place a finite deadline on native verification and finalization. Reclaiming an abandoned reservation requires an ownership fence that prevents the old worker from later committing a follow-up or other refusal-path state.¶

Unknown acquisition status, timeout, transport failure, or an unverifiable response is indeterminate. It MUST NOT be interpreted as evidence satisfaction or permission to retry an action whose effect may already have occurred.¶

2.6. State Bounds and Exhaustion

A relying party MUST configure a finite aggregate upper bound on challenge state retained in one authoritative replay domain. The bound MUST account for outstanding stateful challenges and in-flight or consumed replay records. Where a presenter is authenticated before challenge issuance, the relying party SHOULD also apply per-presenter and per-audience bounds. Multi-tenant deployments SHOULD apply an administrative bound per tenant so one tenant cannot consume the aggregate allowance.¶

Admission control for a stateful challenge MUST occur before the challenge is exposed. The cap check, insertion of the issuer-and-nonce replay key and complete authenticated body binding, and debit across every applicable outstanding-state bucket MUST commit as one atomic issuance transition in the same coordination domain. A read-check- register sequence or registration followed by a separate capacity debit does not satisfy this requirement. If the relying party cannot complete that transition or allocate the required outstanding record, it MUST NOT issue or expose the challenge. It returns a carrier-appropriate overload or generic refusal without an authorization-evidence challenge.¶

For self-describing issuance, the relying party MUST enforce the replay-state bound when the first returned presentation attempts to claim the nonce. If it cannot durably and atomically claim replay state, it MUST refuse without native evidence verification, policy evaluation, or admission. It MUST NOT issue a replacement stateful challenge on that path. Self-describing issuance reduces unanswered outstanding state; it does not make replay processing stateless.¶

A relying party that knows its authoritative replay-state bound is currently exhausted MUST NOT issue a self-describing challenge whose return cannot be claimed. It uses the carrier's overload or generic refusal path until capacity is available.¶

An implementation MUST NOT evict a live in-flight or consumed nonce record to admit a newer challenge. Such a record MUST remain in the authoritative replay domain until the later of expires_at and completion of the in-flight evaluation. Expired unconsumed records MAY be removed. Removing an expired unconsumed initial challenge can release its ordinary outstanding-state capacity because initial issuance does not consume the automatic follow-up budget. Removing an expired follow-up challenge MUST NOT refund the automatic reissue unit charged to its recovery chain. A deployment that wants to return the protocol's expired result during a late-arrival horizon MUST retain an authenticated minimal tombstone binding the replay key, body digest, and expiry for that horizon. If a stateful record is removed without such a tombstone, a later presentation receives a generic unknown- challenge refusal; it MUST NOT be authenticated or classified as expired from presenter-supplied fields. Longer retention for audit or abuse detection is a deployment choice.¶

Challenge lifetimes SHOULD be no longer than the expected evidence- acquisition workflow requires. Rate limiting, authentication where available, self-describing issuance, and short lifetimes can reduce state pressure, but none permits fail-open nonce handling.¶

Before allocating challenge state or routing work to an authoritative owner, an implementation MUST apply a separate finite anti-abuse budget appropriate to the authenticated requester, source, tenant, or deployment. That budget covers parsing, authentication, owner routing, initial native evidence or policy evaluation used to decide whether a challenge is needed, and issuance work that the replay-state cap cannot protect. If the implementation already knows that its replay-state bound is exhausted, it MUST take the generic refusal or overload path before starting such native evidence or policy work. Exhausting the separate budget produces a generic refusal, rate-limit response, or temporary-overload response without a challenge body.¶

For a returned presentation, the authoritative owner MUST perform nonce claim and refusal-path capacity reservation as one indivisible transition. Its security inputs are the authenticated issuer identity, nonce, exact authenticated body digest, current time, every applicable aggregate, per-presenter, per-audience, and per-tenant cap bucket, and the maximum refusal-path state the evaluation can create. The authoritative owner's current time and the challenge expiry are also inputs, so an expiry check cannot race a later claim. A read-only front end, presenter, or verifier-worker timestamp MUST NOT determine this expiry result; current time MUST come from the same authoritative transaction that claims the nonce and changes capacity. A read-only capacity check, a reservation followed by a separate nonce claim, or a nonce claim followed by a separate capacity debit does not satisfy this requirement.¶

The transition has the following mutually exclusive results and total ordering. First, a retained claimed record produces exact-body-replay or body-collision. Second, when no claimed record exists, expiry produces expired for a retained open record, retained authenticated expiry tombstone, or valid self- describing body. Third, an unexpired open record with a different body produces body-collision. Fourth, capacity is checked. A successful unexpired exact claim then produces claimed-with-capacity. Failure or uncertainty while completing this ordering produces unavailable. This ordering preserves replay classification for a duplicate arriving after expiry while the first claimed evaluation is still in flight.¶

• claimed-with-capacity: a statefully registered exact body was open, or a valid self-describing exact body had no replay record, and sufficient capacity existed. The nonce claim and the reservation or debit across every applicable cap bucket commit together.¶
• exact-body-replay: the authenticated issuer-and-nonce key was already in claimed state for the same body digest. No new capacity is reserved or debited.¶
• body-collision: the same retained claimed replay key, or an unexpired open replay key, exists for a different body digest. The request is refused as an integrity or issuer collision failure, never as successful replay classification, and no new capacity is reserved or debited.¶
• capacity-refused: one or more applicable cap buckets lack capacity. No nonce is claimed and no partial debit remains.¶
• expired: authoritative owner time is at or after expires_at. No nonce is claimed and no capacity is reserved or debited.¶
• unavailable: the owner cannot complete the transition or the outcome is uncertain. The caller reports temporary unavailability and MUST NOT infer whether authoritative state changed.¶

For a statefully issued challenge, an existing outstanding-state debit MUST be transferred into the in-flight reservation in the same transaction. Only the positive incremental delta between that debit and the conservative in-flight reservation is added to each applicable cap bucket. The existing debit MUST NOT be lost, counted twice, or released before replacement state is secured. The issuance transition MUST pin the authenticated identities, bucket keys, and bucket limits that produced that debit. Claim and finalization MUST lock and preserve those stored buckets; they MUST NOT recompute and replace them from a mutable audience alias, directory result, or caller context. Newly applicable buckets, such as an authenticated presenter bucket first available on return, are added to the pinned issuance vector in the same transition. For self-describing issuance, the transition creates the first replay record and reservation together. The reservation covers the maximum additional state, including a follow-up challenge where supported. Finalization atomically commits the actual resulting state and releases only unused capacity. A worker crash or uncertain finalization retains the conservative reservation unless a fenced recovery transition proves that the old worker can no longer publish state.¶

Every cap bucket changed by the transition MUST be in the same atomic coordination domain as the replay claim. A sharded deployment MAY use preallocated owner quotas only when the sum of live quotas cannot exceed the global cap and quota transfer itself is safe under failure. Two shards independently reading a global counter do not satisfy this rule. If an applicable cap cannot participate atomically or through a safe preallocated quota, the result is unavailability. Capacity uncertainty fails closed.¶

When a hard cap is binding for an unclaimed exact body, capacity handling controls the response even if the supplied evidence is also missing, stale, or unverifiable. The relying party MUST NOT perform native evidence verification or local policy evaluation, and MUST NOT return a follow-up challenge, a stateless list of remaining requirements, obtain hints, or any other evidence-sufficiency detail. Withholding and coalescing those details reduces the value of exhaustion handling as a policy-discovery oracle; it does not eliminate timing or traffic-analysis signals. Detailed diagnostics are limited to authenticated and locally authorized operational channels. An authoritative exact-body-replay result can be returned without a capacity debit; it does not invoke evidence or policy evaluation.¶

2.7. Extensibility

The critical array names top-level members of the core challenge only; it does not name nested members or JSON Pointer paths. Recipients MUST ignore an unknown top-level challenge member unless its name appears in critical. A recipient that does not understand every member named by critical MUST refuse automated processing. Every name in critical MUST identify a member actually present in the same challenge, and core members MUST NOT be named there. A specification defining an extension MUST state whether that extension is safe to ignore and how it is bound to the registered challenge body. The core retry_timing member is safe to ignore for challenge semantics and MUST NOT be named by critical. Unknown outer Problem Details members are not core challenge members and follow the processing rules of [RFC9457].¶

2.8. Carrier Semantics

A transport binding SHOULD carry a challenge as a structured refusal or error payload when the carrying protocol provides such a facility. A binding that uses a message part, task-state extension, or other carrier MUST preserve the same refusal semantics and scope the challenge to the identified attempt. It MUST NOT represent the challenge as a successful task result, output artifact, authorization, or durable state that silently applies to later attempts. These rules constrain carrier semantics without requiring every transport to use the same envelope.¶

3.1. OAuth Non-Substitution Conformance Case

A protected resource requires a transaction-specific OAuth grant. The presenter supplies a valid AE-CHALLENGE response but no native transaction-bound access token. The protected resource MUST refuse the action. It MUST NOT treat the AE challenge identifier or nonce as the OAuth transaction identifier, and it MUST NOT report the evidence presentation as satisfying the native grant requirement. The case passes only when the protected resource continues the native OAuth flow or refuses.¶

4.1. Illustrative Gateway Case

Gateway A forwards a proposed action to Gateway B. Gateway B derives the exact action under its pinned action profile and refuses because a current approval artifact is missing. B returns an AE-CHALLENGE bound to B's action digest and local evidence requirement. A obtains and presents the artifact. B verifies it under B's trust anchors, matches it to the same action, and reevaluates B's policy. The case passes only if A never treats the challenge as authorization and B refuses an action-digest mismatch, stale status, replayed nonce, or unsupported presentation profile. This is an illustration, not a DMSC conformance requirement.¶

A second case attempts concurrent admission of one single-use right at both gateways. AE-CHALLENGE alone does not pass that case. The case would pass only when a separate conserved-admission mechanism establishes exclusivity, or when the receiving gateway refuses or returns indeterminate because exclusivity cannot be established.¶