ppoppo-token 0.2.0

JWT (RFC 9068, EdDSA) issuance + verification engine for the Ppoppo ecosystem. Single deep module with a small interface (issue, verify) hiding RFC 8725 mitigations M01-M45, JWKS handling, and substrate ports (epoch, session, replay).
Documentation
//! OpenID Connect Core 1.0 id_token profile.
//!
//! Sibling of `access_token::*`, structurally and semantically disjoint:
//! id_tokens carry per-scope PII (M72), nonce binding (M66), at_hash /
//! c_hash (M67/M68), and the `azp` / `auth_time` / `acr` axes — none of
//! which apply to RFC 9068 access tokens. Sharing a `Claims` struct
//! between profiles would force callers to disambiguate at every read
//! site.
//!
//! ── Public surface ──────────────────────────────────────────────────────
//!
//! Verify side:
//! * [`Claims<S>`] — phantom-typed payload; PII accessors are gated by
//!   the marker traits in [`scopes`]. Acceptance evidence for §6.11.1
//!   D2: `Claims::<scopes::Openid>::email()` is a *compile error*, not a
//!   runtime check.
//! * [`VerifyConfig`] — id_token verify policy. Carries `expected_nonce`
//!   as a required field (no `Option`); construction without one is
//!   impossible.
//! * [`AuthError`] — id_token verification errors (M66-M73 + M29-mirror
//!   `CatMismatch` + shared JOSE errors carried via `Jose(...)`).
//!
//! Issue side (Phase 10.10 — D2 emission half):
//! * [`IssueConfig`] — id_token issuance config. Symmetric to
//!   [`VerifyConfig`]: carries the deployment-stable identity
//!   (`issuer`, `audiences`, `kid`) plus the RP-knowable bindings
//!   (`nonce`, at_hash / c_hash inputs).
//! * [`IssueRequest<S>`] — phantom-typed issuance payload. Builders
//!   for PII fields are scope-gated: `.with_email(...)` only compiles
//!   when `S: HasEmail`. Field-for-field mirror of [`Claims<S>`].
//! * [`IssueError`] — issuance failure modes including the β1 runtime
//!   defense-in-depth `EmissionDisallowed(name)`.
//!
//! Shared:
//! * [`Nonce`] — opaque RP-minted correlator (M66 verify-side
//!   `expected_nonce`; same value travels into [`IssueConfig::id_token`]
//!   on the issue side).
//! * `verify::<S>` — single verify entry-point.
//! * `issue::<S>` — single issue entry-point (lands in Phase 10.10.D
//!   alongside the engine wiring).
//!
//! Engine submodules (`crate::engine::*`) remain `pub(crate)`; the
//! `verify` / `issue` re-exports below are the only paths through which
//! id_token consumers reach the JWS pipeline (M51/M52 structural lint).

pub(crate) mod claims;
pub(crate) mod error;
pub(crate) mod issue_config;
pub(crate) mod issue_error;
pub(crate) mod issue_request;
pub(crate) mod nonce;
pub mod scopes;
pub(crate) mod verify;
pub(crate) mod verify_config;

pub use self::claims::{AddressClaim, Claims};
pub use self::error::AuthError;
pub use self::issue_config::IssueConfig;
pub use self::issue_error::IssueError;
pub use self::issue_request::IssueRequest;
pub use self::nonce::Nonce;
pub use self::scopes::{HasAddress, HasEmail, HasPhone, HasProfile, ScopeSet};
pub use self::verify::verify;
pub use self::verify_config::VerifyConfig;

pub use crate::engine::issue_id_token as issue;