Struct Verifier 

pub struct Verifier { /* private fields */ }

A set of published verification keys (indexed by kid) plus the issuer / audience policy applied to every token. Construct once at boot, then share behind an Arc and call verify per request — verification is read-only and allocation-light.

kid is an opaque string assigned by the auth-service and carried in each token’s footer; the verifier indexes its keys by exactly that kid, so key selection at verify time is a direct map lookup.

Implementations

impl Verifier

pub fn from_paseto_keys_value( keys_doc: &Value, issuer: &str, audience: &str, ) -> Result<Self, VerifyError>

Build a verifier from an in-memory key-set document, validating tokens against issuer (iss) and audience (aud).

The document mirrors a JWK set restricted to Ed25519: { "keys": [ { "kty": "OKP", "crv": "Ed25519", "kid": "...", "x": "<base64url 32-byte public key>" }, ... ] }. Entries whose kty/crv are not OKP/Ed25519 are skipped. An empty key set is permitted — it yields a verifier that rejects every token with VerifyError::UnknownKid, so a service can boot before its key source is reachable without panicking.

Errors

VerifyError::Keys when the document lacks a keys array, an Ed25519 key is missing kid / x, or x is not a 32-byte base64url value.

Examples

let keys = serde_json::json!({ "keys": [] });
let verifier = Verifier::from_paseto_keys_value(&keys, "authentication-service", "main-x-service")?;
assert_eq!(verifier.key_count(), 0);

pub fn key_count(&self) -> usize

Number of usable verification keys loaded.

Counts only keys whose algorithm this build implements, so a health check reading this cannot be reassured by a key set full of keys it cannot verify with. A count of zero means no token can verify, which usually signals a key set that failed to load — or, now, an issuer that has moved entirely to an algorithm this binary does not support.

pub fn unsupported_key_count(&self) -> usize

Number of loaded keys whose algorithm this build does not implement.

Non-zero means the issuer publishes keys this binary cannot use. That is normal and expected mid-rollout — the issuer adds the new algorithm before every verifier understands it — and is the signal to upgrade verifiers before the old keys are withdrawn. Worth exporting as a metric for exactly that reason.

pub fn algorithms(&self) -> Vec<String>

The algorithm labels this verifier holds keys for, usable or not, sorted and deduplicated — for logging what a key set actually advertises.

pub fn verify(&self, token: &str) -> Result<Claims, VerifyError>

Verify a PASETO v4.public bearer token: select the key by the footer kid, check the Ed25519 signature, then enforce issuer, audience, expiry, and not-before.

Steps run cheapest-rejection-first: confirm the v4.public header, read the (authenticated) footer for its kid, select the key, then perform the signature check and finally the claim policy.

Errors

• VerifyError::Malformed if the token is not a structurally valid v4.public token or its footer is not { "kid": ... }.
• VerifyError::MissingKid if the footer carries no kid.
• VerifyError::UnknownKid if the kid matches no loaded key.
• VerifyError::Paseto if the Ed25519 signature check fails.
• VerifyError::Claim if iss / aud / exp / nbf do not satisfy the policy.

Examples

let keys = serde_json::json!({ "keys": [] });
let verifier = Verifier::from_paseto_keys_value(&keys, "authentication-service", "main-x-service")?;
assert!(verifier.verify("not.a.paseto").is_err());