Remove extrastandard assertion that iat is not from the future

[gobengo]

Discussion on #190

[mark-adams]

So I think this is going too far. There's no reason to throw out a perfectly good feature of the library that some people may find desirable. In my case (and pretty much any case I can think of) a JWT generated in the future (which is impossible) is lying to me... why would I trust the rest of the claims?

I do understand your desire to bypass this functionality. I'd definitely support a PR that makes verify_iat default to False. I think that would alleviate your concerns while not removing a useful feature of the library. If you submit a PR that does that, I'm all for it.

[gobengo]

@mark-adams @jpadilla I have amended the pull request to still leave iat future checking an option for those that want it.

However, this was not by changing the default value of the 'verify_iat' option to False, but by adding a new option.

This is because RFC7519 does specify how to verify iat (as NumericDate) with a MUST, and I don't think the default behavior should ignore that MUST. gobengo@e8a2432#diff-00ea5fc2260636f8d87435daf8c3b4c7R138

But future checking, along with a specific exception that is a subclass of InvalidIssuedAtError, is still in there with an option. gobengo@e8a2432#diff-6dc52fa39f2c4a084e5bde50b9537e4bR162

[mark-adams]

This has been superseded by #252