



Network Working Group                                         M. Dierken
Internet-Draft                                              paywalls.net
Intended status: Experimental                              17 March 2026
Expires: 18 September 2026


                      Conditional Access for HTTP
                draft-dierken-conditional-access-http-00

Abstract

   This document introduces conditional access to resources based on
   pricing constraints signaled via request and response headers.  An
   origin states the conditions for serving a resource, and a client
   states the constraints under which it will accept it.

   This specification applies this conditional access approach using
   standard HTTP request and response semantics while staying
   interoperable with intermediaries.  It introduces a Pricing response
   header field that communicates current pricing terms and an If-Price-
   LTE request header field that allows a client to declare a maximum
   acceptable price.

   When a request is served under such conditions, the response includes
   a Response-Id header identifying the served response context.  This
   identifier can be used for reconciliation, auditing, and downstream
   usage reporting.

   This specification defines access condition signaling only.
   Accounting and usage reporting may be implemented using a companion
   protocol such as usage-log.

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 18 September 2026.



Dierken                 Expires 18 September 2026               [Page 1]

Internet-Draft         Conditional Access for HTTP            March 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.  Code Components
   extracted from this document must include Revised BSD License text as
   described in Section 4.e of the Trust Legal Provisions and are
   provided without warranty as described in the Revised BSD License.

Table of Contents

   1.  Status of This Memo . . . . . . . . . . . . . . . . . . . . .   2
   2.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
   3.  Representation Lifecycle  . . . . . . . . . . . . . . . . . .   4
   4.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   4
   5.  Protocol Overview . . . . . . . . . . . . . . . . . . . . . .   4
   6.  Price Discovery . . . . . . . . . . . . . . . . . . . . . . .   5
     6.1.  Price Quote Metadata  . . . . . . . . . . . . . . . . . .   5
   7.  Conditional Access Request  . . . . . . . . . . . . . . . . .   6
   8.  Pricing Header  . . . . . . . . . . . . . . . . . . . . . . .   7
   9.  Price Quote Stability . . . . . . . . . . . . . . . . . . . .   7
   10. Response Identifier . . . . . . . . . . . . . . . . . . . . .   8
   11. Pricing Units . . . . . . . . . . . . . . . . . . . . . . . .   8
   12. Response Semantics  . . . . . . . . . . . . . . . . . . . . .   8
   13. Authentication  . . . . . . . . . . . . . . . . . . . . . . .   9
   14. Interaction with Caching  . . . . . . . . . . . . . . . . . .   9
   15. Relationship to Usage Reporting . . . . . . . . . . . . . . .   9
   16. Security Considerations . . . . . . . . . . . . . . . . . . .  10
   17. Privacy Considerations  . . . . . . . . . . . . . . . . . . .  10
   18. IANA Considerations . . . . . . . . . . . . . . . . . . . . .  10

1.  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).








Dierken                 Expires 18 September 2026               [Page 2]

Internet-Draft         Conditional Access for HTTP            March 2026


2.  Introduction

   HTTP provides mechanisms for conditional requests and access control,
   including authentication, authorization, rate limiting, and
   representation-state preconditions.  These mechanisms allow servers
   to express conditions based on identity, resource state, or server
   capacity.  However, HTTP does not currently provide a standardized
   mechanism for expressing economic or policy conditions under which a
   resource may be served.  This specification introduces such a
   mechanism while remaining compatible with existing HTTP conditional
   request semantics.

   Many web resources today are accessed under conditions such as:

   *  usage pricing

   *  quota limits

   *  licensing terms

   *  contractual access policies

   Historically, these conditions have often been implemented using
   JavaScript or proprietary APIs layered above HTTP.  This approach
   works well for browsers but creates interoperability problems for
   automated clients and intermediaries that interact directly with HTTP
   semantics.

   Automation systems, APIs, and AI agents increasingly retrieve web
   content without executing JavaScript.  In such environments, access
   conditions implemented through client-side code cannot be reliably
   expressed or enforced.

   This document defines a protocol mechanism that allows an origin
   server to explicitly communicate access conditions using HTTP
   metadata.  Clients can then declare the conditions under which they
   are willing to receive the resource.

   This mechanism restores capabilities historically implemented through
   JavaScript paywalls and tracking pixels into explicit HTTP protocol
   semantics suitable for automated clients and intermediaries.

   Access conditions may be dynamic and may vary across time, identity,
   or other policy factors.  Because the Pricing field explicitly
   communicates the minimum acceptable price, clients typically have
   little incentive to probe for lower prices.  However, clients may
   issue repeated requests to observe changes in pricing across time,
   identities, or other request characteristics.  This specification



Dierken                 Expires 18 September 2026               [Page 3]

Internet-Draft         Conditional Access for HTTP            March 2026


   therefore allows servers to publish stability metadata such as
   valid_until and next_floor while still enabling efficient price
   discovery.

3.  Representation Lifecycle

   Conditional access introduces a lifecycle for served representations:

   1.  Access conditions are communicated.

   2.  The client declares acceptable conditions.

   3.  The origin serves the representation if conditions are satisfied.

   4.  The served response receives a durable identifier.

   The identifier allows the served response to be referenced later for
   purposes such as:

   *  auditing and reconciliation

   *  operational diagnostics

   *  downstream usage reporting

   A separate protocol may be used to report downstream usage, which is
   particularly applicable to cached representations.

4.  Terminology

   Origin  The server hosting the resource.

   Client  A software agent requesting the resource.

   Access Conditions  Constraints under which the origin is willing to
      serve a representation.

   Response Context  The specific instance of a response served by the
      origin.

5.  Protocol Overview

   This specification introduces two HTTP header fields:

   *  Pricing

   *  If-Price-LTE




Dierken                 Expires 18 September 2026               [Page 4]

Internet-Draft         Conditional Access for HTTP            March 2026


   It also defines the Response-Id response header used to identify
   served responses.

   A typical interaction proceeds as follows:

   1.  A client requests a resource.

   2.  The origin communicates current access conditions.

   3.  The client declares acceptable conditions.

   4.  The origin serves the resource if conditions are satisfied.

6.  Price Discovery

   A client may request a resource without declaring an acceptable
   price.

   Example:

   GET /resource HTTP/1.1
   Host: example.com
   Authorization: Bearer agt_XYZ

   If the resource requires payment or another access condition, the
   origin may respond:

   HTTP/1.1 402 Payment Required
   Pricing: floor=0.02, valid_until=@1743595200, next_floor=0.05, effective=@1743552000, currency="USD", unit="request"

   The Pricing field communicates a price quote for accessing the
   resource.  A quote may include the current minimum acceptable price
   (floor) as well as additional metadata describing the stability or
   evolution of that price.

6.1.  Price Quote Metadata

   Servers MAY include additional metadata describing the stability and
   evolution of pricing conditions.  These fields allow clients to make
   informed decisions and to understand when pricing is expected to
   remain stable or change.

   floor  The minimum acceptable price at the time the response is
      generated.

   valid_until  Timestamp indicating how long the current price quote is
      expected to remain valid.




Dierken                 Expires 18 September 2026               [Page 5]

Internet-Draft         Conditional Access for HTTP            March 2026


   next_floor  Indicates the minimum acceptable price that will apply
      after the next scheduled price change.

   effective  Timestamp indicating when next_floor becomes active.

   Together, these members describe the lifecycle of a price quote.  The
   current quote applies when the response is generated.  When
   next_floor and effective are present, they describe the next
   scheduled pricing change.  When valid_until is present, it indicates
   how long the current quote is expected to remain stable.

   Servers SHOULD ensure that valid_until intervals are long enough to
   provide useful stability information and reduce unnecessary repeated
   requests.

   Example:

   HTTP/1.1 402 Payment Required
   Pricing: floor=0.02, valid_until=@1743595200, next_floor=0.05, effective=@1743552000, currency="USD", unit="request"

   This response indicates that the current floor price is 0.02.  After
   the effective time, the minimum acceptable price will be at least
   0.05.

7.  Conditional Access Request

   A client may include a constraint declaring the maximum acceptable
   price.

   Example:

   GET /resource HTTP/1.1
   Host: example.com
   Authorization: Bearer agt_XYZ
   If-Price-LTE: 0.03; currency=USD; unit=request

   If the constraint is satisfied, the origin may serve the response.

   HTTP/1.1 200 OK
   Pricing: applied=0.02, currency="USD", unit="request"
   Response-Id: resp_82fd

   If the constraint is not satisfied:

   HTTP/1.1 402 Payment Required
   Pricing: floor=0.05, currency="USD", unit="request"





Dierken                 Expires 18 September 2026               [Page 6]

Internet-Draft         Conditional Access for HTTP            March 2026


   When price quote metadata such as valid_until is present, clients
   should treat the quote as stable within that interval and can use
   that metadata to avoid unnecessary repeated requests made only to
   observe whether pricing has changed.

8.  Pricing Header

   Pricing communicates pricing conditions and related quote metadata
   for the resource.

   The field value is an RFC 8941 Structured Field Dictionary.

   Example:

   Pricing: floor=0.02, currency="USD", unit="request"

   Possible members include:

   floor  minimum acceptable price

   valid_until  Timestamp indicating how long the current price quote is
      expected to remain valid.

   next_floor  Indicates the minimum acceptable price that will apply
      after the next scheduled price change.

   effective  Timestamp indicating when next_floor becomes active.

   applied  price applied to a served response

   currency  ISO-4217 currency

   unit  normalization unit

   The applied member MUST appear when the resource is served under
   conditional access.

   The applied member MUST NOT appear in responses that do not serve the
   resource.

9.  Price Quote Stability

   Because the Pricing field explicitly communicates the minimum
   acceptable price (floor), clients typically have little incentive to
   probe for lower prices.  However, clients may issue repeated requests
   to observe changes in pricing across time, identities, or other
   request characteristics.  Servers concerned about such behavior may
   publish stability metadata such as valid_until or next_floor.



Dierken                 Expires 18 September 2026               [Page 7]

Internet-Draft         Conditional Access for HTTP            March 2026


10.  Response Identifier

   Response-Id identifies the origin-served response context.

   Example:

   Response-Id: resp_7Y2f

   The identifier is opaque to clients.

   A Response-Id value is assigned by the origin and MUST uniquely
   identify the served response context.

   Servers SHOULD include a Response-Id when serving a response under
   conditional access.

   The identifier can be used for:

   *  auditing

   *  reconciliation

   *  downstream usage reporting

11.  Pricing Units

   This specification defines two units:

   request
   cpm

   cpm represents price per 1000 requests.

   Servers MUST normalize units when evaluating If-Price-LTE.

12.  Response Semantics

   200  resource served

   402  price constraint not satisfied

   403  access disallowed

   429  rate limited







Dierken                 Expires 18 September 2026               [Page 8]

Internet-Draft         Conditional Access for HTTP            March 2026


13.  Authentication

   Conditional access based on economic or policy conditions typically
   requires identifying the client.

   Authentication mechanisms may include:

   *  OAuth bearer tokens

   *  mutual TLS

   *  other HTTP authentication schemes

   The authentication method is outside the scope of this specification.

14.  Interaction with Caching

   Served responses may be cached according to normal HTTP semantics.

   Cached representations may later be used without contacting the
   origin.

   A Response-Id allows the served response context to be referenced by
   downstream usage reporting mechanisms when such reporting is
   implemented.

   Pricing metadata such as valid_until, floor, or next_floor describes
   the server's view of pricing conditions at the time the response was
   generated.  These fields do not modify HTTP caching semantics.
   Intermediaries and caches MUST continue to follow standard HTTP
   caching rules when determining response freshness.

15.  Relationship to Usage Reporting

   Conditional access defines the terms under which a representation may
   be served.

   In deployments where cached representations are reused without
   contacting the origin, accounting may require reporting downstream
   usage.

   The pricing terms defined by this specification apply only to
   conditional access to a representation.  They do not define or
   constrain any separate conditions that may apply to downstream usage
   of a served or cached representation.  Any such usage policies are
   outside the scope of this specification.





Dierken                 Expires 18 September 2026               [Page 9]

Internet-Draft         Conditional Access for HTTP            March 2026


   Such reporting can be implemented using a companion protocol such as
   usage-log.

   Usage reporting mechanisms are outside the scope of this
   specification.

16.  Security Considerations

   Origins should authenticate clients before serving resources under
   conditional access.

17.  Privacy Considerations

   Conditional access mechanisms operate at the client or operator level
   and do not require identifying individual end users.

   Deployments should avoid including user-level identifiers in access
   metadata unless required for the application.

18.  IANA Considerations

   This document requests registration of the following HTTP header
   fields:

   *  Pricing

   *  If-Price-LTE

   *  Response-Id






















Dierken                 Expires 18 September 2026              [Page 10]
