Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [jakartaee-platform-dev] Moving MicroProfile JWT to JakartaSecurity?

On Nov 9, 2022 at 3:15:53 PM, arjan tijms <arjan.tijms@xxxxxxxxx> wrote:

On Wed, Nov 9, 2022 at 9:50 PM Scott Stark <starksm64@xxxxxxxxx> wrote:
The only place the Jakarta API usage other than CDI shows up is in the org.eclipse.microprofile.jwt.tck.container.* package of the TCK tests. All of those other than org.eclipse.microprofile.jwt.tck.container.jaxrs.* could be moved to the Jakarta Security project in my view, as they stretch requirements for MP implementation to unused specs.

I don't see why the core API and spec cannot remain in MP and the security specs build on that.

More or less the same reason why we included say extensionless URLs in Faces, and didn't ask users to just use OmniFaces? There's a benefit to having JWT among the list of supported authentication mechanisms in the base spec instead of asking users to install an external library. In this case users would have to add an MP Config implementation and a Jakarta EE compatible MP JWT implementation to their wars. It's of course possible, but not ideal.

I don't see a problem here, or how that correlates with OmniFaces. There has to be some implementation library that will have dependencies. Most MP JWT implementations also depend on some other JWT parsing library that will also have to be included. The bigger issue will be how to deal with config once Jakarta config lands.

Also, what if it happened the other way around? What if MP wants to add an Open ID Connect authentication mechanism (which Jakarta EE already has)?

It would have to be in the core profile, and decomposable such that this did not pull in a requirement on servlet, ejb, etc.

In general Jakara needs to use better composition to allow for more layered usage, and EJB, Servlet and JAXRS related APIs need to be in separate artifacts.

I'm not sure about this. Aren't the EJB, Servlet and REST APIs not already separate artefacts? e.g.  

Yes, but the TCKs that pull them in are not broken up into:

And the TCKs associated with a project that already has this dependency. 

jakartaee-platform-dev mailing list
To unsubscribe from this list, visit

Back to the top