ExpiredSignature should perhaps not be a subclass of DecodeError

[joelmichael]

This caused some confusion for us. If a JWT token is expired, this doesn't mean it failed to decode. We were checking for when JWT tokens don't decode correctly due to a formatting error, but this was also catching the case where a (perfectly legitimately encoded) JWT token simply had expired. Thus it affected our error handling for expired tokens unexpectedly.

[anakinj]

Currently all the errors are subclasses of this DecodeError, so your suggestion (that is perfectly reasonable) applies for all the errors. I agree that some kind of intermediate subclassing logic would make sense.

Think revamping the error hierarchy could be a chore for the next major release, to allow possible breaking changes.

[jkarmel]

Thanks @anakinj! I just wanted to second this - because we use Rails' rescue_from on both DecodeError in general and ExpiredSignature in particular but have different handling for each error. Because ExpiredSignature inherits from DecodeError we now have to order the rescue_from blocks in a specific order which feels pretty brittle.

Appreciate this library, which has been great overall!

[anakinj]

Structure to the errors would be great. Some help trying to create some hierarchy appreciated.