Investigate whether it makes sense to integrate with Bean Validation

[Emily-Jiang]

As part of the program plan 2021, the community would like to see some integration between JWT and Bean Validation. I think Spec and TCKs will need to be updated to ensure the two technologies work together.

[rdebusscher]

Can we first discuss the benefits and drawbacks of adding this to the spec and requiring that Bean Validation is added to MicroProfile? If we want that MicroProfile can easily be adopted by new implementations we should make it as easy as possible and thus do not require many specifications.

Also, when adding almost the entire Web profile stack of Jakarta EE, it is no longer lightweight and heavier than WebProfile itself.

The topics that are on the program plan are things we should look into, they are not decided since there was no discussion at all at that moment. And in one of the meetings, it was even indicated that they are topics for discussion for this year.

[Emily-Jiang]

Can we first discuss the benefits and drawbacks of adding this to the spec and requiring that Bean Validation is added to MicroProfile? If we want that MicroProfile can easily be adopted by new implementations we should make it as easy as possible and thus do not require many specifications.

Also, when adding almost the entire Web profile stack of Jakarta EE, it is no longer lightweight and heavier than WebProfile itself.

The topics that are on the program plan are things we should look into, they are not decided since there was no discussion at all at that moment. And in one of the meetings, it was even indicated that they are topics for discussion for this year.

@rdebusscher this issue is for conversation within JWT group. If it deems not useful, it is fine and we can just summarise why not.

[sberyozkin]

@Emily-Jiang

As part of the program plan 2021, the community would like to see some integration between JWT and Bean Validation.

First time I'm hearing about it - where it was proposed, what are the use cases ?
IMHO it is out of scope for MP JWT - the only angle is, at some point, hopefully in 2.0, we may support injecting complex claims as beans - but even if we do it - application of Bean Validation is orthogonal

[sberyozkin]

@Emily-Jiang, for example:

@Inject
JsonwebToken jwt;

Address address = jwt.getClaim("address", Address.class);

or, when talking about the bean validation:

@Claim(name="address")
@Inject
Address myAddress;

Now, here you can see it is not an MP-JWT concern - whose responsibility is to make sure the address claim is produced as Address - but Bean Validation constraints is something the user would apply independently - for ex to Address fields/methods and it is the job of the container which runs this endpoint to make sure BVal is applied upon the (request scoped) injection of Address

[rdebusscher]

To clarify the history behind the creation of this issue; It is indicated in the Program Plan that the Bean Validation could be interesting to add to a couple of specifications.

So this issue is created to gather some use cases where the usage of the Bean Validations annotations could be useful for this spec.

[Emily-Jiang]

@Emily-Jiang

As part of the program plan 2021, the community would like to see some integration between JWT and Bean Validation.

First time I'm hearing about it - where it was proposed, what are the use cases ?
IMHO it is out of scope for MP JWT - the only angle is, at some point, hopefully in 2.0, we may support injecting complex claims as beans - but even if we do it - application of Bean Validation is orthogonal

@sberyozkin this was raised on the 2021 MicroProfile Program Plan googledoc Question 1 - bulletin point 11. These input was then put to MicroProfile 2021 Program Plan Technical Goals.

As explained earlier, if this is not something we envisage with a valid and immediate use case, we can put this on hold or close this issue. These are all valid outcomes. I just want to start the conversation and then record in the program plan.

[sberyozkin]

@rdebusscher @Emily-Jiang Thanks for the clarification.
I can certainly imagine how Bean Validation can be usefully applied alongside MP-JWT in the MP platform where MP-JWT 2.0 would have an ability to inject claim objects other than JsonObject - but I'd be concerned about making it a direct dependency.
Example, I'd like to avoid something like If the claim is represented as a custom bean then the claim producer must run BVal on this object (or optionally run it if 'mp.jwt.bean-validation-enabled=true' is set). IMHO it would overload MP-JWT with the orthogonal concern not directly (fundamentally) related to MP-JWT.
However what I think this issue does help with is that it provides a very good reason for MP-JWT 2.0 to support the injection of custom claims as beans (plus updating JsonWebToken to have T <T> getClaim(String name, Class<T> claimClass)) - for the users to have an opportunity to transparently apply BVal to these beans should they wish to do it

[Emily-Jiang]

@rdebusscher @Emily-Jiang Thanks for the clarification.
I can certainly imagine how Bean Validation can be usefully applied alongside MP-JWT in the MP platform where MP-JWT 2.0 would have an ability to inject claim objects other than JsonObject - but I'd be concerned about making it a direct dependency.

However what I think this issue does help with is that it provides a very good reason for MP-JWT 2.0 to support the injection of custom claims as beans (plus updating JsonWebToken to have T <T> getClaim(String name, Class<T> claimClass)) - for the users to have an opportunity to transparently apply BVal to these beans should they wish to do it

ah, I see. The current valid claim types are

• java.lang.String
• java.lang.Long and long
• java.lang.Boolean and boolean
• java.util.Set<java.lang.String>
• javax.json.JsonValue.TRUE/FALSE
• javax.json.JsonString
• javax.json.JsonNumber
• javax.json.JsonArray
• javax.json.JsonObject
• java.util.Optional wrapper of the above types.
• org.eclipse.microprofile.jwt.ClaimValue wrapper of the above types.

With what you propopsed, it could be any type. Right? If so, can you raise an issue and target for 2.0?

[sberyozkin]

@Emily-Jiang Exactly, #100 was the main issue opened by the user awhile back where we started narrowing down on a possible solution. I guess It would indeed make sense to open a more concrete issue - will do soon, thanks