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 Jakarta Security?

I'd like to also add that in the 6 years MicroProfile has existed it has never moved, copied or duplicated anything in Java EE or Jakarta EE.  It's always been understood as a bad idea.  And when a specification that was discussed as a good addition to MicroProfile shows up as a proposal to Jakarta, the MicroProfile community has generally accepted it and not pushed the spec forward in MicroProfile.

The reason is that it's critical we can implement both in the same box, we don't want to create complexity for users or implementors and do not want situations where MicroProfile and Jakarta are perceived as competing.

If you see them as one big community and are happy to contribute to them both, I find it brings me some peace.  Things don't always end up where I want them, but I remind myself to be happy that they will at least exist, we're still making good progress and nothing but me is stopping me from being excited to work on it.


-- 
David Blevins
http://twitter.com/dblevins
http://www.tomitribe.com

> On Nov 10, 2022, at 10:42 AM, David Blevins <dblevins@xxxxxxxxxxxxx> wrote:
> 
> +1
> 
> -- 
> David Blevins
> http://twitter.com/dblevins
> http://www.tomitribe.com
> 
>> On Nov 10, 2022, at 10:29 AM, John Clingan <jclingan@xxxxxxxxxx> wrote:
>> 
>> I’m inserting this as a general  point in this discussion,  which is related to joining the MP JWT call.
>> 
>> There are non-technical reasons MicroProfile exists. MicroProfile is a flatter working group with fewer processes, somewhat different values (like backwards compatibility differences), releases more often, and  is $250,000 USD cheaper *annually* (for large organizations) than joining Jakarta EE Working Group as a strategic member. Whenever talk of moving a specification to Jakarta, I feel the need to remind folks of the non-technical differences between Jakarta and MicroProfile.
>> 
>> For these reasons, I am against moving *any* specifications out of MicroProfile to Jakarta, although I am open to the idea of moving Jakarta specifications to MicroProfile. The exception is concurrency, which was always intended to move to Jakarta.
>> 
>> My two cents.
>> 
>>> On Nov 9, 2022, at 9:52 AM, David Blevins <dblevins@xxxxxxxxxxxxx> wrote:
>>> 
>>>> On Nov 9, 2022, at 6:31 AM, arjan tijms <arjan.tijms@xxxxxxxxx> wrote:
>>>> 
>>>> Hi,
>>>> 
>>>> On Tue, Nov 8, 2022 at 9:55 PM David Blevins <dblevins@xxxxxxxxxxxxx> wrote:
>>>> MP JWT does define bindings for EJB, Servlets, JACC, JASPIC, etc.
>>>> 
>>>> True, although essentially spelling out everything is unnecessary if one just says that MP JWT in a Jakarta EE environment is/exposes itself as an Jakarta Security Authentication Mechanism. All those other things then follow from that. Specifically this authentication mechanism bit is missing there. I do see identity store being mentioned, and perhaps it comes from the confusion that many people have between the concept of an authentication mechanism (FORM, BASIC, etc) and an identity store (DB, LDAP, FILE, etc). 
>>> 
>>> I'd be on board for making these kinds of changes and improvements in MP JWT.  The next version planned is 3.0, so we can even make breaking changes if we needed to accommodate.  The next MP JWT call is Thursday, November 17th at 8:00am Pacific.  Are you open to attending at least once and discussing?  Here's the call information:
>>> 
>>>  - https://calendar.google.com/calendar/u/0/embed?src=gbnbc373ga40n0tvbl88nkc3r4@xxxxxxxxxxxxxxxxxxxxxxxxx
>>>  
>>>> # Procedural
>>>> 
>>>> In CN4J we did agree to some technical principles.  One of them is that duplication should be avoided.
>>>> 
>>>> That is basically a good thing. The problem here is a little that MP JWT in a sense "hi-jacked" the JWT authentication mechanism from underneath Jakarta Security. Of course it's not that black and white in practice, and there were many valid arguments for MP to introduce JWT in the way it did. But the matter of fact remains that Jakarta Security planned for a number of authentication mechanisms that went beyond the ones provided by servlet, such as Open ID Connect (OAuth) and JWT. 
>>>> 
>>>> These didn't make it into 1.0, and because of the move to Eclipse the new features effort was stalled for years. In that timeframe JWT was introduced in MP. Currently Jakarta EE is open for new features again, but it finds some features are now "controversial" only because MP implemented them in the meantime. Again, there was no malintent (I was even part of the original MP JWT team then), but it's an unfortunate situation.
>>> 
>>> I do understand how things can feel that way from an emotional perspective.  My emotional perspective is that we're fortunate to have this conversation at all, because when MicroProfile and MP JWT were created Java EE was dead with no plans to continue.  I'm thankful and proud of MicroProfile for its impact on the decision to open source Java EE.  I'm happy that both Jakarta EE and MicroProfile now live at the Eclipse Foundation and are implemented side-by-side in most the major implementations.
>>> 
>>> Sure, we don't want duplication between specs, but we also don't want duplication between say two specs in Jakarta EE.  Compared to the challenges we've faced over the last 6 or 7 years, this feels very manageable.
>>> 
>>> 
>>> -David
>>> 
>>> _______________________________________________
>>> jakartaee-platform-dev mailing list
>>> jakartaee-platform-dev@xxxxxxxxxxx
>>> To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakartaee-platform-dev
>> 
>> _______________________________________________
>> jakartaee-platform-dev mailing list
>> jakartaee-platform-dev@xxxxxxxxxxx
>> To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakartaee-platform-dev
> 



Back to the top