Skip to main content

An Authorization Evidence Challenge for High-Risk Agent Actions
draft-schrock-authorization-evidence-challenge-00

Document Type Replaced Internet-Draft (individual)
Expired & archived
Author Iman Schrock
Last updated 2026-07-03
Replaced by draft-schrock-action-evidence-boundary
RFC stream (None)
Intended RFC status (None)
Formats
Additional resources GitHub Repository
Additional Web Page
Stream Stream state (No stream defined)
Consensus boilerplate Unknown
RFC Editor Note (None)
IESG IESG state Replaced by draft-schrock-action-evidence-boundary
Telechat date (None)
Responsible AD (None)
Send notices to (None)

This Internet-Draft is no longer active. A copy of the expired Internet-Draft is available in these formats:

Abstract

The agent-action evidence stack has declaration (a resource declares what evidence its actions require), presentation (an evidence graph of signed artifacts), and decision (deterministic policy replay yielding a closed verdict). Nothing closes the loop: when the verdict is that evidence is missing or stale, no machine-readable message tells the agent what to obtain, how to re-present, or what the retry semantics are — every deployment hand-rolls the dance. This document defines the Authorization Evidence Challenge: the message a relying party returns before a high-risk action executes, naming the exact evidence still required (type, assurance constraints, freshness bound, revocation-check requirement), how to present it, where it might be obtained, and the challenge's own expiry and single-use nonce. The action digest in a challenge is computed by the RELYING PARTY over its own canonical action, so evidence is obtained against the action that will actually execute. The exchange generalizes OAuth step-up authentication (RFC 9470) from authentication to evidence, and completes the circuit: declare, attempt, challenge, obtain, present, replay, consume. A satisfied challenge yields a verdict under the relying party's policy, never a promise to execute.

Authors

Iman Schrock

(Note: The e-mail addresses provided for the authors of this Internet-Draft may no longer be valid.)