[OAUTH-WG] New Draft: draft-williams-oauth-poi-core-00 (Proof-of-Intent Core)

[Paul Williams <[e-mail]>]

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