INTRODUCTION

In Lessons 3.1 and 3.2, we established the cryptographic identity of the PSU and TPP—issuing access tokens scoped to specific permissions. However, an access token is a transient bearer of authority. The source of that authority is the Consent Resource—a durable, auditable legal record that formally binds the PSU, TPP, and ASPSP to a specific set of data access or payment initiation rights.

Consent is not a binary flag; it is a finite-state machine with a strict regulatory backbone. PSD2 Article 67 mandates that consent must be explicit, granular, and revocable. The UK CMA Order (through OBIE v4.0) enforces a 90-day re-authorisation window. Australia’s CDR imposes a strict 2-hour revocation propagation SLA. Brazil’s Open Finance allows 12-month consent but requires daily consent health checks.

This lesson shifts focus from who you are (OAuth) to what you are allowed to do (Consent). We will mathematically model the consent lifecycle, derive the expiry probability function to predict user re-engagement rates, formulate the cache invalidation latency for revocation using probabilistic broadcast models, and calculate the storage capacity requirements for a consent ledger at scale (using Little’s Law and record size estimates).

LEARNING OBJECTIVES

1. Formalize the Consent State Machine using set theory—defining the legal tuple C = {PSU, TPP, Permissions, Validity_Interval, Status} and mapping each status transition (AWAITING → ACTIVE → EXPIRED or REVOKED) to specific HTTP/REST events.

2. Derive the Expiry Calculus—developing the hazard function h(t) for consent expiry, modeling the probability that a consent remains valid after t days without re-authorisation, and proving why 90 days is the optimal equilibrium between user friction and security entropy.

3. Quantify the Revocation Propagation Delay—modeling the ASPSP’s event-driven cache invalidation using the Gossip Protocol Latency Formula O(log N) and deriving the maximum tolerable network partition time to satisfy the CDR’s ≤2-hour SLA.

4. Calculate the Consent Ledger Storage Burden—estimating the total database footprint for a major European bank (10 million active PSUs) using the formula Storage = Active_Consents × Avg_Record_Size + Expired_Consents × Avg_Record_Size × Retention_Years, and comparing B‑Tree vs. LSM‑Tree index overheads.

5. Design the Consent to Scope Mapping Algebra—developing a bijection between OAuth 2.0 scopes (strings) and granular CDR permissions (e.g., ACCOUNTS_BALANCES_READ), and mathematically proving that the mapping is injective to prevent permission escalation.

PART 1: THE CONSENT RESOURCE MODEL — A Finite-State Machine with Legal Entropy

1.1 The Formal Consent Tuple

A consent is not merely a flag; it is a structured data object that must survive for 5–7 years for audit purposes. We define the Consent Tuple mathematically:

C = { ConsentID, PSU_ID, TPP_ClientID, Permissions_Set, Grant_Time, Expiry_Time, Revocation_Time, Status }

Where Status ∈ { AWAITING_AUTH, ACTIVE, EXPIRED, REVOKED, SUSPENDED }.

The State Transition Logic:

• AWAITING_AUTH → ACTIVE (Trigger: PSU completes SCA and grants permission via the OAuth authorization endpoint).

• ACTIVE → EXPIRED (Trigger: System time T_now exceeds Expiry_Time, OR 90 days have elapsed since Grant_Time).

• ACTIVE → REVOKED (Trigger: Explicit DELETE /consents/{id} called by TPP or PSU).

• REVOKED → EXPIRED (Trigger: Hard deletion from the hot store after the retention period).

Regulatory Anchor: Under PSD2 Article 67(2), the consent must be “specific and informed.” This means the Permissions_Set must be a strict subset of the scopes requested. The ASPSP must validate the injective relationship between the requested scope and the granted permissions.

1.2 The Granularity Spectrum (Scope Algebra)

OAuth 2.0 uses a flat scope string (e.g., accounts:read). CDR Australia requires per-account, per-field granularity. To support this without breaking OAuth semantics, we define a Scoped Permission Set:

Let P be the universe of all possible data fields. The Consent grants a subset G ⊂ P. The OAuth scope string is a compressed representation of G using a deterministic hash function H(G). The ASPSP’s token introspection endpoint returns the expanded G to the Resource Server.

The Escalation Attack Proof: If a TPP requests a token with scope S but the stored consent grants G, we must enforce S ⊆ G. If S contains an element not in G, the token issue is denied. This ensures monotonicity—a TPP cannot gain more rights than the PSU signed.

PART 2: THE EXPIRY CALCULUS — The 90-Day Re-Authorisation Mandate

2.1 Why 90 Days? The Entropy-Decay Model

The UK OBIE mandates a maximum consent lifetime of 90 days (unless the PSU re-authenticates). This is a security vs. usability optimisation.

Assume the probability of a PSU’s device being compromised is p per day. After d days, the cumulative risk of compromise is R(d) = 1 - (1-p)^d.
For d = 90 and p = 0.001 (0.1% daily compromise risk), R(90) ≈ 1 - (0.999)^90 ≈ 8.6%. This is deemed an acceptable upper bound for financial data exposure. For d = 365, R(365) ≈ 30.6%, which is unacceptable.

2.2 The Expiry Hazard Function

We model the validity of a consent as an exponential decay process. The probability that a consent is valid (Active) at time t is given by the survival function S(t):

S(t) = e^(-λt) where λ is the “churn rate” (user revokes or re-authenticates).

If we allow a 90-day window, the ASPSP calculates the absolute expiry timestamp:
Expiry_Time = Grant_Time + 90 × 86400 seconds.

The Re-Authorisation Window: OBIE allows a grace period of 7 days after expiry, during which the consent is in a “soft expired” state and the TPP may still read data but cannot initiate new payments. Mathematically, this adds a buffer term:
Hard_Expiry = Grant_Time + 97 × 86400.

PART 3: REVOCATION PROPAGATION — The Eventual Consistency Bound

3.1 The Challenge of Distributed Caches

When a PSU revokes consent (DELETE /consents/{id}), the ASPSP must invalidate the OAuth access tokens (hard) and purge cached data from all microservices (soft). In a distributed system, this requires eventual consistency.

We model the ASPSP as a network of N cache nodes. Revocation triggers a Gossip Protocol—each node forwards the invalidation event to a random subset of peers.

The Gossip Convergence Time:
T_gossip = O(log N) rounds. For N = 100 nodes, this takes approximately 7 rounds. If each round takes RTT (50ms), total propagation time is 7 × 50 = 350ms.

3.2 The 2-Hour SLA vs. Theoretical Limits

The CDR mandates ≤2 hours. The theoretical T_gossip is < 1 second. Therefore, the bottleneck is not network propagation—it is application polling cycles (e.g., batch ETL jobs refreshing caches every 15 minutes). By setting the cache’s max-age to 5 minutes and implementing a Pub/Sub (Kafka) listener, we can ensure propagation within ~2 seconds.

PART 4: STORAGE CAPACITY AND SCALABILITY

4.1 The Consent Ledger Formula

The ASPSP must retain consent records for 7 years (GDPR/audit requirement). Let:

• A = Active consents (average 10 million).

• E_yearly = New consents created per year (5 million).

• R_years = Retention period (7 years).

• Avg_Size = Average record size (including JSON metadata, ~5 KB).

Total Storage:
Total = (A × Avg_Size) + (E_yearly × R_years × Avg_Size)
Total = (10M × 5KB) + (5M × 7 × 5KB) = 50 GB + 175 GB = 225 GB.
This is easily manageable in a modern RDBMS (PostgreSQL).

4.2 Indexing Strategy

• Primary Key: ConsentID (UUID) – Hash index for O(1) lookups.

• Secondary Index: PSU_ID + Status – B-Tree index for listing active consents. The B-Tree height h is log_b(N) where b is the branching factor (approx. 100). For N = 10^7, h ≈ 4 disk seeks (4ms each = 12ms), which is acceptable.