OASNT-ENFORCE: Request-Bound Enforcement of Attested Action Authorization
draft-thallapelly-oasnt-enforce-00
This document is an Internet-Draft (I-D).
Anyone may submit an I-D to the IETF.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
| Document | Type | Active Internet-Draft (individual) | |
|---|---|---|---|
| Author | Arun Thallapelly | ||
| Last updated | 2026-08-01 | ||
| RFC stream | (None) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-thallapelly-oasnt-enforce-00
Network Working Group A. Thallapelly
Internet-Draft OmniArx
Intended status: Standards Track 1 August 2026
Expires: 2 February 2027
OASNT-ENFORCE: Request-Bound Enforcement of Attested Action
Authorization
draft-thallapelly-oasnt-enforce-00
Abstract
This document profiles the enforcement of OASNT tokens at the point
of execution. It defines the OASNT-Token HTTP field, the rules by
which an enforcement point derives the observed request from the
octets it will itself forward, a verification procedure for relying
parties that hold no request-to-action mapping, uniform refusal
behavior, and the set of refusals a conforming enforcement point is
required to produce. An enforcement point conforming to this profile
makes a human approval a precondition of execution for the requests
it fronts, without any change to the protected service.
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 2 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
Thallapelly Expires 2 February 2027 [Page 1]
Internet-Draft OASNT-ENFORCE August 2026
and restrictions with respect to this document. Code Components
extracted from this document must include Revised BSD License text as
described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Revised BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Conventions and Definitions . . . . . . . . . . . . . . . . . 3
3. The OASNT-Token Field . . . . . . . . . . . . . . . . . . . . 3
4. Observation . . . . . . . . . . . . . . . . . . . . . . . . . 4
5. Verification . . . . . . . . . . . . . . . . . . . . . . . . 5
5.1. Transport-bound verification . . . . . . . . . . . . . . 5
5.2. Replay scope . . . . . . . . . . . . . . . . . . . . . . 5
6. Refusal Behavior . . . . . . . . . . . . . . . . . . . . . . 6
7. Forwarding . . . . . . . . . . . . . . . . . . . . . . . . . 6
8. Required Refusals . . . . . . . . . . . . . . . . . . . . . . 6
9. Security Considerations . . . . . . . . . . . . . . . . . . . 7
9.1. The boundary of the guarantee . . . . . . . . . . . . . . 7
9.2. Transport-bound verification is not action
verification . . . . . . . . . . . . . . . . . . . . . . 8
9.3. Inherited limits . . . . . . . . . . . . . . . . . . . . 8
9.4. The body cap . . . . . . . . . . . . . . . . . . . . . . 8
9.5. Operator logs . . . . . . . . . . . . . . . . . . . . . . 8
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 8
11.1. Normative References . . . . . . . . . . . . . . . . . . 9
11.2. Informative References . . . . . . . . . . . . . . . . . 9
Appendix A. Implementation Status . . . . . . . . . . . . . . . 9
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 10
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 10
1. Introduction
[I-D.thallapelly-oasnt] (hereafter "the core document") defines a
token in which a hardware-bound device key attests that a specific
human authorized one specific action, optionally bound to one
concrete HTTP request through the rqf claim. The core document also
states where such a token counts: at the party that verifies it
against the request it is about to perform.
This document specifies that party. Without it, the token gates only
a cooperating caller: an agent may obtain a token for one request and
issue another, or issue a request with no token at all, and nothing
positioned at the transport observes the difference. An enforcement
point conforming to this profile closes that gap for every request it
fronts, and does so without modifying the protected service, which
continues to receive ordinary HTTP.
Thallapelly Expires 2 February 2027 [Page 2]
Internet-Draft OASNT-ENFORCE August 2026
The profile deliberately specifies behavior, not placement. A
conforming enforcement point is typically a reverse proxy in front of
an unmodified origin, but the same rules apply to an in-process
interceptor inside the service itself.
This profile is written from a running implementation, whose
adversarial corpus exercises every refusal Section 8 lists.
2. Conventions and Definitions
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.
"The core document" refers to [I-D.thallapelly-oasnt]. The claim
names adg, dsp, rqf, and jti, and the terms "canonical action" and
"request fingerprint", have the meanings the core document gives
them.
*Enforcement point:* the party that verifies a token against the
request it is itself about to perform or forward.
*Presenter:* the party transmitting the request and token to the
enforcement point. The presenter is untrusted.
*Observed request:* the request as the enforcement point will
actually execute it, derived under Section 4. Never anything the
presenter asserts about the request.
*Upstream:* the protected service the enforcement point fronts.
3. The OASNT-Token Field
The token travels in a dedicated HTTP field:
OASNT-Token = b64part "." b64part "." b64part
b64part = 1*base64url-char
base64url-char = ALPHA / DIGIT / "-" / "_"
The value is the compact JWS serialization the core document defines,
unmodified; the segment alphabet is the URL-safe alphabet of
[RFC4648] without padding.
Thallapelly Expires 2 February 2027 [Page 3]
Internet-Draft OASNT-ENFORCE August 2026
A dedicated field is used rather than the Authorization field of
[RFC9110] because the upstream commonly consumes Authorization for
its own credential, and this profile's promise is that the upstream
changes nothing. The enforcement point removes the OASNT-Token field
before forwarding (Section 7), so the two never collide.
A request MUST carry at most one OASNT-Token field with a single
value. A request carrying more than one, or a value that does not
match the syntax above, MUST be refused. A request carrying none
MUST be refused (no-token); there is no anonymous path through an
enforcement point.
4. Observation
The observed request is derived exclusively from what the enforcement
point will itself execute:
* *Method and target:* the method and request target the enforcement
point will use upstream, as octets. These are the same octets it
received, but their authority comes from the enforcement point's
intent to forward them, not from the presenter having sent them.
* *Tenant and privilege:* the orgId and scope inputs to the request
fingerprint are not inferable from HTTP. Configuration MUST bind
them to request targets. A target no configuration entry names
MUST be refused (no-route): a target nobody declared is not an
open path. Misconfiguration is fail-closed by construction,
because a wrong tenant or privilege recomputes to a different
fingerprint and refuses as a mismatch.
* *Body:* the enforcement point MUST buffer the body it will
forward, up to a configured cap, and compute the body digest over
exactly those raw octets. A body exceeding the cap MUST be
refused and MUST NOT be forwarded unverified. There is no
compliant configuration in which oversized requests bypass
verification.
The request fingerprint is then recomputed from these observed values
as the core document specifies. Nothing the presenter declares
participates in the derivation at any point.
Thallapelly Expires 2 February 2027 [Page 4]
Internet-Draft OASNT-ENFORCE August 2026
5. Verification
An enforcement point MUST apply the core document's verification
procedure to the presented token, with the observed request of
Section 4 as the expected request. Because an enforcement point
always authorizes a concrete request, the core document's request-
binding rule applies in full: a token without rqf MUST be refused,
and absence is never a downgrade.
5.1. Transport-bound verification
The core verification procedure recomputes the action and display
digests from the relying party's own representation of the action.
An enforcement point positioned at the transport typically holds no
request-to-action mapping and cannot form that representation. This
profile therefore defines the following modification, and only this
modification:
In place of the action-binding and intent-binding recomputation
steps, an enforcement point that holds no request-to-action mapping
MUST require adg and dsp to be present as non-empty strings covered
by the verified signature. Every other step of the core procedure
applies unchanged.
The result is *transport-bound verification*: the token is proven to
originate from the enrolled key, to be fresh, unconsumed, and bound
to exactly the observed request, while the action and display digests
are carried at signature strength rather than recomputed. A
deployment that requires action recomputation places it at a party
that holds the mapping, such as an executor-side processing model in
the style of [I-D.schrock-action-evidence-boundary] performing
identifier matching under [I-D.thallapelly-oasnt-caid]; matching
there restores recomputation strength to the carried digests. An
enforcement point MUST NOT represent transport-bound verification as
full verification.
5.2. Replay scope
The consumed-jti set is scoped to the enforcement deployment that
maintains it, consistent with the core document's scoping of nonce
consumption. Coordinating consumption across deployments or trust
domains is out of scope here, as it is there.
Thallapelly Expires 2 February 2027 [Page 5]
Internet-Draft OASNT-ENFORCE August 2026
6. Refusal Behavior
On the wire, every refusal MUST be indistinguishable from every
other: the same status code and an identical body, carrying no
indication of which check failed. The distinct refusal cause MUST be
available to the operator, and MUST NOT be available to the
presenter. Refusal causes reveal enrollment state and nonce state,
which is reconnaissance an untrusted presenter is not owed.
A failure of the upstream after an allow decision is an availability
outcome, not an authorization outcome. It MUST be distinguishable
from a refusal (for example, 502 rather than 403) and MUST NOT be
folded into the uniform refusal, because masking availability as
refusal corrupts the operator's signal in both directions.
7. Forwarding
Only a request whose token passed verification in full is forwarded,
and what is forwarded is exactly the observed octets the fingerprint
was computed over: same method, same target, same body. The OASNT-
Token field MUST be removed before forwarding; every other field is
passed through unmodified.
Because the fingerprinted octets and the forwarded octets are the
same buffer, there is no window at this hop between what was verified
and what executes. What the upstream does beyond those octets, such
as dereferencing an identifier the body names, is outside the binding
and belongs to the action layer.
8. Required Refusals
A conforming enforcement point MUST refuse, without forwarding, in
each of the following situations. The labels are descriptive, for
operator logs; nothing on the wire distinguishes them (Section 6).
Thallapelly Expires 2 February 2027 [Page 6]
Internet-Draft OASNT-ENFORCE August 2026
+===================================+================+
| Situation | Label |
+===================================+================+
| body altered relative to the | rqf-mismatch |
| fingerprinted request | |
+-----------------------------------+----------------+
| target altered relative to the | rqf-mismatch |
| fingerprinted request | |
+-----------------------------------+----------------+
| token already consumed by a | replay |
| previously executed request | |
+-----------------------------------+----------------+
| no token presented | no-token |
+-----------------------------------+----------------+
| tenant or privilege configuration | rqf-mismatch |
| disagrees with the binding | |
+-----------------------------------+----------------+
| body exceeding the configured cap | body-too-large |
+-----------------------------------+----------------+
| target named by no configuration | no-route |
| entry | |
+-----------------------------------+----------------+
| more than one OASNT-Token field, | no-token |
| or a syntactically invalid one | |
+-----------------------------------+----------------+
Table 1
The reference implementation exercises each of these against a live
enforcement point over HTTP, together with a check that all refusal
responses are octet-identical on the wire; see Appendix A.
9. Security Considerations
9.1. The boundary of the guarantee
An enforcement point protects exactly the requests that pass through
it. A service reachable around it is not protected, and no property
of this profile survives such a path. Deployments MUST ensure the
upstream accepts requests only from its enforcement point, by network
isolation, mutual authentication, or equivalent means. With that
condition in place, skipping the authorization ceremony is not a
bypass; it is the refused path.
Thallapelly Expires 2 February 2027 [Page 7]
Internet-Draft OASNT-ENFORCE August 2026
9.2. Transport-bound verification is not action verification
Section 5.1 trades action recomputation for deployability at the
transport. The carried adg and dsp are exactly as strong as the
signature over them: they prove what the device signed, not what the
upstream will do. The composition intended by this profile is that
recomputation happens where the mapping lives, at the approval broker
that derives the display from the request, and at the executor that
matches identifiers per [I-D.thallapelly-oasnt-caid]. An enforcement
point is one layer of that composition, not the whole of it.
9.3. Inherited limits
The core document's limits pass through unchanged. A compromised
device may still assert a clean integrity verdict. A valid display
digest proves which octets were shown, not that they were understood.
Nothing in this profile strengthens either claim.
9.4. The body cap
Refusing oversized bodies is the fail-closed arm of a real trade: it
makes the enforcement point a hard dependency for large uploads. The
alternative, forwarding unverified above a threshold, silently
exempts the largest requests from the strongest control, which is the
wrong shape for a security boundary. Deployments with large-body
endpoints SHOULD raise the cap for those targets explicitly rather
than exempt them.
9.5. Operator logs
Refusal causes are operator-only (Section 6) precisely because they
reveal enrollment and nonce state. The log that carries them SHOULD
be protected as security telemetry, and log entries need carry no
token material beyond the cause label.
10. IANA Considerations
IANA is requested to register the following entry in the "Hypertext
Transfer Protocol (HTTP) Field Name Registry" defined by [RFC9110]:
Field name: OASNT-Token
Status: permanent
Reference: this document, Section 3
11. References
Thallapelly Expires 2 February 2027 [Page 8]
Internet-Draft OASNT-ENFORCE August 2026
11.1. Normative References
[I-D.thallapelly-oasnt]
Thallapelly, A., "OASNT: Attested Action Authorization
Tokens", Work in Progress, Internet-Draft, draft-
thallapelly-oasnt-01, 24 July 2026,
<https://datatracker.ietf.org/doc/html/draft-thallapelly-
oasnt-01>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/rfc/rfc2119>.
[RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data
Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006,
<https://www.rfc-editor.org/rfc/rfc4648>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.
[RFC9110] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,
Ed., "HTTP Semantics", STD 97, RFC 9110,
DOI 10.17487/RFC9110, June 2022,
<https://www.rfc-editor.org/rfc/rfc9110>.
11.2. Informative References
[I-D.schrock-action-evidence-boundary]
Schrock, I., "The Action Evidence Boundary for
Consequential Agent Effects", Work in Progress, Internet-
Draft, draft-schrock-action-evidence-boundary-02, 28 July
2026, <https://datatracker.ietf.org/doc/html/draft-
schrock-action-evidence-boundary-02>.
[I-D.thallapelly-oasnt-caid]
Thallapelly, A., "OASNT-CAID: Canonical Action Identifier
Derivation and the Named-Human Binding", Work in Progress,
Internet-Draft, draft-thallapelly-oasnt-caid-00, 24 July
2026, <https://datatracker.ietf.org/doc/html/draft-
thallapelly-oasnt-caid-00>.
Appendix A. Implementation Status
This section records the implementation this profile was written
from; it is not a conformance statement.
Thallapelly Expires 2 February 2027 [Page 9]
Internet-Draft OASNT-ENFORCE August 2026
A reverse-proxy enforcement point and its verification core exist and
run in front of an unmodified HTTP origin. The verification core
delegates every cryptographic decision to the same verifier the core
document's test vectors were generated from. An adversarial corpus
drives a live enforcement point over real HTTP through every
situation Section 8 lists, asserting each is refused, that nothing
refused reaches the upstream, and that all refusal responses are
octet-identical on the wire. The corpus and the list are cross-
checked mechanically, so a refusal cannot be documented without being
exercised or exercised without being documented.
Acknowledgments
The executor-side framing that this profile composes with, in
particular the discussion of admissibility conditions on the WIMSE
mailing list, sharpened the boundary between transport-bound and
action-recomputed verification.
Author's Address
Arun Thallapelly
OmniArx
Email: arun@advitlabs.com
Thallapelly Expires 2 February 2027 [Page 10]