This adds an UntrustedToken type which can be used to parse things like the footer, from an unverified token, in order to verify it. It also adds TrustedToken. Both types are part of both low-level and high-level APIs now. The latter let's you easily access individual parts of authenticated and validated tokens with claims.
@Eh2406 if you have a minute, could you check the API of UntrustedToken and see if this fulfills your requirements?
Remaining things:
[x] Include TrustedToken in this PR? TrustedToken that can only be created internally and returned by verify()/decrypt() (current high-level API can parse claims from this or switch to returning TrustedToken as well) (it is included)
[x] verify() should at least return the decoded base64 messages, after verification instead of Result<()> if TrustedToken isn't implemented (TrustedToken is included)
[x] Update changelog
[x] Make UntrustedToken part of the overall API? Then verify()/decrypt() could take these instead of String so that the validation logic of the token format/base64 decoding isn't performed twice. Then it makes much more sense to return TrustedToken as well. Then the footer in the UntrustedToken will be verified if footer = Some(&[data]) but and compared constant time. If footer = None, then the footer will be validated if present, but not compared constant-time.
See #47
This adds an
UntrustedTokentype which can be used to parse things like the footer, from an unverified token, in order to verify it. It also addsTrustedToken. Both types are part of both low-level and high-level APIs now. The latter let's you easily access individual parts of authenticated and validated tokens with claims.@Eh2406 if you have a minute, could you check the API of
UntrustedTokenand see if this fulfills your requirements?Remaining things:
TrustedTokenin this PR?TrustedTokenthat can only be created internally and returned byverify()/decrypt()(current high-level API can parse claims from this or switch to returningTrustedTokenas well) (it is included)verify()should at least return the decoded base64 messages, after verification instead ofResult<()>ifTrustedTokenisn't implemented (TrustedTokenis included)UntrustedTokenpart of the overall API? Thenverify()/decrypt()could take these instead ofStringso that the validation logic of the token format/base64 decoding isn't performed twice. Then it makes much more sense to returnTrustedTokenas well. Then the footer in theUntrustedTokenwill be verified iffooter = Some(&[data])but and compared constant time. Iffooter = None, then the footer will be validated if present, but not compared constant-time.