INTRODUCTION

In Lessons 3.1–3.3, we securely authenticated the user (PSU) and managed their consent. However, the ASPSP must also authenticate the client (TPP). Without strong client authentication, a malicious actor could impersonate a legitimate fintech, request tokens, and drain customer accounts.

FAPI 1.0 Advanced mandates two distinct, overlapping layers of client authentication:

  1. mTLS (Mutual TLS): The TPP presents an X.509 certificate (QWAC in the EU/UK, ICP-Brasil in Brazil) during the TLS handshake. This authenticates the TPP’s physical server and ensures the traffic is encrypted with a pre-negotiated cipher suite.

  2. Client Assertion (JWT) : The TPP presents a signed JWT (private_key_jwt) in the client_assertion parameter of the token request. This authenticates the software statement of the TPP and cryptographically binds the token request to the TPP’s registered client_id.

This lesson deconstructs the mathematical binding of these two layers. We prove why binding the Access Token to the mTLS certificate’s thumbprint (x5t#S256) neutralizes token theft across different servers. We derive the optimal certificate rotation period (90 days) based on the probability of private key exposure, and we model the OCSP Stapling latency as a statistical distribution to prevent false negatives during authentication.

LEARNING OBJECTIVES

  1. Formalize the Client Assertion JWT—deriving the exact formula for the nbf and exp constraints, and proving mathematically that the jti (JWT ID) claim, combined with a server-side replay cache, prevents any replay attack with 100% certainty.

  2. Analyze the mTLS Certificate Binding—defining the x5t#S256 claim (SHA‑256 thumbprint of the client certificate) in the Access Token, and using set theory to prove that a stolen token is useless on a different machine with a different private key.

  3. Model the Certificate Validity and Rotation—calculating the optimal certificate lifetime (in days) using the Annualized Failure Rate (AFR) of Hardware Security Modules (HSMs), and deriving the exact overlap period required to avoid service disruption.

  4. Derive the OCSP Stapling Performance Profile—constructing a statistical model of the stapling response time, including the worst-case scenario when the OCSP responder is unreachable, and calculating the fallback CRL size.

  5. Design the JWKS Rotation Schedule—formulating the background refresh interval (T_refresh) for the ASPSP’s public signing keys using the Nyquist theorem, ensuring that the TPPs always have a valid key for signature verification.

PART 1: THE CLIENT ASSERTION — Mathematical Non-Replayability

1.1 The Assertion JWT Structure

The TPP sends a signed JWT as the client_assertion in the POST /token request. The header must indicate alg: PS256, and the payload must contain:

text
{
  "iss": "TPP_Client_ID",
  "sub": "TPP_Client_ID",
  "aud": "https://auth.bank.com/token",
  "iat": T1,
  "nbf": T1 - 90,
  "exp": T1 + 120,
  "jti": UUID_Unique
}

The Replay Prevention Proof: The ASPSP maintains an LRU cache of jti for a duration of exp - iat (120 seconds). If a second request arrives with the same jti, the ASPSP rejects it. The probability of an attacker guessing a valid jti is 1 / 2^128, effectively zero.

1.2 The Clock-Skew Margin

The nbf (Not Before) is set to iat - 90 seconds. This allows for a 90-second clock skew between the TPP and ASPSP. While this increases the valid window, it is mathematically bounded. The time window for a replay attack is strictly [iat - 90, exp] = 210 seconds. If an attacker intercepts the assertion, they have a maximum of 210 seconds to use it. However, because the ASPSP is stateless, the jti cache invalidates the window immediately upon first use. Therefore, the effective window is zero.

PART 2: mTLS AND THE CERTIFICATE BINDING (x5t#S256)

2.1 Binding the Token to the Certificate

FAPI mandates that the Access Token issued in an mTLS-protected token endpoint must be bound to that specific TLS certificate. The ASPSP calculates the SHA‑256 thumbprint of the client certificate presented during the POST /token request:

x5t = SHA256(Certificate_DER)

This thumbprint is embedded in the Access Token JWT as the cnf (Confirmation) claim:

text
"cnf": { "x5t#S256": "base64url(SHA256(cert))" }

The Logic:

  • Token Issuance (AS): AS verifies mTLS, extracts certificate thumbprint, and writes it into the token.

  • Token Presentation (RS): The RS receives the Access Token and the new mTLS connection from the TPP. The RS computes the thumbprint of the certificate presented in this new connection. If New_Thumbprint ≠ x5t#S256, the RS rejects the request.

The Theft Mitigation:
If an attacker steals the Access Token but does not possess the TPP’s private key (needed for mTLS), they cannot establish an mTLS connection with the correct certificate. The only way to pass the validation is to steal the certificate and the private key. This reduces the attack surface to the HSM physical layer.

PART 3: CERTIFICATE LIFECYCLE AND REVOCATION CHECKING

3.1 The Optimal Rotation Period

Certificates have a finite lifetime. OBIE mandates a maximum of 365 days, but recommends 90 days. Let the probability of a private key being compromised per day be p_c = 10^-9 (1 in a billion). The cumulative risk over d days is R(d) = 1 - (1-p_c)^d.

  • For d = 365: R ≈ 0.000365 (0.0365%).

  • For d = 90: R ≈ 0.00009 (0.009%).
    The risk reduction factor is 4x by rotating every 90 days. This justifies the overhead.

3.2 OCSP Stapling and CRL Fallback

To check revocation status without contacting a remote CA for every request, the ASPSP uses OCSP Stapling. The TPP’s certificate includes the OCSP response signed by the CA.

Latency Modeling:

  • OCSP Valid: The ASPSP verifies the signature on the stapled response. This takes T_OCSP = ~1ms.

  • OCSP Unavailable: The AS falls back to the CRL (Certificate Revocation List). CRLs are cached locally and updated every 24 hours. The size of a full CRL for a major CA is ~10MB; searching it locally takes T_CRL = ~2ms.

The worst-case latency is still under 5ms, well within the budget.

PART 4: JWKS ROTATION — The Public Key Lifecycle

The ASPSP must rotate its own signing keys (used to sign ID tokens and Access Tokens). The JWKS endpoint publishes the active and pending keys.

The Rotation Schema:

  1. Generate new key (Key B) while Key A is active.

  2. Publish both keys in the JWKS for a 24-hour overlap.

  3. After 24 hours, drop Key A.

The Nyquist Refresh Rule: Since TPPs cache the JWKS for 12 hours, the ASPSP must ensure that a valid key is published for at least 12 hours before the old key expires. By maintaining a 24-hour overlap, we satisfy the Nyquist criterion (refresh interval < cache TTL), ensuring zero service disruption.

CLOSING — THE CERTIFICATE TRIFECTA (Identity, Binding, Rotation)

You have now quantified the entire client authentication pipeline. The TPP proves its identity via an assertion JWT (math), proves its possession of the private key via mTLS (physics/hardware), and receives a token cryptographically bound to that specific certificate. The binding x5t#S256 neutralizes the token theft vector entirely. The 90-day rotation reduces key exposure risk by a factor of 4.

 
 
PreviousNext