1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
//! γ port-and-adapter SDK boundary for OpenID Connect Relying Party
//! (RP) integration.
//!
//! Phase 10.11 — sibling of [`crate::token`]. Where `token::*` exposes
//! the [`BearerVerifier`](crate::token::BearerVerifier) port for RFC 9068
//! access-token verification (the resource-server side of OAuth), this
//! module exposes [`IdTokenVerifier`] for OIDC id_token verification
//! (the user-authentication side). The two are intentionally disjoint:
//! id_tokens authenticate the user *to the RP*, access_tokens authorize
//! the RP *to the resource server* (OIDC Core §1.2 / RFC 9068 §1).
//!
//! Phase 11.A — adds [`RelyingParty<S>`] composition root + the
//! [`StateStore`] port + `discovery` primitive. The verify-half
//! ([`IdTokenVerifier`] + [`PasIdTokenVerifier`]) stays as the
//! resource-side surface; [`RelyingParty<S>`] composes both halves
//! (start_authorization → callback completion) for the user-flow side.
//!
//! ── Module layout — mirrors [`crate::token`] for parallel structure ─────
//!
//! - [`port`] — [`IdTokenVerifier`], [`IdAssertion`], [`IdVerifyError`]
//! (always compiled when `token` feature is on; depends on engine
//! `ScopeSet` / `Nonce` types).
//! - [`verifier`] — [`PasIdTokenVerifier<S>`] production adapter (gated
//! `well-known-fetch`; depends on the engine's id_token verify entry
//! and a TTL-cached JWKS).
//! - [`memory`] — [`MemoryIdTokenVerifier<S>`] +
//! [`InMemoryStateStore`] test-support adapters (gated
//! `cfg(any(test, feature = "test-support"))`).
//! - [`state_store`] — [`StateStore`] port + value types ([`Config`],
//! [`State`], [`RelativePath`], [`PendingAuthRequest`],
//! [`AuthorizationRedirect`], [`CallbackParams`], [`Completion<S>`])
//! (gated `feature = "oauth"` + `feature = "token"`; Phase 11.A).
//! - [`discovery`] — `fetch_discovery` primitive for OIDC
//! well-known-openid-configuration documents (gated
//! `feature = "well-known-fetch"`; Phase 11.A).
//! - [`relying_party`] — [`RelyingParty<S>`] composition root (gated
//! `feature = "well-known-fetch"`; Phase 11.A skeleton, Phase 11.B
//! impl).
//!
//! ── Phase 9 inheritance — [`AuditSink`] reuse ───────────────────────────
//!
//! Verify-failure emission travels through the same
//! [`AuditSink`](crate::AuditSink) port that [`PasJwtVerifier`](crate::PasJwtVerifier)
//! uses. One audit pipeline serves both verifiers; consumers pass the
//! same `Arc<dyn AuditSink>` to both `with_audit` builders. The
//! [`VerifyErrorKind`](crate::VerifyErrorKind) enum gains an
//! `IdToken(_)` nested variant in 10.11.B so dashboard pivots can
//! filter "all id_token failures" with a single match arm.
//!
//! ── Scope re-exports ────────────────────────────────────────────────────
//!
//! The engine's [`scopes`](ppoppo_token::id_token::scopes) markers are
//! re-exported here so consumers reach them via the SDK boundary:
//!
//! ```ignore
//! use pas_external::oidc::{IdTokenVerifier, Openid, Email, EmailProfile};
//! ```
//!
//! rather than depending on `ppoppo-token` directly. This preserves the
//! γ invariant: the engine type never crosses the SDK boundary except
//! through SDK-shaped re-exports.
pub use ;
pub use PasIdTokenVerifier;
pub use ;
pub use ;
pub use ;
pub use MemoryIdTokenVerifier;
pub use InMemoryStateStore;
// Engine re-exports — consumers reach scope markers + Nonce via the SDK
// boundary rather than depending on `ppoppo-token` directly.
pub use ;