Source-linked AI summary
Optimizing Credential Blast Radius Through Trust Boundaries and Delegation Under Post-Quantum Authentication Costs
Pauli Taipale, Harri Lainio
TL;DR
Trust-boundary placement can limit credential-compromise reach, but post-quantum authentication costs make cross-boundary calls a performance concern. The paper jointly optimizes domains and credential derivation under policy and latency constraints; joint optimization lowers blast-radius score in most exhaustive comparisons. Its latency model is a linearized proxy rather than a general end-to-end or tail-latency model.
Problem
Trust boundaries can contain credential compromise but increase cross-boundary authentication costs, which post-quantum mechanisms can raise on constrained or lossy paths.
Source: §1 · p. 1Method
A two-layer optimization model jointly chooses trust domains and credential-derivation trees under policy and latency constraints, using a conservative linear objective and exact expected-impact evaluation when a joint compromise model is available.
Source: §1 · p. 2Results
Joint optimization lowers the chain or depth-two blast-radius score in 195 of 230 exact comparisons, with a larger effect under chain delegation.
Source: §14 · p. 9Takeaways & Limitations
The framework identifies conditions for exact additive issuer scoring and polynomial-time optimization, while providing candidate designs from risk assumptions and crossing-cost inputs.
Source: §1 · p. 2, §14 · p. 9Static edge coefficients do not directly model correlated packet loss, retries, shared congestion, queueing, or end-to-end tail latency.
Source: §12 · p. 8
Abstract
from arXiv · showhide
Partitioning interacting services into independently rooted trust domains limits issuer-compromise reach while increasing calls across trust boundaries. Post-quantum replacements for public-key authentication and key-establishment mechanisms can increase crossing latency on constrained or lossy paths. We formulate the joint selection of trust domains and credential-derivation structures under policy and latency constraints, linking separate service-interaction and credential-derivation graphs through domain assignment. Credential blast radius measures weighted service impact after compromise. A linear upper bound supports optimization, while a joint event model gives exact expected impact. We identify when risk from issuers trusted across domains can be incorporated into this linear score, avoiding separate issuer-propagation calculations for each candidate. Although the general problem is NP-hard, we identify restricted cases that can be solved efficiently and exactly. Joint optimization yields lower blast radius than choosing boundaries first in 195 of 230 exhaustive synthetic comparisons, especially under chained delegation. A trace-derived replay used measured post-quantum costs, synthetic risk inputs, a fixed derivation family, and one to six trust domains. Under independent compromise events, mean expected impact was up to 36% lower than with one domain within the latency budget. The framework turns risk assumptions and measured crossing costs into candidate trust-domain and credential-derivation designs.
1 INTRODUCTION
The paper jointly chooses trust boundaries and credential-derivation structures to limit compromise reach while respecting the cost of cross-boundary authentication. Its model links service interactions and credential propagation through domain assignment under policy and operational constraints.
1 INTRODUCTION
- Jointly choosing trust boundaries and credential-derivation structures addresses two compromise paths: domain-root exposure and delegated-principal reach.Boundary placement limits the first; derivation structure limits the second.Source: §1 · p. 1
- Post-quantum boundary mechanisms can increase handshake traffic and delay on constrained or lossy paths, making containment decisions subject to a deployment-specific performance budget.The passage also cautions that PQC does not impose a uniform computational slowdown.Source: §1 · p. 1
2 BACKGROUND AND THREAT MODEL
1 INTRODUCTION
- Shared-issuer acceptance can create compromise paths that bypass nominal domain roots, so the method models those relationships separately and identifies when additive scoring is exact.Otherwise, issuer reachability must be traced for candidate designs.Source: §1 · p. 1
2 BACKGROUND AND THREAT MODEL
5 BLAST-RADIUS OBJECTIVE
The section defines a conservative linear blast-radius score and a boundary-latency proxy for comparing designs. Derivation choices govern delegated reach, while crossing costs depend on deployment conditions.
5 BLAST-RADIUS OBJECTIVE
- BRnode sums each compromise point’s probability-weighted impact across the services reachable through its derivation tree.In an arborescence, the equivalent path form makes design pressure explicit: high-probability principals should control little descendant weight.Source: §5 · p. 3
- Under any dependence structure, BRexact is bounded above by BRnode; the linear score avoids assuming a dependence model, but candidates should be rescored under an explicit joint model when probabilities are large or strongly dependent.Under independence, the bound is first-order tight when probabilities are small.Source: §5 · p. 3
6 LATENCY COST
- Boundary latency sums interaction rate, latency sensitivity, and effective crossing cost only for calls whose endpoints lie in different domains.The cost is deployment-specific and may reflect cryptographic work, communication, reuse, and key-update policy.Source: §6 · pp. 3–4
- Equation (7) is a linearized boundary-overhead proxy, not a general end-to-end or tail-latency model.The named TLS measurements span 0.0338–15.5815 ms per crossing call across the specified profile and path range; these are architecture inputs, not algorithm rankings.Source: §6 · pp. 3–4
- At a fixed cut, raising the fanout bound from 2 to 3 reduces BRnode from 0.06 to 0.03 without changing boundary latency.The higher bound permits direct root issuance.Source: §6 · p. 4
7 OPTIMIZATION PROBLEM
The optimization selects domain assignments and credential trees together to trade blast radius against a latency budget. Fixing domains separates tree choices, but does not remove the coupling in the overall design.
7 OPTIMIZATION PROBLEM
- The design jointly selects domains and derivation trees, balancing compromise reach against boundary latency.Boundary placement changes root exposure and latency, while derivation structures govern delegated-principal propagation within domains.Source: §7 · p. 4
- Fixing the domain assignment separates derivation-tree best responses, but the outer assignment still changes both domain membership and the interaction cut.It can also change feasibility through the fanout and depth limits.Source: §7 · p. 4
- A latency budget traces the containment–latency frontier, and additional linear constraints such as a boundary-byte cap can be imposed in the same form.The formulation keeps the two objective units separate.Source: §7 · p. 4
- Scalarization generates supported candidates, then budget-preserving refinement can recover unsupported points; this refinement remains heuristic in general regimes.The implementation selects the feasible candidate with minimum blast radius for each budget.Source: §7 · p. 4
8 SHARED-ISSUER VALIDATION AND RESCORING
The paper characterizes when additive scoring can handle shared-issuer risk and identifies tractable and hard optimization regimes. When accepted targets overlap by ancestry, explicit issuer-reachability scoring is needed for final selection.
8 SHARED-ISSUER VALIDATION AND RESCORING
- In the shared-issuer model, observed issuer-minting and verifier-acceptance relations determine whether the core score suffices or explicit issuer reachability is needed.Redesigns retain those deployment relations as inputs rather than optimization variables.Source: §8 · pp. 4–5
- For fixed designs, the additive issuer score upper-bounds first-order explicit issuer reachability and is exact when each issuer’s accepted targets form an antichain in each derivation tree.The score is also exact for star trees with any number of accepted targets, and for chain trees with at most one accepted target per domain.Source: §8 · p. 5
- When accepted targets overlap by ancestry, additive issuer scoring is only a screening upper bound and final candidate selection requires explicit scoring.The overlap depends on the derivation tree, preventing a candidate-independent adjustment to effective compromise probabilities.Source: §8 · p. 5
9 COMPLEXITY AND STRUCTURAL REGIMES
- The joint problem is NP-hard in chain regimes for fixed k ≥3, while the scalarized direct-issuance two-domain case is solvable by minimum cut in polynomial time under its stated assumptions.Multiway-cut variants are NP-hard for k ≥3.Source: §9 · p. 5
- Documented trust-domain and delegation patterns establish implementability, but service-call traces omit credential semantics and do not establish deployment prevalence.The replay therefore does not estimate how common the regimes are.Source: §9 · p. 6
10 OPERATIONAL SOLVER
The operational solver builds and refines trust-domain and credential-derivation candidates under policy and latency constraints, using exact routines where structural assumptions permit and heuristics otherwise. Evaluation compares joint with staged selection, tests measured-cost designs against held-out budgets, and assesses when shared-issuer reachability requires explicit rescoring.
10 OPERATIONAL SOLVER
- The solver builds a policy- and cost-calibrated instance, generates exact or heuristic designs, then refines candidates under hard latency budgets.It validates shared-issuer semantics and remeasures selected crossing edges before accepting a design.Source: §10 · p. 6
- Exact routines cover chain, direct-issuance, fixed-hub depth-two, two-domain min-cut, and anchored low-treewidth cases; coupled chain and multiway cases remain hard.The reported guarantees depend on each regime's stated assumptions.Source: §10 · p. 6, Table 1 · p. 7
11 EVALUATION
- The deployment study calibrated three named cryptographic profiles over five paths using 12,000 TLS observations, then validated selected crossings on held-out blocks.The operational comparison fixes the derivation family while changing domain-assignment selection.Source: §11 · p. 7
- At B = 0.10 ms, both risk scenarios selected k = 6; BR/BR0 was 0.685 under the heterogeneous baseline and 0.743 under cluster skew.The selected domain count recurred in at least 80% of edge-count resamples and solver seeds under each scenario.Source: §11 · p. 7
- 195 of 230 feasible comparisons favored joint optimization over staging, with staged scores higher in 117 of 120 chain cases.The reported comparison also covers depth-two cases; five infeasible tight-budget cases per risk setting were omitted.Source: §11 · p. 7, Table 2 · p. 8
- A 5% reserve under either block-maximum rule met all 20 path-budget checks, but finite held-out success does not establish a path-independent guarantee.Remeasurement and rejection remain necessary.Source: Table 3 · p. 8, §11 · p. 8
- On N0, risk-aware search lowered mean exact expected-impact ratios from 0.884 to 0.693 and 0.638 at two budgets, with every risk-aware design meeting its held-out budget.The 0.884 latency-first ratio applied at both budgets.Source: §11 · p. 8
- Additive issuer scoring found the best explicitly evaluated candidate in 11 of 12 comparisons; outside the antichain condition, final selection uses explicit reachability.Evaluating the three candidates ranked highest by the reachability-aware proxy recovered the best generated candidate in all 12 comparisons.Source: §11 · p. 8
12 LIMITATIONS
The paper distinguishes what trust boundaries and credential-derivation structures contain, then evaluates their joint design under latency and policy constraints. Its conclusions are limited by the modeled compromise paths, crossing-cost assumptions, and search scope; the closing sections relate the formulation to prior work and outline supplementary analyses.
12 LIMITATIONS
- The model is a credential-architecture planning abstraction, and its conclusions depend on supplied workload, criticality, compromise, and cost scenarios.Propagation covers credential authority, not verifier compromise, software supply-chain compromise, or non-credential exploitation; compromise probabilities are exogenous.Source: §12 · p. 8
- The core assumes single-parent derivation, while multiparent or threshold issuance needs a DAG model; globally coordinated mixtures of core and explicit-propagation scoring remain open.Crossing costs also assume symmetric protection or derived credentials within a domain; independent public-key operations require additional weighted events or refined domain assignments.Source: §12 · p. 8
- Static effective crossing-cost coefficients do not directly model correlated loss, retries, congestion, queueing, or end-to-end tail latency; operational use requires remeasurement of selected crossings.Finite held-out success cannot establish a path-independent guarantee.Source: §12 · p. 8
- Trace results use one deterministic bounded-breadth-first derivation family and finite local-search budgets, so global optimality over all feasible arborescences remains unverified.Supplementary tables quantify observed gaps against exhaustive references on small instances.Source: §12 · p. 8
13 RELATED WORK
- Related work optimizes access structure or key-update communication, whereas this formulation jointly uses an independent-root partition, operational derivation forest, steady-state crossing cost, and condition for exact additive issuer scoring.The cited access-structure methods keep credential-derivation structure fixed; logical-key-hierarchy models focus on update or recovery communication.Source: §13 · p. 9
14 CONCLUSION
- Joint optimization lowers the chain or depth-two blast-radius score in 195 of 230 exact comparisons, with a larger effect under chains; Figure 3 shows risk-aware search leading on N0, while its range overlaps traffic clustering on N2.The Figure 3 comparison uses one fixed derivation family and does not establish global optimization over all derivation arborescences.Source: §14 · p. 9, Figure 3 · p. 9
- The conclusion recommends generating candidate architectures, tracing shared-issuer reach where needed, and remeasuring selected crossings before accepting a design.The evaluation also reports that measured path conditions change the domain count selected under the same latency budget.Source: §14 · pp. 9–10
Supplementary Information: Optimizing Credential Blast Radius Through Trust Boundaries and Delegation
- The supplementary material collects structural results and proofs, secondary risk summaries, solver and workload diagnostics, crossing-cost and shared-issuer analyses, and deployment considerations.Additional solver-scaling, protocol, and calibration diagnostics are identified in Supplementary Section S4.Source: Supplementary Information: Optimizing… · p. 11
S1 WORKED EXAMPLE
The worked example separates fixed boundary latency from derivation-dependent blast radius, while the formal results identify exact and approximate regimes under restricted assumptions.
S1 WORKED EXAMPLE
- Increasing the fanout bound from 2 to 3 reduces the conservative blast-radius score from 0.06 to 0.03 without changing boundary latency.The fixed-domain example assigns Lat(D) = 220 in the unit-normalized toy calibration.Source: S1 WORKED EXAMPLE · p. 11, Figure S1 · p. 11
S1.1 Why latency-first optimization can fail
- Under budget B = 2, joint optimization reduces blast radius from 2.71 to 1.82 versus the latency-first design.The example attributes the difference to which high-risk principal is placed above another in the derivation chain.Source: S1.1 Why latency-first optimization… · p. 12
S2.1 Secondary structural results
- Two-domain tradeoffs admit polynomial parametric cut sweeps, while interval-robust objectives retain the minimum-cut reduction under the stated assumptions.Without fixed anchors, the sweep enumerates ordered anchor pairs; robust optimization substitutes upper bounds for uncertain costs and risks.Source: S2.1 Secondary structural results · p. 12
- In the star regime, bounded-treewidth dynamic programming gives exact optimization, and the at-most-k relaxation has a polynomial-time 2-approximation.The treewidth result assumes direct issuance; its approximation guarantee does not extend to the exact-k nonempty-domain constraint.Source: S2.1 Secondary structural results · pp. 12–13
- Refining each interaction-graph vertex into at most s scoped principals raises treewidth to at most s(τ + 1) − 1, a bound tight up to constants.The corresponding dynamic-programming runtimes depend on the expanded graph size and treewidth.Source: S2.1 Secondary structural results · p. 13
- With complete eligibility, ∆ = 1, and sufficient depth, sorting services by nondecreasing p(v)/w(v) gives an optimal chain in O(|Vi| log |Vi|) time.For w(v) = 0, the ratio convention is p(v)/w(v) = +∞.Source: S2.1 Secondary structural results · p. 13
- When root fanout can cover the domain and all root-to-service arcs are eligible, the star derivation minimizes the domain blast-radius objective.The proposition assumes ∆ ≥ |Vi| and h ≥ 1.Source: S2.1 Secondary structural results · p. 13
- For depth-two trees with complete eligibility, a fixed hub set reduces to a leaf-assignment problem; for constant ∆, enumerating hub sets yields an exact O(n^∆ poly(n)) algorithm.The assignment attaches larger-weight leaves to lower-risk hubs, filling each hub up to capacity.Source: S2.1 Secondary structural results · p. 13
S2.2 Proof of coupled NP-hardness (chains)
The proof reduces weighted completion-time scheduling on identical machines to the coupled design objective for chain derivations. This establishes hardness even when boundary latency is zero.
S2.2 Proof of coupled NP-hardness (chains)
- The construction uses no interaction edges, zero root risk, chain derivations, and service compromise probabilities scaled from scheduling processing times.It sets p(vj) = tj/T, where T = 1 + ∑j∈J tj, and uses scheduling weights as criticality weights.Source: S2.2 Proof of coupled NP-hardness… · p. 14
- For each design, the chain order corresponds to a machine schedule, and minimizing BRnode yields the scheduling optimizer up to the positive scaling factor 1/T.The reduction equates the objective with weighted completion time across domains.Source: S2.2 Proof of coupled NP-hardness… · p. 14
- The coupled optimization is NP-hard for every fixed k ≥ 3 and strongly NP-hard when k is part of the input.The reduction remains valid with the requirement that every domain be nonempty.Source: S2.2 Proof of coupled NP-hardness… · p. 14
S2.3 Proof of the two-domain min-cut regime
The proofs connect restricted design objectives to standard optimization problems: a minimum cut for two domains, ratio sorting for chains, and an upper bound for issuer propagation.
S2.3 Proof of the two-domain min-cut regime
- With two domains under the stated assumptions, the scalarized objective maps to an s–t cut, and nonempty domains are enforced by fixing anchors or enumerating ordered anchor pairs.Interaction edges contribute disagreement costs, while vertex capacities encode domain-specific root-risk terms.Source: S2.3 Proof of the two-domain min-cut… · pp. 14–15
S2.4 Derivation of Corollary S2.8
- For a fully eligible chain, sorting services by nondecreasing p(v)/w(v) minimizes the domain objective in O(n log n) time.The adjacent-swap comparison shows that ordering u before v is no worse when p(u)/w(u) ≤ p(v)/w(v).Source: S2.4 Derivation of Corollary S2.8 · p. 15
S2.5 Proof of the additive issuer-score upper bound
- The additive issuer contribution upper-bounds explicit issuer propagation, and the scores agree when accepted targets in a domain are pairwise incomparable in the derivation tree.Stars satisfy this antichain condition; chains permit at most one accepted target per issuer and domain.Source: S2.5 Proof of the additive… · p. 15
S2.6 Proof of Proposition S2.9
The proofs show when simple derivation structures are optimal and how the depth-two case reduces to a constrained assignment problem.
S2.6 Proof of Proposition S2.9
- When every root-to-service arc is eligible and ∆ ≥ |Vi|, the star is feasible and minimizes the domain objective.The proof separates a nonnegative ancestor contribution that is zero for the star.Source: S2.6 Proof of Proposition S2.9 · p. 15
S2.7 Proof of Proposition S2.10
- For a depth-two tree with n > ∆, some optimum has exactly ∆ services directly attached to the root and all remaining services at depth two.The proof promotes leaves to the root until its degree bound is filled without increasing the objective.Source: S2.7 Proof of Proposition S2.10 · p. 16
- With a fixed hub set, minimizing the depth-two objective is equivalent to assigning each leaf to one hub subject to each hub's capacity.Each leaf has one parent, and each hub has at most ∆ children.Source: S2.7 Proof of Proposition S2.10 · p. 16
- For constant ∆, assigning larger-weight leaves to lower-risk hubs and enumerating hub sets gives an exact algorithm in O(n^∆ poly(n)) time.Hubs are filled in increasing compromise probability, up to capacity.Source: S2.7 Proof of Proposition S2.10 · p. 16
S2.8 Proof of Proposition S2.4
The supplement establishes exact and bounded-width solution procedures for restricted cases, then tests solver quality and transfer across synthetic and trace-derived settings. The diagnostics show strong agreement with exhaustive optima in several tested regimes, while also identifying limits of heuristic search and the conditions needed to interpret deployment graphs.
S2.8 Proof of Proposition S2.4
- For the anchored star case, tree-decomposition dynamic programming runs in O(nk^(τ+1)) time, with at most k^(τ+1) bag assignments.The proof charges each unary and pairwise term when its last required vertex is processed; exact-k optimization minimizes over at most n^k ordered anchor tuples.Source: S2.8 Proof of Proposition S2.4 · p. 16
S2.9 Proof of Corollary S2.6
- Refining each service into at most s principals bounds the refined graph's treewidth by s(τ + 1) − 1, preserving polynomial-time exact optimization for bounded width and constant s.The stated runtime gains an additional factor for unanchored exact-k optimization over ordered anchor tuples.Source: S2.9 Proof of Corollary S2.6 · pp. 16–17
S3 ALTERNATIVE RISK SUMMARIES
- When root risks are equal, expected impact from root compromise is constant in the domain assignment, so segmentation differences appear in worst-case or heterogeneous-risk summaries.This concerns the root-risk contribution, not every risk component.Source: S3 ALTERNATIVE RISK SUMMARIES · p. 17
S4.1 Evaluation protocol
- The replay uses nine scalarization values, refines feasible candidates under each latency budget, and selects the feasible design with minimum blast radius.It fixes one deterministic breadth-first derivation family with fanout and depth limits of three, sets root compromise priors to zero, and caps tested domain counts at six.Source: S4.1 Evaluation protocol · p. 17
S4.2 Q1: Solver validity and transfer
- The fixed-schedule search took 1.95 seconds at n = 50 and 17.03 seconds at n = 1000, an 8.7× increase for 20× more services.These are means over two seeded instances per size; fixed search limits make the curve a throughput measure, not worst-case scaling or solution quality.Source: Figure S2 · p. 18
- Traffic-based starts with budget repair eliminated misses across 60 chain-instance and budget combinations, and the reduced schedule matched all 60 small-instance budget optima.The comparisons use exhaustive budget optima as the reference.Source: Table S1 · p. 18, S4.2 Q1: Solver validity and transfer · p. 18
- The supported-point sweep matched all 132 grid objective values across 12 instances using 4.7–5.0 exact solves per instance, versus 11 grid solves.Runtime was not measured, and the comparison does not cover unsupported hard-budget optima.Source: S4.2 Q1: Solver validity and transfer · pp. 17–18
- In the exact-chain check, the heuristic chose the same domain count in both observed misses, but local search could leave more latency budget unused than the exact solution.Among misses at B = 0.10, mean slack was 0.018 versus 0.002 ms; topology alone does not establish semantic eligibility for a formal solver.Source: S4.2 Q1: Solver validity and transfer · p. 18
S4.3 Q2: Workload, risk, and crossing-cost effects
The workload replay applies measured crossing costs and scenario-based risks to a trace-derived Train-Ticket graph, then checks cost sensitivity and held-out budget compliance. Results show that path-cost variation can change domain choices, while a reserve passed all tested path–budget checks.
S4.3 Q2: Workload, risk, and crossing-cost effects
- The workload retains 32 services and 72 edges from 1,157 unique public Jaeger traces across seven Train-Ticket configurations; compromise priors define a reproducible planning scenario, not empirical frequencies.Reported w(v) and p(v) values are rounded to three decimal places.Source: S4.3 Q2: Workload, risk, and… · p. 20
- At B = 0.10 ms, critical-path reweighting raised BR/BR0 from 0.685 to 0.711 under heterogeneous baseline risk and from 0.743 to 0.780 under cluster skew.The selected domain count stayed unchanged across all four risk–budget rows; at B = 0.20 ms, the change was at most 0.011.Source: S4.3 Q2: Workload, risk, and… · p. 20
- Across stored bootstrap estimates, only N0 at B = 0.10 changed its selected domain count, from five to six.A count of six reaches the search cap.Source: Figure S3 · p. 20, Table S7 · p. 21
- Across the ten path–budget cells, center-estimate C0, K1, and A1 costs selected the same domain count in eight cells, while incremental A1-minus-C0 costs selected more domains in six.The replay used Train-Ticket and the fixed bounded breadth-first derivation family.Source: Table S8 · p. 21
- A 5% latency-budget reserve passed all 20 tested path–budget checks, whereas edge-specific block maxima without a reserve passed every N0 check and 8 of 10 N2 checks.The authors recommend iterative deployment: calibrate, optimize, remeasure selected crossings, and update costs or reserve before rerunning.Source: S4.3 Q2: Workload, risk, and… · p. 21
S4.4 Q3: Explicit shared-issuer rescoring
Explicit issuer-reachability evaluation tests when an additive shared-issuer score can rank candidate designs reliably. The deployment guidance separates cryptographic trust boundaries from network topology and recommends reconstructing credential derivation and acceptance from control-plane data.
S4.4 Q3: Explicit shared-issuer rescoring
- The additive score selected the explicitly evaluated best candidate in 11 of 12 induced comparisons and missed by at most 5.86%; rescoring the reachability-aware proxy's top three recovered the best generated candidate in all 12.The exact additive reduction holds under the antichain condition; global optimality was not assessed.Source: S4.4 Q3: Explicit shared-issuer… · p. 21
S5 DEPLOYMENT CONSIDERATIONS
- A service-call graph alone cannot reveal credential authority or delegation eligibility; audited control-plane metadata can expose roots and delegation layers, while legacy systems may require evaluating plausible structures.The deployment class treats each trust domain as a key-establishment domain rooted in a common issuer or key-management authority.Source: S5 DEPLOYMENT CONSIDERATIONS · p. 22, S5.2 Extracting derivation structure… · p. 22
S5.1 Network segmentation vs. trust domains
- Network segmentation and cryptographic trust domains are different objects: sharing an issuer can create a propagation root across nominal domains even when the interaction graph is unchanged.For additive issuer scoring, accepted targets must have disjoint descendant sets within each issuer and domain.Source: S5.1 Network segmentation vs. trust… · p. 22
S5.2 Extracting derivation structure from control-plane data
- JWT/OIDC issuer and verifier configuration identifies accepted services and shared issuer roots; overlapping accepted-target descendants call for explicit reachability evaluation.The suggested extraction sequence inventories roots, maps issuance or delegation edges, intersects them with verifier-acceptance and policy data, then uses the coarsest defensible abstraction.Source: S5.2 Extracting derivation structure… · pp. 22–23
S5.3 Practitioner instantiation checklist
The checklist maps traces, risk assumptions, policy, and credential-control data into the optimization inputs. Operational refinements preserve the graph approach for scoped principals, policy-conditioned reachability, and request-class latency weights, but leave protocol-state details outside the formulation.
S5.3 Practitioner instantiation checklist
- Trace directed calls and normalize edge counts to calls per top-level request when interpreting latency in milliseconds per request; convert to event-equivalent rates only for raw per-event costs.Microbenchmark crossing costs on representative hardware and represent protocol reuse through event-equivalent rates or amortized per-interaction costs, not both.Source: S5.3 Practitioner instantiation… · p. 23
- The checklist sets impact weights, horizon-based compromise probabilities, policy-gated interaction and derivation edges, scoped principals, and derivation fanout and depth constraints.Risk uncertainty may be represented by intervals; the remaining coupled optimization is a design-space search under the specified constraints.Source: S5.3 Practitioner instantiation… · p. 23
S5.3 Practitioner instantiation checklist; S5.4 Operational refinements
- Request-class latency can be represented by refining linear edge coefficients using traced edge use, class weights, warm crossing costs, and cold-setup penalties.Explicit protocol state machines, packet failure probabilities, and request-level precedence are outside the graph formulation.Source: S5.3 Practitioner instantiation… · p. 24
S5.4 Operational refinements
- Refining a service into scoped principals can isolate highly privileged identities behind stricter boundaries, and bounded-width exact optimization remains polynomial-time for constant-size refinements under the stated direct-issuance assumptions.Policy and reachability condition the interaction and derivation graphs; finite compromise windows can be represented by horizon-dependent probabilities.Source: S5.4 Operational refinements · p. 24