Enforcement-Action HTTP Header Field
draft-secroot-ooda-http-04
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 | Rachid Bouziane | ||
| Last updated | 2026-07-03 | ||
| 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-secroot-ooda-http-04
Internet-Draft R. Bouziane
Intended status: Standards Track SecRoot.io
Expires: 4 January 2027 3 July 2026
Enforcement-Action HTTP Header Field
draft-secroot-ooda-http-04
Abstract
This document defines the Enforcement-Action HTTP response header
field. The field carries an advisory selected-action token from
an application to cooperating intermediaries within a trusted
boundary. It is advisory and safe to ignore. Recipients apply
their local policy in response to the signal. This specification
standardizes the field name, syntax, response-path processing
model, and safe-to-ignore behavior. It does not standardize the
operational meaning, target, duration, or enforcement effect of
individual action tokens or parameters, and it does not modify
HTTP semantics, TLS, QUIC, or the caching rules of [RFC9111].
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 4 January 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 and restrictions with
respect to this document.
Table of Contents
1. Introduction
1.1. Problem Statement
1.2. Decision Layer and Coordination Mechanism
1.3. Relationship to Existing HTTP Mechanisms
1.4. Measurement Motivation
1.5. Document Structure
2. Terminology
3. The Enforcement-Action Header Field
3.1. Field Definition
3.2. Field Syntax
3.3. Field Parameters
4. Processing Model
4.1. Sender Behavior
4.2. Intermediary Behavior
4.3. Recipient Behavior
4.4. Safe-to-Ignore Guarantee
5. Security Considerations
5.1. Advisory Semantics
5.2. Trust Boundaries
5.3. Injection Protection
5.4. Information Exposure
5.5. Caching Considerations
5.6. No Transport Modification
6. IANA Considerations
7. Implementation Status
7.1. SecRoot.io Reference Enforcement Implementation
7.2. Three-Hop Observability Prototype
8. References
8.1. Normative References
8.2. Informative References
Appendix A. Deployment Example (Informative)
Appendix B. Revision History (Informative)
Acknowledgements
1. Introduction
Distributed HTTP deployments separate the component that makes
enforcement decisions from the components that enforce them.
An application that identifies an anomalous request may determine
that the client should be throttled, challenged, or blocked.
That determination exists at the application layer. But the
intermediaries that sit between the application and the client
-- CDN edge nodes, reverse proxies, API gateways -- operate
independently. Without an explicit response-path coordination
mechanism, downstream components may not observe the
application's selected action and may therefore apply their own
local policy independently.
The enforcement intent exists. It is not propagated.
This specification defines a coordination mechanism for HTTP.
The Enforcement-Action response header field carries an advisory
selected-action token downstream on the HTTP response path, from
the application to cooperating intermediaries within a trusted
boundary. The field is advisory: intermediaries apply their
local policy in response to the signal. The field is safe to
ignore: intermediaries that do not recognize it continue normal
HTTP operation without error or fallback.
The design rationale for the coordination mechanism is described
informatively in Appendix A.
1.1. Problem Statement
HTTP deployments are not monolithic. A single request traverses
multiple independent components -- application server, reverse
proxy, API gateway, CDN edge node -- each of which may make
enforcement decisions independently. These decisions are
commonly selected using deployment-private detection, policy, and
enforcement logic. A downstream intermediary can therefore
observe the resulting HTTP response without being able to
determine which action an upstream component selected. Existing
HTTP mechanisms address adjacent concerns -- identity, outcome,
observability -- but none of them carries a selected action
downstream on the response path to cooperating infrastructure
components; see Section 1.3.
Deployments can address this problem through shared state,
centralized control planes, or proprietary signaling. However,
HTTP does not define a standard response-path field for
exposing a selected action to cooperating intermediaries. This
specification defines such a field without standardizing the
mechanism that selected the action.
This specification defines a minimal signal -- the
Enforcement-Action field -- that a trusted sender can generate
and a cooperating intermediary can process using deployment-
specific token semantics and local policy. It does not require
a proprietary control plane, but deployments still need to
define trust relationships and the meaning of any action tokens
they use.
1.2. Decision Layer and Coordination Mechanism
The design of this specification rests on a precise distinction
between two layers.
The decision layer comprises components that produce enforcement
decisions. This layer includes the decision engine and all
components specific to a deployment's security architecture.
The decision layer is deployment-specific. Its design,
implementation, and operation are outside the scope of
this specification.
The coordination mechanism is what this specification
standardizes. It is the means by which the decision layer's
output -- the selected action -- is carried to the
infrastructure components that may apply local policy in
response to it. The coordination mechanism consists of a
single HTTP response header field, its Structured Fields
syntax, its processing model, and its IANA registry.
The relationship between the two layers is as follows:
o The decision layer determines WHAT to enforce. The decision
engine observes request context, evaluates it against its
internal model, and produces an enforcement decision.
o The coordination mechanism defines how a selected action can
be represented and processed downstream on the HTTP response
path by cooperating intermediaries. The Enforcement-Action
field carries the selected action downstream on the HTTP
response path to cooperating intermediaries within the
trusted boundary.
This distinction is the architectural basis of this
specification. Only the coordination mechanism -- the signal
that carries the selected action -- is standardizable across
deployment boundaries; the decision layer that produces it is
not, since different deployments face different threats and
will implement different engines. The draft history of this
architectural distinction is recorded in Appendix B.
1.3. Relationship to Existing HTTP Mechanisms
HTTP already defines mechanisms for adjacent concerns:
o Identity: authentication headers establish who the client is.
o Outcome: status codes per [RFC9110] communicate what happened
to the request.
o Observability: Proxy-Status per [RFC9209] reports what
intermediaries did.
Each of these mechanisms is either client-facing or
observability-facing. They communicate outcomes to the client
or to logging infrastructure. None of them is designed to carry
an enforcement decision from the application to cooperating
infrastructure components within a trusted boundary.
The Enforcement-Action field addresses this gap. It carries a
selected-action token downstream on the HTTP response path, from
a trusted sender to cooperating intermediaries. It does not
replace any existing mechanism. It complements them by
completing the coordination surface that HTTP provides for
distributed deployments.
1.4. Measurement Motivation
This specification is motivated by a measurement problem in
distributed HTTP deployments. When an application makes an
enforcement decision, downstream intermediaries may observe only
ordinary response signals, such as status code, unrelated
response headers, body size, latency, local logs, or proxy
reports. Multiple internal decisions can be compatible with the
same observable response.
This creates decision ambiguity. For example, a 200 (OK)
response may be compatible with an ordinary allow decision, a
transparent monitoring decision, a silent throttle, or a content
filtering decision, depending on the deployment. In such cases,
intermediaries that do not receive the decision explicitly must
reconstruct it from indirect signals.
The Enforcement-Action field reduces this ambiguity by making
the upstream enforcement decision visible to cooperating
intermediaries within a trusted boundary. This document does
not define a measurement methodology, but the field is intended
to support evaluation of decision visibility, reconstructability,
consistency, and overhead in distributed HTTP deployments.
The trade-off can be summarized as ambiguity versus overhead:
without an explicit field, HTTP remains lightweight but the
decision may remain ambiguous; with an explicit field, ambiguity
is reduced, but deployments incur measurable costs such as
additional response bytes, parsing, logging, and boundary
handling.
A functional prototype described in Section 7 demonstrates these
conditions in a three-hop response path: implicit signaling,
explicit preservation, and boundary stripping.
1.5. Document Structure
Section 2 defines terminology used in this specification.
Section 3 defines the Enforcement-Action header field, its
Structured Fields Item syntax, and its parameter structure.
Section 4 defines the processing model for senders,
intermediaries, and recipients.
Section 5 addresses security considerations specific to the
field and its deployment context.
Section 6 addresses IANA considerations. This document
registers the field name only; action-token and parameter
semantics are deployment-defined.
Section 7 records the implementation status of this
specification per [RFC7942].
Appendix A provides an informative, minimal deployment example
showing the field in use across a trusted boundary. Implementers
are not bound by Appendix A.
Appendix B documents the revision history of this draft series,
explaining the architectural distinction between the decision
layer explorations in drafts 00 through 02 and the coordination
mechanism specification in drafts 03 and 04.
2. Terminology
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.
Enforcement-Action field:
The HTTP response header field defined by this specification.
It carries an advisory selected-action token from a sender
to recipients within a trusted boundary.
Action token:
The primary value of the Enforcement-Action field. A
Structured Fields Token (Section 4.1.7 of [RFC9651])
representing an advisory selected action selected by a
deployment-specific decision layer. Action-token semantics
are deployment-defined. This document registers the field
name only.
Parameter:
An optional Structured Fields parameter qualifying the
action token, per Section 3.1.2 of [RFC9651]. Parameter
keys MUST be Structured Fields keys. Parameter values in
this field are limited to Tokens, Integers, Decimals,
Strings, and Booleans.
Trusted boundary:
The set of components under coordinated administrative or
policy control within which the Enforcement-Action field
is meaningful. Defined administratively by the deployment.
Operational guidance for boundary definition is provided
in Appendix A.
Sender:
An origin server or proxy that includes the Enforcement-
Action field in an HTTP response.
Recipient:
A downstream component -- proxy, CDN edge node, or client
-- that receives the Enforcement-Action field.
Intermediary:
A proxy or CDN edge node that MAY inspect, act upon, or
forward the Enforcement-Action field.
Decision layer:
The deployment-specific components that select enforcement
actions based on request context. The decision layer does
not include the response-path coordination mechanism defined
by this specification. Described informatively in
Appendix A.
Coordination mechanism:
The mechanism defined by this specification. Comprises
the Enforcement-Action field, its Structured Fields syntax, its
processing model, and its IANA registration. Carries the
output of the decision layer to cooperating intermediaries
within the trusted boundary.
Decision engine:
A deployment-specific component that selects an enforcement
action based on request context. A sender MAY serialize
that selected action as an Enforcement-Action field value.
The decision engine is outside the scope of this
specification. A minimal example is described informatively
in Appendix A.
Safe-to-ignore:
The behavioral guarantee that if a recipient does not
recognize the Enforcement-Action field or its action token,
HTTP behavior is unchanged. No error, no fallback, and no
protocol failure results from ignoring the field.
Selected-action visibility:
The condition in which a component receives, successfully
parses, and accepts an Enforcement-Action field from a
trusted source. Selected-action visibility does not
guarantee that a component acts upon the field uniformly,
since the field is advisory and subject to local policy.
Token consistency:
The condition in which two or more components with
selected-action visibility observe the same action token
for the same response.
3. The Enforcement-Action Header Field
3.1. Field Definition
The Enforcement-Action field is an HTTP response header field.
It is not a hop-by-hop field. An intermediary MAY forward or
remove it according to the processing rules in Section 4 and
the trust-boundary considerations in Section 5.
The field carries an advisory selected-action token from a sender
to recipients within a trusted boundary. The sender MUST NOT
rely on recipients to enforce the action. Recipients apply
their local policy in response to the signal. Recipients that
do not recognize the field or its action token MUST treat the
field as a no-op.
This specification standardizes the field name, syntax,
response-path processing model, and safe-to-ignore behavior.
It does not standardize the operational meaning, target,
duration, or enforcement effect of individual action tokens or
parameters; those remain deployment-defined.
The field MUST NOT be included in 304 (Not Modified) responses.
A 304 response can update metadata of a stored response under
[RFC9111]. Including Enforcement-Action could therefore
associate a newly selected action token with a previously
stored representation.
3.2. Field Syntax
The Enforcement-Action field is a Structured Header [RFC9651].
It MUST NOT be sent in HTTP trailers or in informational
(1xx) responses. Its value is an Item (Section 3.3 of
[RFC9651]). The Item's bare-item MUST be a Token (Section
4.1.7 of [RFC9651]) representing a deployment-selected action.
Parameters on the Item (Section 3.1.2 of [RFC9651]) carry
optional context qualifying the action token.
Implementations MUST use a Structured Fields parser [RFC9651]
to parse the field value.
A sender MUST NOT generate more than one Enforcement-Action
field line in a response. A recipient that receives multiple
Enforcement-Action field lines MUST treat the field as invalid
and MUST NOT apply enforcement based on any of their values. A
recipient that cannot parse the field as a Structured Fields
Item MUST treat the field as absent and MUST NOT apply
enforcement based on that field value. An intermediary that
treats the field as invalid MAY remove all Enforcement-Action
field lines before forwarding the response.
Examples:
Enforcement-Action: challenge
Enforcement-Action: throttle; rate=10
Enforcement-Action: block
Enforcement-Action: monitor
3.3. Field Parameters
Parameters qualify the action token with additional context
meaningful to recipients within the trusted boundary.
Parameters are Structured Fields parameters per Section 3.1.2
of [RFC9651]. Parameter keys MUST be Structured Fields keys as
defined in [RFC9651]. Parameter values in this field are
limited to Tokens, Integers, Decimals, Strings, and Booleans as
defined in [RFC9651]; this specification does not use the Byte
Sequence, Date, or Display String types. Recipients that do
not recognize a parameter MUST ignore it. Unrecognized
parameters MUST NOT cause the action token to be treated as
unrecognized.
Parameter semantics are deployment-defined. This document
registers the field name only.
Multiple parameters are separated by semicolons:
Enforcement-Action: throttle; rate=10; duration=3600
4. Processing Model
4.1. Sender Behavior
A sender -- an origin server or a proxy within the trusted
boundary -- MAY include the Enforcement-Action field in an
HTTP response.
The sender:
o MUST NOT rely on recipients to enforce the action. The
field is advisory. Enforcement is at the recipient's
discretion per local policy.
o MUST NOT include the field in 304 (Not Modified) responses.
o SHOULD include the field only when it expects the response
to traverse one or more cooperating recipients within the
trusted boundary, and when boundary-edge stripping is
configured before the response reaches an untrusted
recipient.
o The presence or absence of the Enforcement-Action field does
not define, modify, or override HTTP response semantics,
including status-code meaning. A sender MAY return any
status code appropriate to its own application behavior
independently of the action token it selects.
4.2. Intermediary Behavior
An intermediary -- a CDN edge node, reverse proxy, or API
gateway -- that receives a response containing an
Enforcement-Action field:
o MAY inspect and act upon the field in accordance with
local policy.
o MAY forward the field to downstream components within the
trusted boundary.
o MUST remove the Enforcement-Action field before forwarding a
response from within the trusted boundary to a recipient
outside that boundary. A deployment that intentionally
exposes the field outside the trusted boundary is outside
the scope of this specification.
o MUST ignore the field if the action token is unrecognized.
Unrecognized tokens MUST be treated as a no-op. HTTP
behavior MUST be unchanged.
o MUST NOT act on the field if the source cannot be
authenticated as being within the trusted boundary.
4.3. Recipient Behavior
A cooperating recipient is a recipient within the trusted
boundary that is authorized by local policy to process
Enforcement-Action.
A cooperating recipient MAY act upon the field in accordance
with local policy only when it authenticates the immediate
upstream source and authorizes that source to originate or
forward the field.
A recipient that is not a cooperating recipient, including a
recipient outside the trusted boundary, MUST NOT apply
enforcement based on the field value. Such a recipient MAY
ignore the field.
A recipient that does not recognize the field or its action
token MUST treat it as a no-op.
A recipient MUST NOT interpret the field as changing HTTP
response semantics or status-code meaning. Caching
considerations are defined in Section 5.5.
4.4. Safe-to-Ignore Guarantee
If a recipient does not recognize the Enforcement-Action field
or its action token, HTTP behavior is unchanged. No error
results. No fallback is required. The response is processed
as if the field were not present.
A recipient that does not recognize a parameter MUST ignore
that parameter as specified in Section 3.3. An unrecognized
parameter does not by itself cause the action token to be
treated as unrecognized.
This guarantee applies to recipients that do not recognize, do
not trust, or choose not to act upon the field. Such recipients
process the response according to ordinary HTTP rules, without
protocol error, fallback, or mandatory enforcement. It does not
mean that a recipient which recognizes the field and chooses to
act on it will preserve every behavioral outcome a sender might
expect; enforcement remains at the recipient's discretion per
local policy.
5. Security Considerations
The Enforcement-Action field is an advisory coordination mechanism.
It does not mandate enforcement. Recipients apply their own local
policy in response to the signal. This section describes the
security properties of the field and the considerations relevant
to its deployment.
5.1. Advisory Semantics
The Enforcement-Action field does not mandate enforcement.
Intermediaries apply their local policy in response to the field
value. An intermediary that determines its local policy does not
warrant a response to the field MAY ignore it entirely.
The safe-to-ignore design prevents unintended enforcement cascades.
If an intermediary does not recognize the action token, it MUST
treat the field as a no-op. HTTP behavior is unchanged. No error
results and no fallback is required.
Because the field is advisory, a malfunctioning or misconfigured
intermediary that fails to act on the field does not create a
protocol failure. The origin application continues to function
normally. The consequence of non-enforcement is a coordination
gap -- which is the problem the field is designed to reduce, not
a safety failure introduced by the field itself.
5.2. Trust Boundaries
The Enforcement-Action field is meaningful only within a trusted
boundary -- the set of components under coordinated administrative
or policy control that have agreed to participate in enforcement
coordination.
The trusted boundary defined in this specification is
administratively scoped. Deployments that require cryptographic
boundary verification MAY use existing HTTP mechanisms such as
HTTP Message Signatures [RFC9421] to make participation within
the boundary verifiable; this is outside the scope of this
specification.
Intermediaries MUST remove the Enforcement-Action field before
forwarding responses to parties outside the trusted boundary,
per Section 4.2. Failure to strip the field at the boundary
edge may expose the selected action to untrusted parties. It
does not create a protocol failure, as the field is advisory
and external recipients are not cooperating intermediaries.
Operational guidance for trust boundary definition, boundary
edge identification, and source authentication within the
boundary is provided in Appendix A.
5.3. Injection Protection
An untrusted party that injects an Enforcement-Action field value
into a response path it does not control may cause cooperating
intermediaries to apply incorrect enforcement actions.
To mitigate injection risk:
o Recipients MUST NOT act on an Enforcement-Action field value
received from a source that is not authenticated as being
within the trusted boundary.
o Intermediaries SHOULD authenticate the source of field values
before applying enforcement. Authentication MAY rely on the
authenticated TLS connection over which the response was
received, on network topology constraints within a controlled
administrative domain, or on pre-configured trusted source
lists.
o A recipient that cannot authenticate the source of an
Enforcement-Action field MUST treat the field as untrusted
and MUST NOT apply enforcement based on its value.
Because the field is advisory, an injected field value can only
cause an intermediary to apply enforcement it would not otherwise
have applied. An intermediary that applies local policy correctly
-- including verification of the source -- is not vulnerable to
injection from untrusted parties.
Authentication of the immediate HTTP peer does not necessarily
authenticate the original producer of the field. A deployment
that forwards Enforcement-Action through intermediaries MUST
define which intermediaries are trusted to originate, preserve,
modify, or remove the field. An intermediary that receives
Enforcement-Action from an untrusted upstream source MUST remove
the field before forwarding the response to a trusted downstream
recipient, unless local policy authorizes that source to
originate the field.
5.4. Information Exposure
The Enforcement-Action field conveys a selected action. It does
not convey detection reasoning, behavioral scores, client
identity, or internal policy configuration.
A field value such as "Enforcement-Action: throttle" tells a
recipient that the origin wishes to throttle the client. It does
not tell the recipient why the action was selected, what signals
were observed, or what scoring thresholds are configured.
This design limits information exposure to the minimum required
for coordination. Internal enforcement posture is not exposed
by design.
Intermediaries MUST strip the field at the trust boundary edge
before forwarding responses to clients or untrusted parties,
per Section 4.2. If a client nevertheless receives an
Enforcement-Action field, it learns that an action was
selected. It does not learn the reasoning behind that
selection.
5.5. Caching Considerations
The Enforcement-Action field does not define cache behavior and
does not modify the caching rules in [RFC9111].
A sender MUST NOT include Enforcement-Action in a response that
can be reused by a shared cache unless the field value is valid
for every request to which that stored response can be reused.
When an action token is specific to a client, session, request,
or other non-reusable context, the sender MUST use appropriate
HTTP cache controls or deployment configuration to prevent
inappropriate reuse of the field value. For example, a sender
can use Cache-Control: no-store when an action token is
specific to an individual request or client and no cache reuse
is appropriate. This is not the only valid approach; private
cache control, Vary, and other deployment-specific cache
configuration can also be appropriate depending on context.
A cache or intermediary that serves a stored response containing
Enforcement-Action MUST apply ordinary HTTP caching rules. It
MUST NOT infer that the field value remains valid for a different
client, session, or request context.
5.6. No Transport Modification
The Enforcement-Action field introduces no changes to TLS, QUIC,
HTTP/2, HTTP/3, or any transport or session layer mechanism.
It is carried as a standard HTTP response header field and
processed according to the rules in Section 4.
The field does not interact with connection establishment,
session resumption, or transport-layer security negotiation.
Removing the field from a response has no effect on the
underlying HTTP connection or transport session.
6. IANA Considerations
IANA is requested to register the following entry in the
"Hypertext Transfer Protocol (HTTP) Field Name Registry"
per [RFC9110]:
Field name: Enforcement-Action
Status: permanent
Structured Type: Item
Reference: This document
This document registers the field name only. Action-token and
parameter semantics are deployment-defined and are not subject
to IANA registration by this specification.
7. Implementation Status
Note to the RFC Editor: Please remove this section before
publication.
This section records the status of known implementations of the
protocol defined by this specification at the time of posting of
this Internet-Draft, and is based on a proposal described in
[RFC7942]. The description of implementations in this section
is intended to assist the IETF in its decision processes in
progressing drafts to RFCs. Please note that the listing of
any individual implementation here does not imply endorsement by
the IETF. Furthermore, no effort has been spent to verify the
information presented here that was supplied by IETF contributors.
This is not intended as, and must not be construed to be, a
catalog of available implementations or their features. Readers
are advised to note that other implementations may exist.
According to [RFC7942], "this will allow reviewers and working
groups to assign due consideration to documents that have the
benefit of running code, which may serve as evidence of valuable
experimentation and feedback that have made the implemented
protocols more mature. It is up to the individual working groups
to use this information as they see fit."
7.1. SecRoot.io Reference Enforcement Implementation
Organization: SecRoot.io, Rabat, Morocco.
Name: enforcement-action-nginx
Description: A prototype deployment combines a C-based
decision engine with NGINX response-path
configuration to emit and forward
Enforcement-Action field values conforming to
the Structured Fields Item syntax defined in
Section 3.2.
Coverage: The prototype exercises sender-side generation
and response-path forwarding of Enforcement-
Action field values using NGINX-based
configuration.
Interoperability testing: Initial testing has been performed
with NGINX-based configurations.
Licensing: Proprietary. Contact: contact@secroot.io.
Contact: Rachid Bouziane <contact@secroot.io>
URL: https://secroot.io
7.2. Three-Hop Observability Prototype
Organization: SecRoot.io, Rabat, Morocco.
Name: Enforcement-Action Observability Prototype.
Description: A separate functional prototype, distinct from
the reference implementation in Section 7.1, was
implemented to evaluate selected-action visibility
across a distributed HTTP response path.
Topology:
Decision Application -> Gateway -> Edge Proxy -> Client
The trust-boundary placement in this experiment is
configuration-specific and differs from the illustrative
deployment in Appendix A.
The decision application selected one action token from a
deployment-defined vocabulary:
allow, monitor, throttle, filter
The prototype evaluated three response-path conditions:
o implicit: the decision application selected an action but did
not emit an Enforcement-Action field;
o explicit: the decision application emitted an
Enforcement-Action field and the gateway preserved it when
forwarding the response to the edge proxy; and
o strip: the decision application emitted an Enforcement-Action
field, the gateway observed it, and the gateway removed it
before forwarding the response to the edge proxy.
Each request carried a correlation identifier. The decision
application, gateway, and edge proxy recorded request-correlated
logs. The logs recorded the selected action at the decision
application and the Enforcement-Action value observed at each
downstream component.
In the tested configuration, the implicit condition exposed no
selected-action token at either downstream component. The
explicit condition exposed the same token at both components.
In the strip condition, the gateway observed the token and
removed it before the edge proxy, which was configured outside
the trusted boundary for the purposes of this experiment; this
demonstrates boundary stripping only under that configuration,
not as a general property of any gateway-to-edge hop.
This prototype demonstrates functional response-path
propagation, request correlation, and configured boundary
stripping. It is not a production-performance evaluation or a
general measurement method. It is a separate observability
experiment and is not a claim about the behavior of the
reference enforcement implementation in Section 7.1.
Licensing: Proprietary. Contact: contact@secroot.io.
Contact: Rachid Bouziane <contact@secroot.io>
URL: https://secroot.io
8. References
8.1. Normative References
[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/info/rfc2119>.
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines
for Writing an IANA Considerations Section in RFCs",
BCP 26, RFC 8126, DOI 10.17487/RFC8126, June 2017,
<https://www.rfc-editor.org/info/rfc8126>.
[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/info/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/info/rfc9110>.
[RFC9111] Fielding, R., Ed., Nottingham, M., Ed., and
J. Reschke, Ed., "HTTP Caching", STD 98,
RFC 9111, DOI 10.17487/RFC9111, June 2022,
<https://www.rfc-editor.org/info/rfc9111>.
[RFC9651] Nottingham, M. and P.-H. Kamp, "Structured Field
Values for HTTP", RFC 9651,
DOI 10.17487/RFC9651, September 2024,
<https://www.rfc-editor.org/info/rfc9651>.
8.2. Informative References
[RFC7942] Sheffer, Y. and A. Farrel, "Improving Awareness of
Running Code: The Implementation Status Section",
BCP 205, RFC 7942, DOI 10.17487/RFC7942, July 2016,
<https://www.rfc-editor.org/info/rfc7942>.
[RFC9209] Nottingham, M. and P. Sikora, "The Proxy-Status
HTTP Response Header Field", RFC 9209,
DOI 10.17487/RFC9209, June 2022,
<https://www.rfc-editor.org/info/rfc9209>.
[RFC9421] Backman, A., Ed., Richer, J., Ed., and
M. Sporny, "HTTP Message Signatures", RFC 9421,
DOI 10.17487/RFC9421, February 2024,
<https://www.rfc-editor.org/info/rfc9421>.
Appendix A. Deployment Example (Informative)
This appendix is entirely informative. Nothing in this appendix
is normative. A sender or intermediary can conform to this
specification without using the deployment example in this
appendix.
The following example illustrates the Enforcement-Action field
in a minimal four-component deployment.
Deployment topology:
Application -> Gateway -> Edge -> Client
Trusted boundary: Application, Gateway, and Edge are
co-administered under a common operational policy. The Client
is outside the trusted boundary.
Application:
The application evaluates a request using deployment-specific
logic outside the scope of this specification, selects an
action, and includes it in the response:
Enforcement-Action: throttle
Gateway:
The Gateway is within the trusted boundary. It recognizes
the field, forwards it downstream, and MAY apply its own
local policy in response to the token.
Edge:
The Edge is the boundary-edge intermediary. Two outcomes
are possible, depending on deployment configuration:
o Within the boundary, the Edge recognizes the field and
MAY apply local policy in response to the token.
o Before forwarding the response outside the trusted
boundary, the Edge MUST strip the field per Section 4.2.
Client:
The Client is outside the trusted boundary. It does not
receive the Enforcement-Action field. HTTP semantics --
status code, response headers, and body -- are unaffected
by the field's presence, absence, or removal at any point
in the path.
Key observations:
o Each component that recognizes the field applies enforcement
per its own local policy. The field carries the selected
action; enforcement details are determined locally.
o Before forwarding the response to the Client, the Edge
strips the field at the trust boundary. The Client
receives no enforcement signal.
o If any component had not recognized the token, it would have
treated the field as a no-op. HTTP behavior would have been
unchanged. The safe-to-ignore guarantee holds regardless of
recipient sophistication.
Appendix B. Revision History (Informative)
B.1. Changes from draft-02 to draft-03
Drafts 00 through 02 explored the decision layer -- the engine
architecture, its decision phases, its behavioral analysis
methodology, and its external agent integrations. That
exploration was necessary to understand what the coordination
mechanism needed to carry. The decision layer is not
standardizable as a unit: different deployments face different
threats and will implement different engines.
Draft-03 extracted the protocol-layer element from that
exploration: the Enforcement-Action field. The following
were removed from the normative specification:
o The OODA framework framing and OODA-HTTP terminology.
o The seven-phase loop as a normative requirement.
o Machine learning engine specifications (SVDD, PSLPSO).
o Frontend DOM instrumentation (OODA-DOM).
o The JSON header format (OODA-Action).
o Quantum threat model claims.
o External agent integration as normative protocol behavior.
The header field was renamed from OODA-Action to
Enforcement-Action to reflect the narrowed, framework-neutral
scope. There is no protocol contradiction between the draft
versions because the earlier versions were not defining a
protocol. They were exploring the decision layer that the
coordination mechanism serves.
B.2. Changes from draft-03 to draft-04
Draft-04 returns the decision layer material to its correct
position as informative reference content, and narrows the
scope of this document to a minimal HTTP field so that
reviewers evaluate a header field, not a security framework.
The field definition and processing model from draft-03
(Sections 3 and 4) are unchanged in substance. The following
additions and updates were made:
o Section 1.1 added: Problem Statement. Provides the
unified framing of the enforcement coordination gap,
documenting the common structural cause behind the
symptoms that industry has addressed with point solutions.
o Section 1.2 added: Decision Layer and Coordination
Mechanism. Explains the architectural distinction between
the decision layer and the coordination mechanism. The
draft-history discussion previously included here has been
moved to this appendix to keep the introduction focused on
what is invisible, what the field exposes, and what the
field does not standardize.
o Section 1.4 added: Measurement Motivation. Explains
the ambiguity versus overhead rationale for evaluating
decision visibility in distributed HTTP deployments, and
adds a one-sentence pointer to the three-hop observability
prototype described in Section 7.2.
o Section 1.5 updated: document structure description
reflects field-name-only IANA registration and the
Implementation Status section.
o Abstract and Section 3.1 updated: add a decisive scope
statement -- this specification standardizes the field
name, syntax, response-path processing model, and
safe-to-ignore behavior, and does not standardize the
operational meaning, target, duration, or enforcement
effect of individual action tokens or parameters.
o Section 2 updated: "Consistent enforcement" replaced with
"Selected-action visibility" and "Token consistency."
Selected-action visibility describes a component receiving,
parsing, and accepting the field from a trusted source; token
consistency describes two or more such components observing
the same action token. Neither implies uniform recipient
behavior, which this specification does not guarantee.
"Advisory enforcement decision" language describing what the
field itself carries is replaced throughout with "advisory
selected-action token."
o Sections 1.1 and 1.3 updated: the RateLimit citation is
removed. It incorrectly referenced [RFC9333] (Minimal IP
Encapsulating Security Payload), which is unrelated to HTTP
rate-limit header fields; the actual RateLimit header field
specification is an active Internet-Draft, not an RFC, and
is not cited. [RFC9333] is removed from the references.
o Section 3.2 updated: the field is declared a Structured
Header per the field-definition requirements of [RFC9651],
and is explicitly prohibited from HTTP trailers and
informational (1xx) responses.
o Section 3.1 updated: the 304 (Not Modified) prohibition is
explained by reference to [RFC9111]'s stored-response
metadata update behavior, connecting the rule to the
caching considerations in Section 5.5.
o Section 4.1 updated: the sender boundary rule is reworded to
account for responses traversing multiple cooperating
recipients before reaching a boundary edge, rather than
implying the response is directed to a single recipient.
o Section 3.2 updated: adds explicit handling rules for
multiple Enforcement-Action field lines and unparseable
field values; both MUST NOT be used as a basis for
enforcement.
o Section 4.1 updated: the prior statement that senders
MUST NOT modify HTTP status codes to reflect enforcement
intent is replaced with a statement that the field does
not define, modify, or override HTTP response semantics,
including status-code meaning. A sender MAY select any
status code appropriate to its own application behavior
independently of the action token.
o Section 4.4 updated: the safe-to-ignore guarantee is
scoped explicitly to recipients that do not recognize, do
not trust, or choose not to act upon the field; it no
longer implies that recipients which do act on the field
preserve every behavioral outcome.
o Section 5.2 updated: trust boundary section adds
reference to HTTP Message Signatures [RFC9421] as a
candidate mechanism for cryptographic boundary
verification in future work.
o Section 5.3 updated: adds provenance rules distinguishing
authentication of the immediate HTTP peer from
authentication of the field's original producer, and
requires deployments to define which intermediaries are
trusted to originate, preserve, modify, or remove the
field.
o Section 5.5 added: Caching Considerations. Adds rules
preventing a sender from including a client-, session-, or
request-specific action token in a response reusable by a
shared cache, and clarifies that caches serving a stored
Enforcement-Action value MUST NOT infer it remains valid
for a different context. [RFC9111] added as a normative
reference. The prior "No Transport Modification"
subsection is renumbered to Section 5.6.
o Section 6 (IANA Considerations) narrowed to field-name
registration only. The Enforcement-Action Token Registry
proposed in an earlier working version of this draft is
removed; action-token and parameter semantics remain
deployment-defined, consistent with the advisory,
framework-neutral scope of this specification.
o Section 7 added: Implementation Status per [RFC7942].
Two distinct implementations are recorded in separate
subsections rather than merged into a single description.
Section 7.1 records the SecRoot.io reference enforcement
implementation (a C-based decision engine integrated with
NGINX). Section 7.2 records a separate three-hop
observability prototype (a decision application, gateway,
and edge proxy) used to evaluate selected-action visibility
under implicit, explicit, and strip conditions. Each
subsection describes only the implementation it reports on;
neither implementation's claims are attributed to the other.
Section 7.1's description is worded neutrally as to how the
C-based decision engine and NGINX are combined, and drops an
interoperability claim for HAProxy and Envoy that has not
been tested. Section 7.2 reports only the observed presence
or absence of the selected token at each downstream
component per condition; a measurement-methodology
discussion (candidate-set entropy) previously included here
has been removed, since Section 7 records running code and
its tested behavior rather than measurement methodology.
Section 7.2 also clarifies that the edge proxy was
configured as outside the trusted boundary for the strip
condition specifically, so the result demonstrates boundary
stripping under that configuration rather than as a general
property of any gateway-to-edge hop.
o Appendix A replaced: the prior decision-engine reference
model (seven-phase engine, risk scoring, DOTS/SIEM
integration) is replaced with a short, minimal deployment
example. The decision-engine material reintroduced
framework-level detail inconsistent with the narrowed,
framework-neutral scope established in draft-03, and has
been removed rather than retained as an appendix. The
statement that a decision engine itself conforms to this
specification is corrected: conformance applies to a
sender or intermediary, not to the deployment example.
o References updated: [RFC8941] is replaced throughout with
[RFC9651], which obsoletes it, for Structured Fields.
o Section 4.4 updated: resolves a conflict with Section 3.3.
An unrecognized parameter is now explicitly stated to not
cause the action token to be treated as unrecognized, so
an intermediary can recognize the action token, ignore an
unrecognized extension parameter, and still apply local
policy for that token.
o Section 2 and Section 3.3 updated: parameter keys are
corrected from "Tokens" to "Structured Fields keys" per
[RFC9651], since Structured Fields keys and Tokens are
distinct grammars (keys are restricted to lowercase
characters, digits, "_", "-", ".", and "*").
o Section 1.1 updated: the closing paragraph is reworded to
avoid implying that any intermediary can process the field
independently of deployment-defined trust and token
semantics; deployments still need to define both.
o Section 2 updated: "Decision layer" and "Decision engine"
are reworded to describe action selection based on request
context, rather than language that blurred selection with
enforcement or application to HTTP traffic.
o Section 3.1 updated: the 304 explanation is shortened for
clarity while preserving the substantive point that a 304
response can update stored-response metadata under
[RFC9111].
o Section 7.2 updated: results are explicitly scoped to "the
tested prototype configuration" to avoid the per-condition
visibility results being read as a universal property of
all deployments.
o Section 1 and Section 1.1 updated: the absolute claim that
each component applies default behavior "without a
coordination mechanism" is corrected to acknowledge that
other coordination mechanisms (shared state, control
planes, proprietary signaling) exist; this specification's
contribution is a standard response-path field, not the
only possible coordination method. The three paragraphs
describing industry-wide symptoms and point solutions,
which made unreferenced claims and included weakly related
examples (request smuggling, cache poisoning), are replaced
with one focused paragraph.
o Section 1.2 updated: the claim that the coordination
mechanism "determines HOW that decision reaches the
components that enforce it" is corrected to describe the
mechanism as defining representation and processing, since
existing HTTP forwarding -- not this field -- determines
how responses reach components. "Components that enforce
it" is replaced with "components that may apply local
policy in response to it" throughout Sections 1.1 through
1.3 to preserve the advisory model.
o Section 2 updated: the Enforcement-Action field and Action
token definitions are revised to use "selected-action
token" as the primary normative term, reserving
"decision"/"intent" language for the deployment-specific
process that occurs before serialization into the field.
o Section 3.2 updated: the separate "Field values that do not
conform ... MUST be ignored" sentence is removed as
redundant with the parse-failure rule, which now also
specifies that such a field is treated as absent.
o Section 5.2 and Section 5.4 updated: "internal enforcement
intent" and "enforcement decision" language describing what
the field itself conveys is replaced with "selected action"
for consistency with the Section 2 terminology.
o Section 7.2 updated: the explicit-condition result is
reworded from "observed token consistency" to "observed the
same token for the tested response," since the former could
be read as a general property rather than a single recorded
result.
o Appendix A updated: "The field was stripped at the trust
boundary edge" is replaced with concrete language tied to
the Edge component's SHOULD-strip behavior, since the
example describes expected behavior rather than asserting
it necessarily occurred.
o Section 3.1 updated: "end-to-end field" is replaced with
"not a hop-by-hop field," since the field can be
deliberately removed at a trust boundary and "end-to-end"
could be read as contradicting that design.
o Section 7.1 updated: the Coverage statement is narrowed to
sender-side generation and response-path forwarding, which
the C/NGINX prototype specifically demonstrates; the prior
wording claimed safe-to-ignore and intermediary-stripping
behavior not specifically evidenced by that prototype.
o Section 7.2 updated: adds a sentence noting that the
trust-boundary placement in this experiment is
configuration-specific and differs from the illustrative
deployment in Appendix A, to avoid an apparent contradiction
between the two.
o Section 1.3 updated: "HTTP already standardizes several
coordination mechanisms" is replaced with "HTTP already
defines mechanisms for adjacent concerns," since not all of
identity, outcome, and observability mechanisms are
coordination mechanisms in the sense this document uses.
o Section 1.4 updated: "the resulting HTTP response: status
code, headers, ..." is replaced with "ordinary response
signals, such as status code, unrelated response headers,
...", since the Enforcement-Action field is itself a
header and the prior wording could read as self-
contradictory.
o Section 4.2 updated: boundary stripping is changed from
SHOULD to MUST for intermediaries forwarding a response
from within the trusted boundary to a recipient outside it,
with a stated exception for deployments that intentionally
expose the field outside the boundary. Sections 5.2, 5.4,
and Appendix A are updated to match.
o Section 4.3 rewritten: introduces "cooperating recipient" as
a recipient within the trusted boundary authorized by local
policy to process the field. Non-cooperating recipients,
including any recipient outside the trusted boundary, MUST
NOT apply enforcement based on the field. This removes an
earlier ambiguity about whether an untrusted client could
legitimately act on the field. The broad "MUST NOT allow
the field to affect ... caching behavior" bullet is replaced
with a narrower statement that the field does not change
HTTP response semantics or status-code meaning, with caching
handled exclusively in Section 5.5.
o Section 2 and Section 3.3 updated: parameter value types are
restated as an intentionally limited subset of [RFC9651]'s
bare-item types (Tokens, Integers, Decimals, Strings,
Booleans), explicitly excluding Byte Sequence, Date, and
Display String, which [RFC9651] also defines.
o Section 3.2 updated: "representing the enforcement action"
is replaced with "representing a deployment-selected action"
for consistency with the selected-action-token terminology
used elsewhere.
o Section 3.2 updated: adds that an intermediary treating the
field as invalid MAY remove all Enforcement-Action field
lines before forwarding, to prevent a malformed or
conflicting field from reaching another trusted component.
o Section 5.5 updated: adds a practical example noting that a
sender can use Cache-Control: no-store for a request- or
client-specific action token, while noting this is not the
only valid approach.
o Section 7.2 updated: the results discussion is shortened
while preserving that results are configuration-specific,
do not establish general performance, and are not a claim
about the reference implementation in Section 7.1.
o Sections 1.1 through 1.3 shortened: a mechanism-by-mechanism
list duplicated between Sections 1.1 and 1.3 is consolidated
into Section 1.3 only, and a redundant scope-restatement
paragraph in Section 1.2 is removed.
o Section 1.1 updated: adds two sentences noting that
enforcement decisions are commonly selected using
deployment-private detection, policy, and enforcement logic,
and that a downstream intermediary can therefore observe the
resulting HTTP response without being able to determine
which action an upstream component selected. This motivates
the coordination gap without implying that the private
detection, scoring, policy, or enforcement logic itself is
shared or standardized -- only the selected-action token is.
o Acknowledgements updated: Eric Rescorla for document
structure guidance; Rich Salz for recommending
Structured Fields as the field syntax and for guidance
on boundary stripping behavior; Professor Heng Li for
feedback on the measurement framing of the proof-of-concept.
Acknowledgements
The authors thank Rich Salz for recommending Structured Fields
[RFC9651] as the field syntax, and for guidance on boundary
stripping behavior in distributed HTTP deployments.
The authors thank Eric Rescorla for guidance on document
structure -- specifically the separation of the normative
coordination mechanism from the informative deployment example
in Appendix A of this document.
The authors thank Rifaat Shekh-Yusef for guidance on the
secdispatch presentation process and for directing this work
toward the appropriate IETF forum.
The author thanks Professor Heng Li for helpful feedback on the
measurement framing of the proof-of-concept, especially
regarding the distinction between local interpretation and
inter-component consistency, which helped refine the
protocol-level token-resolution model.
Author's Address
Rachid Bouziane
SecRoot.io
Rabat, Morocco
Email: contact@secroot.io