REPP support for stateful EPP?

[mwullink]

To help convince the EPP purists, we could look into keeping EPP stateful, the REST/HTTP layer would still be stateless.

The EPP applciation state would have to be kept by the client and NOT the server, maybe we can use JWT to encode the (limited) state that is required for an EPP session?
The EPP RFC5730 says nothing about where the state should be kept, so keeping it on the client would not be a problem.

What information is stored in an EPP session anyway?

The client could do a Login request (POST /login) and the response would be a standard greeting AND a JWT (HTTP header) the JWT would have to be sent to the server for each following request.

There is no way to invalidate a JWT, we just need recommend a sensible lifetime for it and the client must do a login again when the JWT is expired. ( Kind of an auto logout function)

[pawel-kow]

Yes, this approach is doable, however not sure if this is not too much fitting a square peg into a round hole. There is some benefit of it that after /login the session context will be fix to the extensions in use. On the other end this was kind of interesting property of original REPP to be able to send each request with the extension set needed in the context by setting REPP-Svcs header. Not sure if super useful but I may imagine use-cases where this might be useful.

To the proposal:
Does it actually matter whether it is JWT or not? I guess this can be just any opaque value and it is an implementation detail of the server whether it is JWT. Kind alike any OAuth token.
Not sure if there are standard HTTP headers to pass on an authorization token with a response. Maybe the standard mechanism of cookies would fit better?

[mwullink]

The reason why i'm asking the question, is because 1 of the main sticking points for the EPP folks seems to be that we change EPP from stateful to stateless. if we can convince them that EPP can remain stateful, then this might make it easier to get them to go along.

I figured a JWT would be perfect for the job of storing the application state because the JWT is designed to transmit information and authorization in a secure manner and they are easy to implement. we could use the JWT claims for static EPP session values that form the application state. The JWT is sent using the standard HTTP "Authorization" header.

What state does a EPP session normally keep anyway? besides the client session id, maybe the language?
the other stuff from the Login command does need to be saved in the session, the extensions used only need to be checked during login to see if they are supported.
https://datatracker.ietf.org/doc/html/rfc5730.html#section-2.9.1.1

Maybe cookies could also be an option, the main thing is that the state MUST be kept on the client side.

[pawel-kow]

I think there is a list of issues that would pose an incompatibility to EPP:

• session management and login/logout incl. extension negotiation
• XML representation for queries. Especially for GET requests using body is really not recommended if you want to stick to EPP in all request types
  • a part of this problem would be moving part of the requests to headers
  • ... and the redundancy of the data between the body and the headers and resource path
• other media types like JSON

If you remove all this issues you will end up with Mario's proposal EPP over HTTP. So the real question is whether this is the goal of REPP.

And back to this issue - JWT can be a technical implementation, but the client does not need to interpret or introspect it in any way (it's issued by the server and processed by the server) so on the protocol level it can be opaque IMHO.

[mwullink]

Let’s discuss this during the CENTR Jamboree in Copenhagen Op 15 mei 2024, om 13:32 heeft Pawel Kowalik ***@***.***> het volgende geschreven: I think there is a list of issues that would pose an incompatibility to EPP: * session management and login/logout incl. extension negotiation * XML representation for queries. Especially for GET requests using body is really not recommended if you want to stick to EPP in all request types * a part of this problem would be moving part of the requests to headers * ... and the redundancy of the data between the body and the headers and resource path * other media types like JSON If you remove all this issues you will end up with Mario's proposal EPP over HTTP. So the real question is whether this is the goal of REPP. And back to this issue - JWT can be a technical implementation, but the client does not need to interpret or introspect it in any way (it's issued by the server and processed by the server) so on the protocol level it can be opaque IMHO. — Reply to this email directly, view it on GitHub<#56 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AALSFIAJ7D73P4LV4UCTHA3ZCNBUDAVCNFSM6AAAAABHAB6FNCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCMJSGI4DKOJTGI>. You are receiving this because you authored the thread.Message ID: ***@***.***>