Re: [jakartaee-platform-dev] Moving MicroProfile JWT to Jakarta Security

[arjan tijms <arjan.tijms@xxxxxxxxx>]

p.s.

Another alternative not mentioned yet is Jakarta Security just going ahead with its original plans and implementing a JWT authentication mechanism, simply ignoring there's already one in MP.

This too has a precedent already, with e.g. @Asynchronous, which is in MP, but was also added (again) in Jakarta EE, specifically Jakarta Concurrency.

Just like there is a duplicate specification of @Asynchronous, there would be a duplicate implementation of JWT. It's not ideal perhaps, and again (IMHO) a testimony to how unfortunate our process and EE/MP split is, but it might be a solution.

Kind regards,

Arjan Tijms

On Sun, Nov 6, 2022 at 4:50 PM arjan tijms <arjan.tijms@xxxxxxxxx> wrote:

Hi,

On Sun, Nov 6, 2022 at 2:30 PM Brian Stansberry <brian.stansberry@xxxxxxxxxx> wrote:

This seems like the crux of the issue. MP and the Jakarta Core Profile don't require Servlet, and there are implementations that don't see Servlet as something useful for them. We also have important implementers of Servlet who don't see EE Full Platform or Web Profile as useful for them. But EE has security specs that are tied to servlet.

Well, the question is, are they really tied to Servlet conceptually, or is it more of a belief?

The two SPIs which Jakarta Security uses for integration with a container (Jakarta Authentication and Jakarta Authorization), are those really tied to Servlet? Or do people just assume they are?

Jakarta Security itself has the HttpAuthenticationMechanism, which uses the HttpServletRequest and HttpServletResponse. As I've argued before, it's a truly sad state of affairs that in Jakarta EE (and Microprofile) we've come to have important vendors who don't see the most basic of basic things of the web (the request and the response of an HTTP request) as useful for them.

Kind regards,

Arjan Tijms