Hi OAuth WG, I have submitted a new individual Internet-Draft, draft-williams-oauth-poi-core-00: https://datatracker.ietf.org/doc/draft-williams-oauth-poi-core/
A companion extension covering multi-hop escalations and concurrency is also available: https://datatracker.ietf.org/doc/draft-williams-oauth-poi-chained-state/ Motivation and Common Ground with AAuth The recent discussion around draft-rosenberg-oauth-aauth highlights a consensus in the working group: 1. AI agents cannot be trusted with broad, ambient access tokens. 2. AI agents cannot be trusted to author their own approval justifications (under prompt injection or hallucination, an agent can misrepresent its actions to the human). 3. The Resource Server (RS) must generate the human-readable explanation and sign it inside a challenge, as only the RS understands the operational semantics of the request. I strongly agree with these premises. Where Proof-of-Intent (PoI) diverges from AAuth is on the operational mechanics: specifically, whether human approval should result in an elevated bearer token issued via an Authorization Server (AS) round-trip, or an atomic, stateless cryptographic attestation delivered directly to the Resource Server. The Architectural Contrast with AAuth 1. Atomic Transaction Attestation vs. Ambient Scope Elevation In AAuth, user approval results in the AS issuing an access token with broader scope (e.g., 'reservations.write'). Once granted, the agent holds a time-bounded ambient capability that could be reused for other unreviewed operations until expiry. PoI Core does not elevate the agent's access token. Instead, the human signs an atomic Proof-of-Intent Envelope (PoIE) committing to the exact canonical SHA-256 hash of the transaction parameters (RFC 8785 JCS). The RS verifies the signature and executes only that specific action. 2. Eliminating the "AS Round-Trip Tax" AAuth models human approval through the AS (using HTTP polling, SSE streams, or WebSockets to wait for token delivery). PoI Core completely removes the AS from the live transaction path. During initial session login, the client generates a short-lived Ephemeral Intent Key (EIK) certified by the AS via RFC 7800 'cnf' claims. When the RS challenges an action, the client signs the challenge locally and returns it directly to the RS. Runtime verification is entirely stateless at the RS. 3. In-Situ Signing Vault vs. Out-of-Band Redirects AAuth relies on out-of-band mobile push notifications or instructs the agent to launch a browser to the AS's user approval endpoint. PoI Core defines a client-side Signing Vault (e.g., an isolated iframe or secure enclave) embedded in the agent application. The vault validates the RS's signed display facts and presents the approval prompt directly in the user's primary workflow. 4. Hardware-Backed Step-Up Assurance PoI Core integrates W3C WebAuthn Level 3 directly into the challenge semantics. The RS dynamically dictates the required assurance tier based on consequence: Tier 1 (session key PoP), Tier 2 (platform biometrics like TouchID/Windows Hello), or Tier 3 (FIDO2 cross-platform hardware tokens). 5. Alignment with Established Stateless Prior Art Rather than inventing new stateful queuing patterns, PoI builds on battle-tested prior art: - FAPI / PSD2 Dynamic Linking (RTS Article 5): Applying "What You See Is What You Sign" directly to agent parameter payloads. - DPoP (RFC 9449) & RFC 7800: Lifting proof-of-possession key confirmation from HTTP transport to application transaction intent. - WebAuthn: Validating that client-held keys and local challenge-response scale without an IdP in the critical path of every operation. Running Code & Implementation Status In the spirit of "rough consensus and running code", an open-source reference implementation of the PoI challenge-handling, key rotation, and verification pipeline is available in the Mandrel Collet repository: https://gitlab.com/the-mandrel-project/mandrel-collet https://gitlab.com/the-mandrel-project/mandrel-demo/-/tree/main/scripts I see PoI Core as a high-performance, stateless complement to the ongoing agentic authorization discussions in OAuth. I welcome feedback from the list on the cryptographic bindings and operational trade-offs, and I would be glad to request agenda time to present a brief comparison at an upcoming interim or meeting. Regards, Paul Charles Williams Barefoot Coders, LLC https://mandrelproject.ai
_______________________________________________ OAuth mailing list -- [email protected] To unsubscribe send an email to [email protected]
