Probably this is just me, but I found it useful to see the calendar in my own time zone.
Here is the
link with the time zone set to USA EDT.
You can edit the value of the
ctz query parameter accordingly.
Ed
| edburns@xxxxxxxxxxxxx | office: +1 954 727 1095
| Calendar Booking:
https://aka.ms/meetedburns
|
| Please don't feel obliged to read or reply to this e-mail outside
| of your normal working hours.
|
| Reply anonymously to this email: https://purl.oclc.org/NET/edburns/contact
From: 'Emily Jiang' via MicroProfile <microprofile@xxxxxxxxxxxxxxxx>
Sent: Monday, September 11, 2023 2:57 PM
To: microprofile@xxxxxxxxxxxxxxxx; EE4J Security project <jakarta-security-dev@xxxxxxxxxxx>
Subject: [EXTERNAL] Re: [microprofile] Re: [jakarta-security-dev] Jakarta Security and MicroProfile JWT interlock call
Great news! The new
repo jwtBridge has been created. The next step is to start contributing. Please join the MP JWT bi-weekly call from this week to collaborate. You can find the full details for the meeting
here.
Tomorrow will be the final interlock call to finish off the last piece and provide a quick update on where we are at. Please make every effort to attend. Here are the
minute, in which you can add any agenda items.
The meeting details can be found
here.
Thanks for letting me know, Ondro! No worries. Here are the
minutes. We are having a finalish call on 20th July to discuss the last-minute questions.
Hi Emily, nobody from OmniFish could make it today, I’m sorry.
A quick reminder on the interlock call of Jakarta Security and MP JWT in 30 minutes. Hopefully this will be the last call and we will create a Creation Plan next week. Please try your best to attend. Below are the joining details! Thank
you! I have put all of the materials in the
MicroProfile sandbox as promised in the last meeting.
Microprofile Meeting is inviting you to a scheduled Zoom meeting.
Join Zoom Meeting
https://eclipse.zoom.us/j/85366098724
Meeting ID: 853 6609 8724
Minutes
here
---
One tap mobile
+17193594580,,85366098724# US
+12532050468,,85366098724# US
---
Dial by your location
• +1 719 359 4580 US
• +1 253 205 0468 US
• +1 253 215 8782 US (Tacoma)
• +1 301 715 8592 US (Washington DC)
• +1 305 224 1968 US
• +1 309 205 3325 US
• +1 312 626 6799 US (Chicago)
• +1 346 248 7799 US (Houston)
• +1 360 209 5623 US
• +1 386 347 5053 US
• +1 507 473 4847 US
• +1 564 217 2000 US
• +1 646 876 9923 US (New York)
• +1 646 931 3860 US
• +1 669 444 9171 US
• +1 669 900 6833 US (San Jose)
• +1 689 278 1000 US
Meeting ID: 853 6609 8724
Find your local number:
https://eclipse.zoom.us/u/ke7E0lqJp
A quick reminder for today's meeting on Jakarta Security and MP JWT: The agenda is to discuss the proposal mentioned in the
minute.
Thanks for providing the feedback! Ondro, based on my understanding, your assumption were correct. Logically speaking, it makes more sense for the bridge spec resides in Jakarta EE as it is a kind of addendum for Jakarta Security, which
Arjan is also advocating for. I am fine for it to be in MicroProfile as well. I don't think it matters too much.
In the next call, we will agree on the content of the bridge spec. We can also discuss your suggestion of putting it into Jakarta Security. I think some people have concerns of circular dependency. However, if we lock down the part of
MP JWT (pretty much the concept), it might not be a problem.
I think you mean something like
securityContext.getPrincipalsByType(JsonWebToken.class)
You are right, this would be better to specify in a spec that is on top of both specs. And I realized there are more things like that, e.g. the mapping between properties of @JwtAuthenticationMechanismDefinition and MP config properties.
In my proposal I assumed these would be implicitly provided by implementors but it's better to specify this in a spec.
However, I still think that it might be worthy adding @JwtAuthenticationMechanismDefinition to the Security Spec, because it's not related to MicroProfile. In the Security spec, it wouldn't define any mapping between annotation properties
and MP config values, although the Security spec would keep MP config values in mind when designing the API. The format of the JWT, validation and handling of the JWT would be left intentionally unspecified, so that they can be specified in the bridge spec.
I admit this would be a little more complicated but it would allow adding some JWT support to pure Jakarta EE without any MP specs.
I'm not sure whether it's worth it though, just an idea. There are probably very few Jakarta EE implementations which wouldn't want to implement MP JWT and the bridge spec. What do others think?
On Sunday, May 14, 2023 at 6:02:56 PM UTC+2 Siarhei Biarozkin wrote:
I'm sorry I couldn't attend the call, I was unexpectedly travelling on Thursday.
I read the google doc with the draft and I have a few thoughts. I understand the following, please correct me if I'm wrong:
-
The new bridge spec would introduce @JwtAuthenticationMechanismDefinition. This annotation doesn't make much sense with Microprofile JWT and would be ignored in a pure MicroProfile runtime. It would only work in a Jakarta EE runtime, right?
-
No other APIs would be defined by the bridge spec
-
The bridge spec would define that runtimes must comply with some non-API parts of MicroProfile JWT spec
-
The bridge spec defines accessing claims via Jakarta SecurityContext, which again makes sense only in a Jakarta EE runtime, not in a pure MicroProfile runtime
If all above is correct, then I have an idea to simplify all of this:
-
The bridge spec would be actually a subset of MP JWT and Jakarta Security
-
The part of the MicroProfile JWT spec, which the proposal refers to, would be moved to this new bridge spec
-
The parts related to Jakarta Security would be added to the Jakarta Security spec directly
-
Both Jakarta Security and MicroProfile JWT would depend on this bridge spec, which specifies a common format of the JWT, validation and handling of the JWT
As a result, the spec would reside in Jakarta EE and it would define basically only the common format of the JWT, validation and handling of the JWT. Jakarta Security would define @JwtAuthenticationMechanismDefinition and injecting claims
on top of it. MicroProfile JWT would define JsonWebToken on top of it
Do you mean Jakarta Security users will have no way to work directly with the token representation ?
Individual claim injection can work for sure, but can be limiting...
and means of configuration using Microprofile Config.
If we'd like to make it even simpler, the whole bridge spec could be part of Jakarta Security, which would define it as a profile or a subspec. Then MicroProfiel would require only this profile/subspec of Jakarta Security.
I'm proposing this with the assumption that the format of the JWT, validation and handling of the JWT is already pretty stable in MicroProfile JWT and it would rarely or never need to be updated. Then it doesn't matter if it stays in MP
JWT or in Jakarta EE and it would greatly simplify the solution for Jakarta Security and MicroProfile JWT interlock.
Further to today's call, I have started a
googledoc to draft the proposal that we are going to either submit to Jakarta EE or MP. Please directly comment on the proposal and we will iterate on it. We will try to finalise the proposal in the next call and start the specification.
A quick reminder to say the upcoming call is today at 4:00pm BST time. Hope to see you there!
Today we had another call to discuss this topic further. Since the time slot is too early for US folks, the attendance was quite low. Please see our discussion in
the minutes and the recording will be added to the minutes soon. Please add your comments either on this list or on the doc. We discussed the future call time and agreed to delay the call for 2 hours so that more people can join next time. The next call
will be at 11th May 16:00BST and then occur every other week due to travelling and meeting clashes. I will send a reminder email when the time is closer. Please let me know if you have any questions/or concerns.
As promised, I have scheduled a few weekly calls for this topic. The joining details can be found
here (please see the meetings on Thursdays). The meeting will start on 20th April 2:00pm UK time.
Thank you all for attending today's meeting and contributing your thoughts! We had a very productive conversation with the agreed mission to solve.The minutes can be accessed
here. Please add your comments on the doc especially if you could not attend today's call. The link to the recording can be found from the minutes. We will have a few regular subsequent calls after we have all got into summer time saving mode.
In the meantime, please discuss this on this thread or on the
minute doc.
Thank you to the ones who registered your availability! The most voted slot is Wednesday 15th March 5:00-6:00pm GMT. I have created a meeting invitation on the MicroProfile calendar
here. The call will be recorded and the recording will be made available in due course.
We discussed the topic of "Jakarta Security and MicroProfile JWT" in various threads. You can read some discussion
here.
I would like to volunteer to move this issue forward via chairing some calls to discuss the technical solutions for this issue. I have created
this doodle pool for anyone who is interested in the discussion of
the issue where Jakarta security uses MicroProfile JWT. We had some internal conversations in IBM and will present a couple of options to this issue and would like to hear some feedback
from you. Please register your interest and availability so that I can schedule a call accordingly.
--
--
--
--
--
--
--
_______________________________________________
jakarta-security-dev mailing list
jakarta-se...@xxxxxxxxxxx
To unsubscribe from this list, visit
https://accounts.eclipse.org
--
You received this message because you are subscribed to a topic in the Google Groups "MicroProfile" group.
To unsubscribe from this topic, visit
https://groups.google.com/d/topic/microprofile/5VNyxjhHTbA/unsubscribe.
To unsubscribe from this group and all its topics, send an email to
microprofile+unsubscribe@xxxxxxxxxxxxxxxx.
To view this discussion on the web visit
https://groups.google.com/d/msgid/microprofile/8ecf739d-3276-48bf-ab0e-d35c562708dfn%40googlegroups.com.
--
--
--
You received this message because you are subscribed to a topic in the Google Groups "MicroProfile" group.
To unsubscribe from this topic, visit
https://groups.google.com/d/topic/microprofile/KFL6a72bcSk/unsubscribe.
To unsubscribe from this group and all its topics, send an email to
microprofile+unsubscribe@xxxxxxxxxxxxxxxx.
To view this discussion on the web visit
https://groups.google.com/d/msgid/microprofile/CAECq3A-%3DqWvZt94q8aLyZTDNHLwh06jQDjRJZ1pghx8Zq7UBnw%40mail.gmail.com.
--
You received this message because you are subscribed to the Google Groups "MicroProfile" group.
To unsubscribe from this group and stop receiving emails from it, send an email to
microprofile+unsubscribe@xxxxxxxxxxxxxxxx.
To view this discussion on the web visit
https://groups.google.com/d/msgid/microprofile/CACZTZYUHx%3D8jazeH_4XPMFL1ZoWjtoTBjftw%3Dnbx0r-7uw9jSQ%40mail.gmail.com.
--
--
--
--
You received this message because you are subscribed to the Google Groups "MicroProfile" group.
To unsubscribe from this group and stop receiving emails from it, send an email to
microprofile+unsubscribe@xxxxxxxxxxxxxxxx.
To view this discussion on the web visit
https://groups.google.com/d/msgid/microprofile/CAECq3A_VPcRutsBs16f5AYgysseDWiJ6WYfofSDEyXkEPuCYEA%40mail.gmail.com.
|
