feat: more expressive errors

[raphaelrobert]

No description provided.

[jcjones]

This looks great, thank you! I also appreciate the refactoring around deserializing the responses, that is much clearer too.

[jcjones]

Since all these PartialEq only compare variants and not the underlying source fields, it feels like that should be documented for types, and perhaps Eq not be implemented.

[jcjones]

did you want to impl PartialEq here for SerializationError?

[raphaelrobert]

@jcjones It turns out that the changes from #45 make #42 somewhat more complicated. Since we can now have several public keys for which we verify a signature, we expect signature verification to fail for all but one key. Therefore it's not entirely clear what we should return.
Looking at the underlying verify() function in the blind-rsa-signatures crate, only Error::UnsupportedParameters is returned when the length of the signature and the public key modulus are not equal, all other errors are mapped to Error::VerificationFailed.

Some options:

1. When all verification attempts fail with all keys, we return all errors.
2. When all verification attempts fail with all keys, we only return errors that are not Error::VerificationFailed.
3. We don't change anything, given that the application can trivially check for the Error::UnsupportedParameters case itself.
4. Any other ideas?

[jcjones]

Thorny.

I agree with not changing the redeem_token function, but I would still argue that it's not obvious to check that the Token's authenticator's length needs to be equal to at least one of the public keys. In my case, at the time new to the specification/ecosystem, I decoded the tokens incorrectly. I could tell the pubkeys were correct, but until I dug out the underlying UnsupportedParameters I didn't realize the relationship and where my error was.

Perhaps this is a thing for debug logging instead? Or expanding the doc comment on redeem_token?

[raphaelrobert]

I think both options you propose are valid. In the case of debug logging, it would probably be good to have more logging than just for that case. Do you want to file a PR for the solution you prefer?

[jcjones]

I'll put together a PR. Thanks!

[jcjones]

I've opened #48 to replace this PR.