I tried out the MP-JWT 2.1 RC3 TCK today and there are just two more test failures and three new configuration flags:
- `mp.jwt.decrypt.key.algorithm` property for supporting an RSA-OAEP-256 key management algorithm has been introduced. - `mp.jwt.verify.token.age` property for restricting a token age has been introduced. - `mp.jwt.verify.clock.skew` property for configuring a leeway for the token expiry and age verification has been introduced. My disagreement is with how `mp.jwt.decrypt.key.algorithm` has been defined. The configuration flag allows the user to specify the exact algorithm they want supported for decrypting encrypted JWTs. Having a flag users can set is great. No disagreement there. The disagreement is with the proposed handling of defaults for that setting. The draft spec says there's a default value of RSA-OAEP and that we must reject requests that have the stronger RSA-OAEP-256 encryption. Further that the default will change to RSA-OAEP-256 in MP JWT 3.0 and then we'll have to reject JWTs with RSA-OAEP by default. The issues I see with this: - MP JWT 2.0 required RSA-OAEP support, but implementors could support more. We support RSA-OAEP-256, RSA-OAEP-384 RSA-OAEP-512 and RSA-OAEP out of the box with no config. - MP JWT 2.1 RC3 basically says we're not allowed to support RSA-OAEP-256 encryption out of the box with no config. Applications that may have worked successfully on MP JWT 2.0 leveraging RSA-OAEP-256, RSA-OAEP-384 or RSA-OAEP-512 must now fail until the user adds the new flag. - MP JWT 3.0 is "planned" to change the default from RSA-OAEP to RSA-OAEP-256. This means MP JWT 2.1 applications that use out of the box settings are again required to break on upgrade. It's the continuous breaking of applications that I'm not fond of. There should be a flag. There should be a set of algorithms that must be standardly supported by an MP JWT impl. However the default when users do not use the flag should allow vendors to support the stronger RSA-OAEP-256, RSA-OAEP-384, and RSA-OAEP-512. Our implementation does this and ideally we can leave it that way. I'll implement the `mp.jwt.decrypt.key.algorithm` configuration flag so that when set it will reject tokens that use a different algorithm, but by default will allow the required RSA-OAEP plus the much better RSA-OAEP-256, RSA-OAEP-384, and RSA-OAEP-512 (as it does now). I'll be creating a PR for the spec and TCK and bring it up for discussion over on the MP JWT side of things. -David > On Sep 9, 2022, at 11:54 PM, Richard Zowalla <r...@apache.org> wrote: > > Hi David, > > thanks for the update. > > I think it is a good idea to look at the (unreleased) JWT 2.1 while > your head is still "in the zone". Mybe you find some corner/edge/we- > dont-like things in the next spec and we can change before it happens. > > Regarding your original discussion / question: > > I think, that we can eliminate support for JWTAuthConfiguration. We > already switched to smallrye and did some major version upgrades of > microprofile. That will - most certainly - break user applications, so > their code needs to be touched anyway. If we don't do it now, the next > opportunity might be TomEE 10 ;) > > Gruß > Richard > > Am Freitag, dem 09.09.2022 um 20:29 -0700 schrieb David Blevins: >>> On Aug 30, 2022, at 3:10 PM, David Blevins <david.blev...@gmail.com >>>> wrote: >>> >>> I'm digging through the test failures in the MP JWT TCK and one of >>> them is a test verifying support for downloading the keys for >>> verifying JWTs via an http call. >>> >>> The trick is the test is deploying an application that makes an >>> HTTP request to itself to get the public key and expects that to >>> work. Since we validate the configuration before the application >>> is started, this does not work -- the application can't call itself >>> to make an HTTP request because it hasn't been deployed >>> yet. Chicken and egg. >> >> Alrighty, we're down to just two failures in the MP JWT 2.0 TCK and >> both are due to the above. >> >> As mentioned, fixing this is going to require ripping the code up a >> bit and backwards incompatible changes to JWTAuthConfiguration which >> was user-facing in TomEE 8.0. >> >> Before I do that I'm tempted to take a look at implementing the >> unreleased JWT 2.1 requirements & TCK tests while my head is in this >> space. I know there's at least one change that I'm not a fan of and >> there may be others. I'd prefer to get that feedback in asap before >> that spec goes final, if possible. >> >> Anyway, things are looking good! >> >> >> -David >> >> >> >
smime.p7s
Description: S/MIME cryptographic signature
