Pawel, I wouldn’t intermingle the use of JWT and the stateless behavior of RPP with the use of sticky HTTP sessions to maintain a stateful EoH connection that is required to support the stateful EPP application protocol. Based on the discussion with Maarten, we need to update the draft to clearly define the EoH connection versus a HTTP connection, where the HTTP connection is transient and the EoH connection is a logical connection maintained via the HTTP session. The equivalent of a physical EoT connection is the logical EoH connection, and the physical EoQ connection represented by a QUIC stream.
The concept of an EPP connection (EoT, EoH, and EoQ) directly relates to the EPP state machine in returning the EPP greeting, with support for the server side managed timeouts (e.g., idle, absolute), and support for the EPP command and response flow that includes the EPP <login> to establish an EPP session (EoT, EoH, EoQ). The HTTP session could target an individual HTTP server, or the server implementation may implement HTTP clustering, where state is replicated / stored to handle failures of an individual HTTP server. HTTP clustering may be overkill, since EoT doesn’t include clustering support, where when an individual server fails, the client will establish a new session that can be fully automated with the use of a session pool on the client side. -- JG [cid87442*[email protected]] James Gould Fellow Engineer [email protected]<applewebdata://13890C55-AAE8-4BF3-A6CE-B4BA42740803/[email protected]> 703-948-3271 12061 Bluemont Way Reston, VA 20190 Verisign.com<http://verisigninc.com/> From: Pawel Kowalik <[email protected]> Date: Tuesday, March 17, 2026 at 7:25 AM To: Mario Loffredo <[email protected]>, Maarten Wullink <[email protected]>, James Gould <[email protected]>, "[email protected]" <[email protected]> Subject: [EXTERNAL] Re: [regext] Re: draft-ietf-regext-epp-https-02 early Httpdir review Hi Mario, On 17.03.26 12:06, Mario Loffredo wrote: However, the risk of managing too many sessions or maintaining unused sessions is common to all mechanisms based on server-generated secrets to prevent clients from authenticating on every request. To be clear, EoH sessions = RPP JWTs. The mitigation measures are the same: limit the number of simultaneously active secrets and optimize secret lifetime. This is only true if the tokens are persisted. This must be true for opaque tokens, but is not true most of cases for rfc7523 JWT tokens. These tokens are self-carrying and only resource which can be exhausted is the token endpoint itself. A sane OAuth2 server will rate limit token generation per client to prevent that. For http sessions is different, as usually some server-side resources are created to manage the session. There are solutions that carry the same properties as JWT tokens, where cookies are basically encrypted tokens with full state of the session (and nothing on the server), but I don't know how applicable it is to EoH. If the session state may change during the session, then strict ordering of the requests is required to prevent stale session cookie usage. Kind Regards, Pawel
_______________________________________________ regext mailing list -- [email protected] To unsubscribe send an email to [email protected]
