Mostly as discussed in #9 with the following exceptions:
validateClaimsSet is exported from Crypto.JWT separately from validateJWSJWT, mostly for ease of testing. Doing so may lead some users to only validate the claims, without realizing that they need to validate the signature as well. I added an additional warning to try to prevent this.
Prior to these commits, the signature of validateJWSJWT had been changed to use ValidationsSettings instead of ValidationAlgorithms and ValidationPolicy. I left it as it was, choosing to defer to the code over the discussion in #9.
I did not provide validateJWSJWTWithTime, as was discussed in #9. The implementation uses MonadTime, of which IO and any mtl stack terminating in IO are all instances, and (as demonstrated in the tests) it is straightforward to make Reader UTCTime an instance for testing purposes. I believe that this covers any use cases that would be served by validateJWSJWTWithTime without tempting unsophisticated users to perform unsafe IO.
Mostly as discussed in #9 with the following exceptions:
validateClaimsSetis exported from Crypto.JWT separately fromvalidateJWSJWT, mostly for ease of testing. Doing so may lead some users to only validate the claims, without realizing that they need to validate the signature as well. I added an additional warning to try to prevent this.validateJWSJWThad been changed to useValidationsSettingsinstead ofValidationAlgorithmsandValidationPolicy. I left it as it was, choosing to defer to the code over the discussion in #9.validateJWSJWTWithTime, as was discussed in #9. The implementation uses MonadTime, of which IO and any mtl stack terminating in IO are all instances, and (as demonstrated in the tests) it is straightforward to makeReader UTCTimean instance for testing purposes. I believe that this covers any use cases that would be served byvalidateJWSJWTWithTimewithout tempting unsophisticated users to perform unsafe IO.