Protect FinanceRates with an LFI-hosted display element
Retire the encrypted-JWE protection for FinanceRates. Instead of handing the TPP an encrypted rate to decrypt on the device, the LFI returns a reference to a surface it renders itself, which the TPP embeds as a cross-origin element — 3DS-style — so the rate is never received by the TPP at all.
Cast your vote
Sign in with the Trust Framework to vote — For, Against, or Abstain — recorded in the open with your reasoning. Your organisation and name come from your directory profile, and each person may vote once. This changes how a protected rate reaches the customer for every LFI and TPP, so the reasoning you record carries as much weight as the tally itself.
The encrypted-rate design is heavy to build and thin on protection
When a TPP holds ReadProductFinanceRates and calls GET /accounts/{AccountId}/product, the LFI MAY return the FinanceRates field as a compact JWE rather than a cleartext object. The TPP forwards that JWE to the customer’s browser and decrypts it locally, using a one-time code the LFI sends the customer out of band. The Encrypted FinanceRates guide documents the full flow.
# Today — the LFI returns FinanceRates as an encrypted JWE
GET /accounts/{AccountId}/product
"FinanceRates": "eyJhbGciOiJQQkVTMi1IUzUxMitBMjU2S1ciLCJlbmMiOiJBMjU2R0NNIn0..."
# The TPP forwards this compact JWE to the customer’s browser and decrypts it
# locally using a one-time code the LFI sent out of band. Once decrypted, the
# cleartext rate exists in a context the TPP controls — whether it is stored or
# leaves the device rests on the TPP behaving as it demonstrated at certification.LFI feedback has surfaced two structural problems. First, it is heavy to implement for thin protection. The LFI must generate a per-call JWE (PBES2-HS512+A256KW / A256GCM), mint and deliver a one-time code on a channel it controls, and operate OTP-spam rate limits — a significant build. Yet once the browser decrypts the JWE, the cleartext rate exists in a context the TPP controls; whether it is stored or leaves the device rests on trusting the TPP to behave as it demonstrated at certification.
Second, that certification is a point-in-time check, and it is not technically required. The optional certification attests, once, that the TPP decrypts and displays locally and does not persist the rate — it cannot bind the TPP’s runtime behaviour thereafter. Separately, nothing in the API Hub currently prevents an uncertified TPP from requesting ReadProductFinanceRates when it creates a consent; the dependency is documented but not enforced.
The net effect is real engineering cost on the LFI side buying protection that still rests on trust, with an enforcement gap on top.
Have the LFI show the rate itself, inside the TPP’s screen
On GET /accounts/{AccountId}/product, an LFI protecting a rate returns — in place of the rate value — a short-lived reference to an LFI-hosted display surface. The TPP embeds that surface as a cross-origin element (a plain iframe, or an LFI-provided web component) within its own screen. The customer sees the rate in the flow of the TPP application; it is rendered by LFI-origin content that the TPP’s code cannot read, script into, or capture.
# Proposed — the LFI returns a reference to a surface it renders itself
GET /accounts/{AccountId}/product
"FinanceRates": {
"DisplayUrl": "https://display.altareq1.example.ae/rates?rt=eyJhbGciOi...",
"ExpiresAt": "2026-08-01T14:30:00Z"
}
# The TPP embeds DisplayUrl as a cross-origin iframe. The customer sees the rate
# rendered by LFI-origin content; the TPP’s own code cannot read it. The rate
# value never reaches the TPP in any form, encrypted or cleartext.This mirrors 3-D Secure: the LFI is the issuer, the TPP is the merchant, and the sensitive interaction happens in an issuer-controlled frame the merchant hosts but cannot see into. LFIs that already run 3DS challenge infrastructure can reuse that tooling to authenticate the customer inside the surface, replacing the out-of-band OTP entirely.
The customer’s browser or app loads the LFI surface directly from the LFI origin, exactly as it already reaches the LFI when the customer authenticates during consent authorisation. Strict mediation is preserved — the invariant governs API and data traffic, and the rate value is never proxied to the TPP; only a reference is.
What the reference means, precisely
The reference and the surface behind it become something TPPs and LFIs build against, so the shape and the controls have to be pinned down rather than left to implementation.
FinanceRatesbecomesanyOfa cleartextAEProductFinanceRatesobject or a newAERateDisplayRef. TheAEJweshape is removed from this field.AERateDisplayRefcarries aDisplayUrlon the LFI’s customer-facing display origin — itself carrying a signed, single-use request token bound to the consent,AccountId,ProductId, and the TPP’s client identity — and anExpiresAt.- Confidentiality comes from cross-origin isolation. Because the frame is cross-origin, the TPP page cannot read the rate from the DOM, script into the frame, or capture its content. This holds regardless of any allowlist.
- Access comes from the token. A valid
DisplayUrlonly ever reaches the legitimate TPP, because obtaining one requires an authenticated, consented call through the API Hub. The LFI validates the token before rendering anything. - Expiry is enforced by the LFI, server-side. After
ExpiresAtthe surface stops rendering the rate — it is no longer a TPP obligation to honour a display window. - No per-TPP embedding-origin registration. We deliberately avoid a
frame-ancestorsallowlist; it would only add clickjacking defence for a display-only surface showing the customer their own rate, at the cost of a new registration artifact and LFI upkeep, and it does not map cleanly onto native / webview. ReadProductFinanceRatesis unchanged. It still gates whether the LFI surfaces the rate at all; if the permission is absent,FinanceRatesis omitted from theProductrecord, exactly as today.
The baseline embedding is a plain cross-origin iframe — the lowest common denominator and the closest reuse of 3DS browser flows — with an optional LFI-provided web-component or mobile-SDK profile defined for richer embedding, and for native contexts where an iframe is not the host.
What changes
One schema change, a display surface on the LFI side, a repurposed certification the API Hub can enforce, and documentation. The consent, audit, and billing semantics are untouched.
In the account-information specification, change FinanceRates to anyOf [ AEProductFinanceRates, AERateDisplayRef ], add the AERateDisplayRef schema, and remove AEJwe from this field. Targets V2.2. Because no LFI has a live JWE implementation, the removal affects no one and needs no deprecation window.
A protecting LFI stands up (or reuses) a tokenised, customer-facing display surface that validates the request token, authenticates the customer where it chooses to — reusing existing 3DS / challenge infrastructure — renders the rate, and enforces ExpiresAt server-side. In return it retires the JWE generation, the one-time-code minting and delivery, and the OTP-spam rate limits. No per-TPP allowlist is maintained.
Rename the optional Access Encrypted Resource Data certification — a misnomer once there is no encryption — to Rate Display Embedding, and repurpose it: the TPP demonstrates it can correctly embed and operate the LFI element and does not attempt to defeat its isolation. The API Hub SHOULD then reject a consent requesting ReadProductFinanceRates from a TPP that does not hold the certification, using the trust-framework record it already holds — closing today’s enforcement gap.
Rewrite the two Encrypted FinanceRates guides (TPP and LFI) and the Data Sharing requirements tables around the embedded surface, update the certification page under its new name, and record the change as an errata. No new registration field is introduced.
A different shape of work, not obviously less of it
This proposal trades one build for another. It retires the JWE crypto, the one-time-code delivery, and the OTP rate limiting — genuinely the heaviest parts of today’s LFI work — but in their place a protecting LFI has to expose a customer-facing display surface with token validation and, if it wants friction control, a challenge step. For an LFI that already runs 3DS this is largely reuse; for one that does not, it is new front-end responsibility.
The change is meaningful for TPPs too: they move from forwarding a JWE and decrypting in-browser to embedding and operating a cross-origin element they cannot style. And it is a breaking schema change to FinanceRates, taken at V2.2. The one thing that makes it cheap right now is that no LFI has shipped the JWE path, so nothing has to be migrated — this is close to a clean start rather than a transition.
A vote in favour is a statement that your institution would build to this — an LFI that it would host the surface, a TPP that it would embed it — not merely that it reads as more secure. If the ecosystem would rather keep the encrypted-rate design, or would not use the protected path at all, that is a perfectly good outcome and the work will not be scheduled.
What the display surface buys
- ✓The rate never enters the TPP’s systems in any form — protection is structural (cross-origin isolation), not a matter of trusting the TPP’s conduct after a point-in-time certification.
- ✓Removes the heaviest parts of the LFI build: JWE generation and the PBES2 / A256GCM crypto, per-call one-time-code minting and out-of-band delivery, and OTP-spam rate limiting.
- ✓Expiry is enforced by the LFI server-side, eliminating today’s “the TPP must honour exp” weakness and the header-vs-plaintext ambiguity in the current design.
- ✓Lets LFIs reuse existing 3DS / challenge infrastructure to authenticate the customer inside the surface, rather than build a bespoke encryption-and-OTP flow.
- ✓Makes the certification meaningful and technically enforceable at consent creation — closing the gap where nothing today stops an uncertified TPP requesting ReadProductFinanceRates.
- ✓Cleartext stays available for LFIs that do not consider a given rate sensitive, so no forced friction is added where none is wanted.
- ✓No LFI has a live JWE implementation, so removing AEJwe affects no one — this is a clean introduction, not a migration, with no deprecation window to run.
What it costs
- ×LFIs must expose a customer-facing web surface with token validation — more front-end responsibility than a pure API contract, even where it reuses existing customer channels.
- ×Embedded cross-origin frames bring UX cost: sizing, theming to fit the TPP’s design, mobile-webview quirks, and accessibility. 3DS challenge windows are a known source of friction.
- ×The TPP cannot theme or localise the rate presentation — it is the LFI’s element. Consistency of protection is bought at the price of TPP brand control.
- ×Clickjacking / overlay attempts belong in the threat model. They are mitigated by the LFI’s framing hygiene, the certification, and the low value of a display-only surface showing the customer their own rate — but we deliberately do not defend them with a per-TPP origin allowlist.
- ×Viewing a protected rate now requires a live, customer-present context and an LFI round-trip — it is not a server-side or batch-friendly path. (This already applies to today’s JWE + OTP path, which is also customer-present.)