pawel-kow
commented
5 months ago 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
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)