@berendsliedrecht and Timo came up with the wish that the verification functions will not throw errors and break up the function call, but rather return a list of validation with their result.
Before implementing this we have to make clear what are validations that can run without breaking up and what kind of response should they return. I want to avoid to introduce a complex validation framework for a scenario where the implementation it not worth the feature.
For me the validation of a signature is a must have. Is this wrong, we can not trust the JWT since it's not authentic!
expiration check
not before check
revoked check (checking the status list)
Could be done in parallel without stopping each other. But we have to make this clear to the implementer that just the function ran without throwing an error and being in the success call, the jwt does not have to be valid!
I also do not think that it is the job of the validation function to return some kind of validation report if everything is okay. This is out of scope of this library to generate reports that can be presented to the user and can be implemented by the ones needing the in their application.
We also have to think about if we want to pass a parameter like throwErrorOnFail to break up further checks. In case of efficiency this could be relevant.
@berendsliedrecht and Timo came up with the wish that the verification functions will not throw errors and break up the function call, but rather return a list of validation with their result.
Before implementing this we have to make clear what are validations that can run without breaking up and what kind of response should they return. I want to avoid to introduce a complex validation framework for a scenario where the implementation it not worth the feature.
For me the validation of a signature is a must have. Is this wrong, we can not trust the JWT since it's not authentic!
Could be done in parallel without stopping each other. But we have to make this clear to the implementer that just the function ran without throwing an error and being in the success call, the jwt does not have to be valid!
I also do not think that it is the job of the validation function to return some kind of validation report if everything is okay. This is out of scope of this library to generate reports that can be presented to the user and can be implemented by the ones needing the in their application.
We also have to think about if we want to pass a parameter like
throwErrorOnFailto break up further checks. In case of efficiency this could be relevant.