Hi Mario, On 17.03.26 15:20, Mario Loffredo wrote:
[PK] My point was not about proving which one is better. Just the statement was not correct about usage of JWTs, that's all. I agree with all you say and the operator of RPP server would have to make some choices and take trade-offs. I think only non-negotiable factor written down in requirements is that RPP must remain stateless.Hi Pawel, see my comments inline. Il 17/03/2026 12:25, Pawel Kowalik ha scritto:[ML] It's true but with two drawbacks. A JWT once created remain valid until its expiration time, making them vulnerable to misuse if stolen, even after a user logs out. Security risks persist throughout their lifespan. Therefore, in order to mitigate these risks, it's crucial to finda good compromise between the lifetime of a JWT and a sustainable rate of requests.Hi Mario, On 17.03.26 12:06, Mario Loffredo wrote: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.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.Briefly, JWT works well in distributed systems, but it introduces new risks compared to session-based models, especially around token leakage and revocation.Security concerns related to JWT are also mitigated by the nature of the REST service. This is why I'm in favor of using JWT in RDAP but I see more disadvantages in using them in a provisioning protocol.To be clear, I'm not saying JWTs shouldn't be used, but I'm showing the pros and cons of using them.The other disadvantage is the additional effort required for clients to manage tokens in general, compared to HTTP sessions. Clients must register with the authentication server, access the token endpoint, obtain the token, and store and refresh it unless they want to request a new one for each request.
[PK] ok, if this is all embedded in the cookie (+ some client identification) and the cookie does not change during the session then server may not need to keep track of open sessions.Managing an HTTP session is much less complex than managing a JWT.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.[ML] The information stored in the EPP session is basically that negotiated at the time of EPP Login and remains immutable for the duration of the session.- An <options> element that contains the following child elements: - A <version> element that contains the protocol version to be used for the command or ongoing server session. - A <lang> element that contains the text response language to be used for the command or ongoing server session commands. The values of the <version> and <lang> elements MUST exactly match one of the values presented in the EPP greeting. - A <svcs> element that contains one or more <objURI> elements that contain namespace URIs representing the objects to be managed during the session. The <svcs> element MAY contain an OPTIONAL <svcExtension> element that contains one or more <extURI> elements that identify object extensions to be used during the session.
But, same time would it be the client who assures order of request processing? The "HTTP transport" cannot assure that any more, because parallel requests with the same cookie will be still legit.
Kind Regards, Pawel
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ regext mailing list -- [email protected] To unsubscribe send an email to [email protected]
