Enforcement-Action HTTP Header Field
draft-secroot-ooda-http-03

INTERNET-DRAFT                                              R. Bouziane
Intended Status: Standards Track                            SecRoot.io
Expires: 30 August 2026                                     1 March 2026
              
                Enforcement-Action HTTP Header Field
                 draft-secroot-ooda-http-03

Abstract

   This document defines the Enforcement-Action HTTP response header
   field. The field provides a minimal, interoperable mechanism for
   signaling advisory enforcement coordination between cooperating
   components operating within a defined administrative or policy trust
   boundary. The header conveys a single action token and optional
   parameters without modifying HTTP status code semantics or
   representation meaning. The field is designed to be safely ignored by
   recipients that do not recognize it and to operate over existing HTTP
   deployments without changes to transport protocols. This
   specification defines the syntax, semantics, processing rules, and
   IANA registration for the header field.

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 30 August 2026.

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.

1.  Introduction

   HTTP defines status codes that communicate the outcome of request
   processing and header fields that control caching and representation
   semantics.

   In certain deployments, including reverse proxies, API gateways, and
   other cooperating components operating within a shared trust
   boundary, there are cases where a response must remain semantically
   successful (e.g., 200 OK) while still signaling an advisory
   enforcement coordination adjustment.

   Existing HTTP status codes describe request outcomes and are not
   intended to convey advisory enforcement coordination independent of
   transaction semantics.

   This document defines the Enforcement-Action HTTP response header
   field to provide a minimal signaling mechanism while preserving
   existing HTTP semantics.  This specification does not standardize
   enforcement algorithms, detection models, token vocabularies,
   coordination frameworks, or operational enforcement mechanisms.

2.  Conventions and Terminology

   The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY"
   in this document are to be interpreted as described in BCP 14
   (RFC 2119, RFC 8174) when, and only when, they appear in all capitals.

   For the purposes of this specification, a trusted boundary is defined
   as a set of components operating under coordinated administrative or
   policy control, or under explicit bilateral trust configuration.

3.  Problem Statement

   HTTP status codes communicate the result of processing a specific
   request.  They are not designed to convey advisory enforcement
   coordination independent of that result.

   In deployments involving intermediaries within a trusted boundary,
   there are scenarios where enforcement coordination must occur without
   modifying client-visible semantics.

   This document defines a minimal HTTP response header field to support
   such coordination while preserving HTTP protocol behavior and
   semantic layering.

4.  Header Field Definition

4.1.  Field Name

   The header field name is:

      Enforcement-Action

   This field is defined for use in HTTP responses only.  The
   Enforcement-Action field is an end-to-end response header field.

4.2.  Syntax

   The Enforcement-Action field value is defined using ABNF (RFC 5234):

      Enforcement-Action = action-token *( OWS ";" OWS parameter )

      action-token       = token
      parameter          = token "=" token

   The definitions of "token" and "OWS" are imported from RFC 9110.

4.3.  Semantics

   The Enforcement-Action header field conveys an advisory,
   deployment-defined enforcement coordination signal associated with
   the response.

   The presence of the field does not modify HTTP status code semantics,
   representation metadata, caching semantics, or content negotiation
   behavior.

   This specification does not define specific action tokens.  The
   meaning of action tokens and parameters is deployment-defined.

5.  Processing Rules

5.1.  General

   The Enforcement-Action header field is defined for HTTP responses
   only.  Recipients MUST ignore the field if received in an HTTP
   request.

   The field MUST NOT be included in 304 (Not Modified) responses.

5.2.  Sender Behavior

   A sender MAY include the Enforcement-Action header field in a
   response to convey an advisory enforcement coordination signal.

   Senders SHOULD generate the field only within authenticated or
   policy-trusted contexts operating within a trusted boundary.

   A sender MUST NOT rely on recipients to enforce a specific action.

5.3.  Recipient Behavior

   Recipients MAY ignore the Enforcement-Action field entirely.

   Recipients MUST NOT assume authenticity or integrity beyond what is
   provided by the underlying transport security.

   Recipients MUST only honor the Enforcement-Action field when it is
   received from authenticated and policy-trusted sources operating
   within a defined trusted boundary.

   Recipients that recognize the field:

      * MUST parse the field according to Section 4.
      * MUST treat unrecognized action tokens as no-op.
      * MUST ignore unrecognized parameters.
      * MUST ignore the entire field if parsing fails.
      * MUST NOT alter HTTP status semantics based solely on the field.

5.4.  Multiple Header Instances

   A response SHOULD include at most one Enforcement-Action header
   field.

   If multiple instances are present, recipients MUST process only the
   first occurrence and ignore subsequent instances.

6.  Intermediary Behavior

   Intermediaries MAY forward the Enforcement-Action header field
   unchanged.

   Intermediaries operating within a trusted boundary MAY consume and
   remove the header before forwarding the response beyond that
   boundary.

   Intermediaries SHOULD remove the header when forwarding responses
   beyond the intended trusted boundary unless explicitly configured
   otherwise.

   Intermediaries MUST NOT modify HTTP status code semantics solely due
   to the presence of the Enforcement-Action field.

7.  Caching Considerations

   The presence of the Enforcement-Action header field does not modify
   HTTP caching semantics.

   Caches MUST evaluate cacheability according to existing HTTP caching
   rules independent of the presence of this field (RFC 9111).

   Deployments that use Enforcement-Action for client-specific
   coordination SHOULD ensure that responses containing the field are
   not reused across unrelated clients unless explicitly intended.

8.  Security Considerations

   The Enforcement-Action header field conveys advisory enforcement
   coordination signals.  Improper interpretation may result in
   unintended policy decisions within a deployment.

   The field does not provide authentication, authorization, integrity,
   or confidentiality guarantees beyond those provided by the underlying
   HTTP transport.

   When used over authenticated transports (e.g., HTTPS), the field
   benefits from transport security.  When used over unauthenticated
   transports, it may be modified or injected by on-path attackers.

   Recipients MUST treat the field as untrusted unless received from
   authenticated and policy-trusted sources operating within a defined
   trusted boundary.

   Intermediaries and recipients SHOULD consider the potential
   disclosure of operational enforcement posture when forwarding the
   field beyond a trusted boundary.

   The field MUST NOT be interpreted as a replacement for HTTP
   authentication, authorization, rate-limiting, or access control
   mechanisms.

9.  IANA Considerations

   IANA is requested to register the following HTTP response header
   field in the "Hypertext Transfer Protocol (HTTP) Field Name
   Registry":

      Field Name:  Enforcement-Action
      Status:      permanent
      Reference:   This document

   No additional IANA registries are created by this specification.

10.  Examples

   The following examples illustrate possible uses of the
   Enforcement-Action header field.  These examples are deployment-
   specific and are provided for illustrative purposes only.

   Example 1:

      HTTP/1.1 200 OK
      Content-Type: application/json
      Enforcement-Action: isolate

   Example 2:

      HTTP/1.1 200 OK
      Content-Type: text/html
      Enforcement-Action: throttle; score=87

11.  Non-Goals

   This specification does not:

   * Define a threat model or attack taxonomy.
   * Define enforcement algorithms or decision logic.
   * Standardize action token vocabularies or parameter registries.
   * Establish a control-plane coordination protocol.
   * Replace HTTP authentication, authorization, or access control
     mechanisms.
   * Modify HTTP status code semantics or transaction outcome behavior.

   The Enforcement-Action header field defines only a minimal advisory
   signaling surface within a trusted boundary.

Appendix A.  Change History

   This header field was previously named "OODA-Action".  It has been
   renamed to "Enforcement-Action" to reflect the narrowed,
   framework-neutral scope of this specification.

12.  References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", RFC 2119.

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", RFC 8174.

   [RFC5234]  Crocker, D., Ed., and P. Overell, "Augmented BNF for
              Syntax Specifications", RFC 5234.

   [RFC9110]  Fielding, R., Ed., "HTTP Semantics", RFC 9110.

   [RFC9111]  Fielding, R., Ed., "HTTP Caching", RFC 9111.

Author's Address
   Rachid Bouziane
   SecRoot.io
   Email: contact@secroot.io
   Morocco