v1.5.1

What's Changed

• Use json.RawMessage to delay serialisation/deserialisation by @aidantwoods in #48

Full Changelog: v1.5.0...v1.5.1

v1.5.0

What's Changed

• Add constructors to allow constructing keys from standard Go objects by @aidantwoods in #43
• Update dependencies by @aidantwoods in #45

Full Changelog: v1.4.0...v1.5.0

v1.4.0

This is an fairly large internal change around how results + errors are being represented. There should be no change to any consumer facing behaviour from the public API perspective.

What's Changed

• doc: update README by @Claude-Zq in #26
• Result type by @aidantwoods in #19
• No longer force unwrap footer result by @aidantwoods in #41

New Contributors

• @Claude-Zq made their first contribution in #26

Full Changelog: v1.3.0...v1.3.1

v1.3.0

What's Changed

• Raise min permitted version of Go to 1.18 by @aidantwoods in #23
• Bump yaml dependency by @aidantwoods in #24

Full Changelog: v1.2.1...v1.3.0

v1.2.1

What's Changed

• Create SECURITY.md by @aidantwoods in #17
• Only run push trigger for main by @aidantwoods in #18
• Add pkg description by @aidantwoods in #20
• Update deps and notice about Go version support by @aidantwoods in #21

Full Changelog: v1.2.0...v1.2.1

v1.2.0

What's Changed

• Update ci.yml by @ilyabrin in #9
• Validate ed25519 private keys during import by @aidantwoods in #8
• Add sentinel error types by @aidantwoods in #12

New Contributors

• @ilyabrin made their first contribution in #9

Full Changelog: v1.1.3...v1.2.0

Sentinel Errors

Introduces two specialisations on errors that may be returned: TokenError and RuleError. Note that some errors will still be returned by the library that are in neither of these specialisations, and so you should still fallback to general error handling (not assume one of these will always be returned).

A TokenError will be returned if the token is outright invalid in some way, whether that be due to formatting, a cryptographic issue, or some other issue which renders the token invalid.

A RuleError will be returned if a token fails one of the specified rules, but is otherwise valid (including cryptographically).

Distinguishing between these two error types is not mandatory: it is perfectly safe to just handle a general error without inspecting it. Being able to inspect an error may be useful for some use cases, for example if a different handling action is desired depending on whether the token was invalid or whether a rule failure occurred. Note that if you do look for one of these errors, you should additionally include code to handle general errors as a fallback: you should expect new errors that do not fall into either of these two categories to be returned in the future.

v1.1.3

What's Changed

• Added new NotBeforeNbf rule, which can be used the check the current time is after or equal to the token's nbf claim.
• Clarified that NotExpired checks according to the time when the rule is run, not when the rule is created

Full Changelog: v1.1.2...v1.1.3

v1.1.2

What's Changed

• Testing against update PASETO test vectors #5
• Error messages are now slightly more helpful

Full Changelog: v1.1.1...v1.1.2

v1.1.1

What's Changed

• Add feature to import/export keys as raw byte array by @suttod in #2

New Contributors

• @suttod made their first contribution in #2

Full Changelog: v1.1.0...v1.1.1

v1.1.0

This minor release adds support for version 3 public of the PASETO spec.

Additional information: #1