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 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 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, . [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, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC9110] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, Ed., "HTTP Semantics", STD 97, RFC 9110, DOI 10.17487/RFC9110, June 2022, . [RFC9111] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, Ed., "HTTP Caching", STD 98, RFC 9111, DOI 10.17487/RFC9111, June 2022, . [RFC9651] Nottingham, M. and P.-H. Kamp, "Structured Field Values for HTTP", RFC 9651, DOI 10.17487/RFC9651, September 2024, . 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, . [RFC9209] Nottingham, M. and P. Sikora, "The Proxy-Status HTTP Response Header Field", RFC 9209, DOI 10.17487/RFC9209, June 2022, . [RFC9421] Backman, A., Ed., Richer, J., Ed., and M. Sporny, "HTTP Message Signatures", RFC 9421, DOI 10.17487/RFC9421, February 2024, . 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