INTRODUCTION

In Lessons 3.1 through 3.7, we dissected each component of the open banking security stack in isolation: OAuth flows, FAPI cryptographic constructs, consent state machines, certificate binding, token introspection, and risk‑based authentication.

However, a security system is only as strong as its weakest link—and a regulator audits the entire chain. A sophisticated attacker will not attack the RSA‑PSS signature (which is mathematically infeasible). Instead, they will target the OAuth redirect URI (open redirect), the PAR endpoint (lack of rate limiting), or the Consent UI (Clickjacking).

This capstone lesson reconstructs the full end‑to‑end flow from the PSU’s first click to the API response. We overlay the security controls onto a unified HTTP sequence diagram, annotating each step with its cryptographic guarantee and latency contribution. We then quantify the Total Attack Surface by multiplying the individual probability of breach for each layer (Defense‑in‑Depth), proving that the combined security posture reduces the probability of a successful attack to less than 2^-128. Finally, we provide the Audit Evidence Bundle—the exact logs, cryptographic hashes, and timestamps that the ASPSP must retain to prove compliance during a CMA or EBA investigation.

LEARNING OBJECTIVES

1. Reconstruct the Complete End‑to‑End Sequence—overlaying the PAR push, the JARM response, the mTLS handshake, the SCA dynamic linking, the consent creation, and the token introspection into a single, unified flowchart with microsecond‑level latency annotations.

2. Calculate the Total Attack Surface Probability—using the Independent Security Layer Theorem to multiply the success probability of each attack vector (e.g., Replay Attack, MITM, Token Theft, Consent Escalation), proving the combined breach probability is computationally infeasible.

3. Formalize the Audit Trail Algebra—defining the Audit_Record tuple as a cryptographic concatenation of ConsentID || Token_Hash || Certificate_Thumbprint || Transaction_HMAC || Timestamp, and proving that this binding makes it impossible for the ASPSP to “lose” or retroactively alter transaction evidence.

4. Design the Failure Mode Recovery—modeling the system’s behavior when each critical component fails (e.g., OCSP responder unreachable, Redis cache cold, PAR TTL expired), and deriving the deterministic fallback paths that maintain compliance.

5. Quantify the End‑to‑End Critical Path Latency—summing the p95 latencies from initial PAR push to final API response, proving that the mandatory security overhead (excluding human SCA time) is under 250ms, well below the 1.5s CDR and 850ms UK SLAs.

PART 1: THE END‑TO‑END SECURITY SEQUENCE — A Unified Flow with Latency Calculus

The complete authentication and consent journey involves 12 distinct network hops. The ASCII diagram below maps the exact cryptographic binding at each stage.

+-----------------------------------------------------------------------+
|         COMPLETE AUTH & CONSENT FLOW — LATENCY ANNOTATED               |
+-----------------------------------------------------------------------+
|                                                                        |
|  TPP (Client)         ASPSP (Auth)        ASPSP (Resource)  PSU       |
|     |                      |                     |            |        |
|     |--(1) PAR Push------->|                     |            |        |
|     | (mTLS, 10ms)        |                     |            |        |
|     |<-(2) request_uri----|                     |            |        |
|     |   (5ms)             |                     |            |        |
|     |                     |                     |            |        |
|     |--(3) Redirect PSU-->|                     |            |        |
|     |                     |                     |            |        |
|     |                     |<-(4) SCA Challenge--|------------|        |
|     |                     |  (Dynamic Linking)  |            |        |
|     |                     |  (3-5s Human)      |            |        |
|     |                     |                     |            |        |
|     |                     |<-(5) Consent Grant--|------------|        |
|     |                     |  (Granular Scopes) |            |        |
|     |                     |                     |            |        |
|     |<-(6) JARM Response--|                     |            |        |
|     |   (JWT Signed,      |                     |            |        |
|     |    0.5ms verify)    |                     |            |        |
|     |                     |                     |            |        |
|     |--(7) POST /token--->|                     |            |        |
|     |  (mTLS + Client     |                     |            |        |
|     |   Assertion, 15ms)  |                     |            |        |
|     |<-(8) Access Token---|                     |            |        |
|     |   (x5t#S256 bound)  |                     |            |        |
|     |                     |                     |            |        |
|     |--(9) API Call------>|-------------------->|            |        |
|     |  (Bearer Token)     |                     |            |        |
|     |                     |                     |            |        |
|     |                     |<-(10) Introspect----|            |        |
|     |                     |  (Cache Miss, 6ms)  |            |        |
|     |                     |--(11) Valid-------->|            |        |
|     |                     |                     |            |        |
|     |<-(12) Data Response-|                     |            |        |
|     |   (100ms)           |                     |            |        |
|                                                                        |
|  LATENCY SUM (Non‑Human): 10+5+0.5+15+6+100 = ~136ms                  |
+-----------------------------------------------------------------------+

Observation: The entire machine‑to‑machine security handshake (excluding the PSU’s SCA typing time) completes in ~136ms (p95). This leaves a massive budget (714ms) for the UK SLA and 1.36s for the CDR SLA.

PART 2: THE ATTACK SURFACE PROBABILITY — Defense in Depth Math

We model each security control as an independent layer. For a breach to occur, the attacker must break every layer simultaneously. The probability of a successful breach is the product of the individual failure probabilities.

Total Breach Probability:
P(Breach) ≈ (2^-128) × (2^-128) × (2^-344) × (2^-256) × (10^-9) × (10^-2) × (10^-6)

Ignoring the decimal powers and focusing on the exponents, the logarithmic sum is approximately -(128+128+344+256) = -856 bits of entropy, plus the machine learning factor (which is the “weakest link” at 1%). The combined probability is effectively zero. An attacker is more likely to win the lottery 1,000 times consecutively than to break this stack.

PART 3: THE AUDIT TRAIL ALGEBRA — The Cryptographic Binding Proof

A regulator requires proof that a specific transaction was authorized by a specific PSU using a specific consent. The ASPSP constructs an immutable audit trail by concatenating cryptographic artifacts.

Audit Record Definition:
Audit = ConsentID || Access_Token_Hash || mTLS_Thumbprint || Transaction_HMAC || Timestamp

Where:

• ConsentID is the UUID of the consent granting.

• Access_Token_Hash = SHA256(Access_Token) proves the token used.

• mTLS_Thumbprint = SHA256(Cert_DER) proves the TPP identity.

• Transaction_HMAC is the SCA dynamic linking code (proving the PSU saw the details).

The Non‑Repudiation Proof:
If the PSU disputes a transaction, the ASPSP presents the Audit record. The PSU’s device is the only entity holding the private key for K_Device, so only the PSU could have generated the Transaction_HMAC. The TPP’s certificate is bound to the token (x5t#S256), so only that specific TPP could have presented it. The mathematical linkage is transitive, irrefutable, and satisfies PSD2’s burden of proof.

PART 4: FAILURE MODE ANALYSIS AND FALLBACK RECOVERY

Even a perfect system fails. We define the deterministic fallbacks for each critical component:

CLOSING — THE COMPLETION OF MODULE 3

You have now completed Module 3: Authentication, Authorization, and Consent Management. You have mathematically formalized the entire stack:

• OAuth 2.0 + PKCE establishes the secure delegation channel with 2^-344 collision resistance.

• FAPI 1.0 Advanced (PAR, JARM, PS256) eliminates request tampering and response leakage with under 15ms overhead.

• Consent Management models the legal contract as a finite‑state machine, with revocation propagating via Gossip protocols under the CDR’s 2‑hour SLA.

• mTLS + Certificate Binding (x5t#S256) neutralizes token theft by cryptographically binding the token to the client’s physical hardware.

• SCA Dynamic Linking proves that the PSU saw exactly the transaction details, using HMAC‑SHA256 and 128‑bit entropy nonces.

• Risk‑Based Authentication optimally balances fraud risk and user friction, with sub‑5ms inference latency.

Ty.