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
//! Profile-shared verification policy — the JOSE-level fields neither
//! `access_token::VerifyConfig` nor `id_token::VerifyConfig` "owns".
//!
//! ── Why a third struct ──────────────────────────────────────────────────
//!
//! Phase 10.0 split the engine into `access_token::*` + `id_token::*` but
//! left `engine::check_algorithm` / `check_header` / `raw` reading their
//! cfg from `access_token::VerifyConfig`. That conceptually inverts the
//! dependency: the JOSE wire layer doesn't depend on RFC 9068; RFC 9068
//! depends on JOSE. Phase 10.1 (this file) restores the layering — both
//! profile configs *embed* a `SharedVerifyConfig`, and the engine
//! submodules read only from this struct.
//!
//! Adding a field here is a deliberate decision: it must be JOSE-shared
//! (applies to both profiles symmetrically). RFC 9068 access ports
//! (replay/session/epoch revocation) stay on `access_token::VerifyConfig`;
//! OIDC-specific axes (`expected_nonce`, `max_age`, `acr_values`) stay
//! on `id_token::VerifyConfig`.
use crateAlgorithm;
/// JOSE-level verification policy shared by both profiles.