OFP-007 ClosedMedium

Show an LFI its own API Hub configuration in the Admin Portal

An LFI's Ozone Connect Base URL, Authorization Endpoint, application layer authentication method, and API family base paths are spread across an onboarding ticket and every later ticket that changed one of them. Nothing holds the current answer in one place. Surface the effective configuration, read-only, in the Admin Portal.

Proposed by

Nebras

Author

Thomas Catchpole

Target

API Hub

Opened

20 Jul 2026

Closes

3 Aug 2026

Decision record · DR-2026-007Admin Portal · TransparencyVoting closed 3 Aug 2026

✓

Approved Ratified

0% in favour · 0–0–0

OFP-007

Show an LFI its own API Hub configuration in the Admin Portal

✓Approved

Final decision

In favour

0/24

Total votes

Participation

§ Decision summary

Approved as proposed, and unanimously — 13 votes in favour, none against, none abstaining. A read-only Configuration section will be added to the Admin Portal, showing the effective connectivity and application layer authentication configuration the API Hub actually holds for that hub and environment, including the worked forwarded URL for each API family. Today that state exists only as a chain of Service Desk tickets an LFI has to find, order, and replay — where missing one gives a wrong answer that looks exactly like a right one. The proposal now passes to engineering for implementation.

The approved change adds a Configuration section to the Admin Portal, scoped — as the portal already is — to one API Hub and one environment. It is generated from the live configuration the API Hub enforces at proxy time, not from a stored copy of the onboarding submission, so it cannot drift from the running configuration. A multi-brand LFI opens each brand's portal and sees that brand's values, which is precisely the distinction that is hardest to hold onto across ticket threads.

No editing capability is introduced. Every value on the page is read-only. Configuration continues to be submitted and changed exactly as it is today, through the Service Desk, with Nebras's end-to-end connectivity validation unchanged. The vote showed clear appetite for editing some of these fields directly, and that will be taken forward as a separate proposal with the roles, approval, and validation model worked through properly — it is not part of this decision.

Nothing on the request path changes. The Ozone Connect contract, the headers, the schemas, the TPP-facing API, and the onboarding process are all untouched, and neither LFIs nor TPPs have anything to implement. Certificates remain out of scope: the Trust Framework is their system of record, and a second view of them would raise the question of which is authoritative.

What happens next

The proposal is now handed over to engineering for implementation. Delivery timings, and the detail of how the change is incorporated, will be communicated through the relevant API Hub release notes — this page will not be updated with a schedule. No action is required from LFIs or TPPs in the meantime.

The change This change will be made in a future API Hub release

No new fields, endpoints, or schemas — a read model over configuration the API Hub already holds, rendered in a portal an LFI already signs in to, behind Trust Framework SSO it already uses. Field names follow the onboarding documentation so the two read as one thing.

Shown in the Admin Portal · read-only, per hub and per environment

Ozone Connect Base URL — the base URL the API Hub forwards to for this environment.
Authorization Endpoint — the OIDC authorisation URL the customer is redirected to, or an explicit indication that the LFI has adopted CAAP and therefore provides none.
Application layer authentication method — mTLS only, API Key, Client Credentials Grant, or JWT Auth, with its configured sub-settings.
API family base paths — one row per family, showing the configured path or an explicit “not set”, and beside it the effective forwarded URL worked through against the base URL.
Instance identifiers and allocated values — LFI Code, LFI Organisation ID, the Ozone-allocated domains for the environment, and the API Hub egress IP addresses to allowlist.

Raised in the vote · carried forward separately

Restrict the section by role before release. Portal access is not role-differentiated today, so an LFI asked that backend URLs, internal paths, and egress IPs be limited to the technical roles. Carried into implementation as a requirement.
Editing these values in the portal. Four of the five voters who answered the question wanted it, naming API family base paths, endpoint URLs, and the LFI redirect URL (C3) — every one of them conditioned on maker-checker or four-eyes approval, a restricted role, audit logging, and controlled promotion to production. To be brought forward as its own proposal.
Log search by Interaction ID, with keyword search within a single request journey. Not configuration; recorded and taken up on its own merits.
Replace the mock-bank placeholder with the LFI's own base URL wherever it appears. A documentation and portal-copy fix, handled outside this proposal.

Decision

Voting is now closed

The voting period has ended. The votes cast are shown below.

§ ResultOFP-007Voting closed

Voting has closed for this proposal

in favour

votes cast

For

Against

Abstain

Feedback · themes from the vote

What the ecosystem told us

A short synthesis of the votes, comments, and question answers behind the tally above. Support was unanimous; the substance is in the three questions on the form, which five voters answered. The full per-organisation votes are listed in the panel.

Unanimous, with no dissent

Every vote was in favour — 13 for, none against, none abstaining — across a broad cross-section of LFIs. No amendment was requested, and no voter argued that the information should stay where it is. The read-only scope was accepted as drawn; the disagreement, such as it was, is about what should come next rather than about this.

Today the answer is reconstructed, not looked up

The first question asked how an LFI finds out what its configuration is actually set to. The answers converge: keep a local record, search back through the onboarding and change tickets, and raise a ticket with Nebras when no confident answer can be found. Frequency ranged up to one or two checks a week, triggered by a forwarded request failing, a pre-production/production comparison, or onboarding a new engineer. One LFI named the failure mode precisely — a local record says what was intended, not what the Hub is enforcing.

“Our record and the Hub’s record are two separate things. Our infrastructure code tells us what we intended to configure; it does not tell us what the Hub is actually enforcing. Where those have diverged, we have no way to detect it.”
An LFI · For

The resolved forwarded URL is the part that earns its keep

Two voters singled out the worked forwarded URL per API family, rather than the raw base paths, as the thing that changes their day. Showing the URL the Hub will actually call turns a 404 on a proxied request from a Service Desk ticket into something the LFI can diagnose from the screen in front of it. The same voter set the scaling problem out plainly: moving from one API Hub to two for SME takes them from one configuration to four across brands and environments, each distinguishable today only by reading ticket history in the right order.

“Reconstructing those from ticket history is exactly the failure mode described, and the per-brand portal scoping solves it without anything for us to build. The resolved forwarded URL per API family would also materially shorten incident diagnosis.”
An LFI · For

Read-only is enough for now — but editing has real appetite

The second question asked whether LFIs would want to change these values themselves. Four of the five who answered said yes, and they named fields: the API family base paths and endpoint URLs, the LFI redirect URL (C3), and in one case every field on the page. Every one of them attached change control to the request — maker-checker or four-eyes approval, a restricted role modelled on PBC/PTC access in the Trust Framework, audit logging, and controlled promotion to production. None of them argued it should be folded into this proposal; the split the proposal drew was accepted, and editing will be brought forward separately.

“Read-only is good enough for this proposal … That said, edit capability would also be valuable, but it should be treated as a separate enhancement … provided appropriate governance and change controls are in place (for example, role-based access, maker-checker approval, audit logging, and controlled deployment to production).”
An LFI · For

Restrict the page by role before it ships

The one condition attached to a “for” vote goes to the cost the proposal itself flagged: portal access is not role-differentiated today, so backend base URLs, internal paths, and egress IP addresses would become visible to every user the Trust Framework grants portal access. The request is that the section be limited to the technical roles before it is released — a requirement carried into implementation rather than a reason to hold the decision.

“Portal access is not currently role-differentiated, so this section would expose backend URLs and internal paths to every user granted portal access. We would ask that it be restricted to the technical roles before it ships.”
An LFI · For

Two adjacent asks, recorded but out of scope

The third question — what else an LFI would want to see that it cannot see today — produced two requests that are not configuration and so fall outside this proposal. One is log search in the Admin Portal filtered first by Interaction ID, with a second-level keyword search within a single request journey. The other is replacing the mock-bank placeholder with the LFI's own base URL wherever it appears, which is a documentation and portal-copy fix rather than a new view. Both are recorded and will be taken up on their own merits.

The proposal

01 · Background

Knowable in principle, scattered across tickets in practice

During environment-specific onboarding, an LFI hands Nebras the details that define how the API Hub reaches its backend: the Ozone Connect Base URL, the Authorization Endpoint, and an optional API family base path for each of Data Sharing, Service Initiation, Products, Consent Events & Notifications, and Health Check. Earlier in onboarding it selects an application layer authentication method — mTLS only, API Key, Client Credentials Grant, or JWT Auth — along with its sub-settings, such as the scopes used for Client Credentials or whether JWT Auth headers are also sent on the LFI's own calls to the Consent Manager and Headless Heimdall.

All of it is submitted on a Service Desk ticket. That is the documented process and it works: the ticket is raised, the values are exchanged, connectivity is validated in both directions, and the ticket is closed.

None of this is hidden from the LFI. The values are in the tickets, the tickets are searchable, and in principle everything can be recovered from them. The difficulty is that it is never one ticket. Onboarding creates the first record, and everything after it arrives as its own ticket, each raised to change one specific thing — a base path added when Products went live, a corrected path, a moved Authorization Endpoint, a switch from mTLS-only to JWT Auth. Each ticket is a delta, not a statement of the whole.

So working out what is configured today is not a lookup. It means finding every ticket that has ever touched the field, putting them in order, replaying them, and being confident none was missed — where missing one gives you a wrong answer that looks exactly like a right one. Then doing it again for the other environment, and again for each brand if the LFI runs more than one hub.

Today — reconstructing a value from the ticket history

Q: "What is our Data Sharing base path in pre-production?"

  OF-1042   Environment-specific onboarding, pre-prod     = /openfinance/data
  OF-1361   Add a base path for Products                  untouched?
  OF-1590   Move the Authorization Endpoint               untouched?
  OF-1847   Correct the Data Sharing base path            = /openfinance/data-sharing
  OF-2033   Switch application layer auth to JWT Auth     untouched?

The answer is whatever the LAST ticket to touch that field said — so you have to
find them all, order them, and be sure none was missed. Miss one and the wrong
answer looks exactly like the right one.

Then repeat for production. Then repeat for every other brand.

Meanwhile the API Hub holds the answer as a single current value, because that is what it enforces on every proxied request. There is simply no way for the LFI to ask it. The one place an LFI already signs in to look at its own hub — the Admin Portal — shows TPP activation, consents, logs, reports, outages, and the users who hold access. It does not show a single one of the values above.

The cost of this is small each time and constant in aggregate. It lands hardest in the places where accuracy matters most: an incident where a forwarded request is 404ing and nobody can confirm the path the Hub is prepending; a suspected drift between pre-production and production that nobody can rule out; a multi-brand LFI running several hubs whose configurations must be told apart from ticket history; a new engineer joining the team with no way to read the current state of the integration they have inherited.

02 · Recommendation

A Configuration section in the Admin Portal

Add a read-only Configuration section to the Admin Portal that shows the effective onboarding configuration the API Hub actually holds for that instance and environment. Not a copy of the onboarding form — the live values the Hub enforces at proxy time.

Proposed — Admin Portal › Configuration (illustrative)

Admin Portal  ·  Configuration          admin.examplebank.preprod.apihub.openfinance.ae

CONNECTIVITY
  Ozone Connect Base URL        https://openapi-uat.example.com
  Authorization Endpoint        https://auth.example.com/openfinance/authorize

APPLICATION LAYER AUTHENTICATION
  Method                        JWT Auth  (PS256, keys via Trust Framework JWKS)
  JWT Auth on LFI -> Hub calls  Enabled   (Consent Manager, Headless Heimdall)

API FAMILY BASE PATHS                                   Effective forwarded URL
  Data Sharing        /openfinance/data-sharing         https://openapi-uat.example.com/openfinance/data-sharing/accounts
  Service Initiation  /openfinance/service-initiation   https://openapi-uat.example.com/openfinance/service-initiation/domestic-payments
  Products            (not set)                         https://openapi-uat.example.com/products
  Consent Events      (not set)                         https://openapi-uat.example.com/event-notifications
  Health Check        /openfinance/health               https://openapi-uat.example.com/openfinance/health/echo-cert

INSTANCE
  LFI Code                      examplebank
  LFI Organisation ID           b41f9c2e-...
  API Hub egress IPs            203.0.113.10, 203.0.113.11   (allowlist these)

The scoping falls out of what already exists. The Admin Portal is provisioned one instance per API Hub, per environment — admin.{lficode}.preprod.apihub.openfinance.ae and admin.{lficode}.apihub.openfinance.ae — so a page inside it is already correctly scoped to one brand and one environment without anything new being built. A multi-brand LFI opens each brand's portal and sees that brand's configuration, which is exactly the distinction that is hardest to hold onto across ticket threads.

Access control falls out too. Portal access is already granted via Trust Framework SSO to users holding the relevant roles — PTC, PBC, STC — and revoked by managing those roles in the Trust Framework. This proposal introduces no new identity, credential, or permission model; the audience for the page is the audience the portal already has.

Nothing else changes. The Ozone Connect contract, the headers, the schemas, the TPP-facing API, and the onboarding process itself are all untouched. Configuration continues to be submitted and changed exactly as it is today.

03 · What is shown

Connectivity and authentication, for this hub and this environment

The scope is the configuration an LFI provides or is allocated for connectivity. Certificates are deliberately excluded — see below.

In scope

Ozone Connect Base URL — the base URL the API Hub forwards to for this environment.
Authorization Endpoint — the OIDC authorisation URL the customer is redirected to, or an explicit indication that the LFI has adopted CAAP and therefore provides none.
Application layer authentication method — mTLS only, API Key, Client Credentials Grant, or JWT Auth, together with its configured sub-settings: the scope values agreed for Client Credentials, and whether JWT Auth headers are sent on the LFI's calls to the Consent Manager and Headless Heimdall Auth Server.
Optional API family base paths — one row per family (Data Sharing, Service Initiation, Products, Consent Events & Notifications, Health Check), showing the configured path or an explicit “not set”, and next to it the effective forwarded URL worked through against the base URL, so there is nothing left to infer.
Instance identifiers and allocated values — LFI Code, LFI Organisation ID, the Ozone-allocated domains for the environment, and the API Hub egress IP addresses the LFI must allowlist.

Out of scope

Certificates. The certificate set (S1, S3, C4, Sig2, Sig3, C3, S4, Sig4, Enc1) and its JWKS URLs and KIDs are not included. They are held and managed in the Trust Framework, which is their system of record, and surfacing a second view of them raises questions about which one is authoritative. Keeping this proposal to connectivity and authentication keeps it small enough to be worth building; certificates can be taken up separately if the ecosystem wants them.
Editing. Nothing on the page is changeable. See section 04.

One requirement matters more than the rest: the page must be generated from the live configuration the API Hub enforces, not from a stored copy of what was written on the onboarding ticket. A page that can drift from the running configuration is worse than no page, because it would be trusted.

04 · Why view-only

Seeing and changing are different proposals

The obvious next question is whether an LFI should be able to change these values in the portal rather than raising a Service Desk ticket. This proposal deliberately does not ask for that, for three reasons.

The risk profiles are not comparable. Displaying a value the Hub already holds cannot break a live integration. Editing the Ozone Connect Base URL, the Authorization Endpoint, or a base path on a production hub can take an LFI's entire Open Finance estate offline in one click, and a wrong application layer authentication method breaks every call in both directions. Nebras's end-to-end connectivity validation exists precisely because these values are not safe to set unverified.

Editing needs a change-control model that does not exist yet. The portal today documents no role-differentiated permissions — every user granted access sees the same thing. Before any of this becomes editable there has to be an answer on who may change what, whether approval is required, how a change is validated before it takes effect, how it is audited, and whether production is treated differently from pre-production. That is a substantial piece of design in its own right and it should not ride along on a display change.

Read-only is worth having on its own. A meaningful share of the Service Desk traffic these fields generate is not “please change this” but “what is this set to?”. That question disappears entirely with a view, at a fraction of the cost.

That said, we want to know whether editing would be valuable to you, so the second question on the vote form asks exactly that — which fields you would want to change yourself, and what change control your institution would need around them. If the answers show real appetite, we will bring it forward as a separate proposal with the permissions and validation model worked through properly. Please answer it whichever way you vote on this one.

05 · Technical changes

What changes

A read model, a portal page, and documentation. Nothing on the request path, and nothing that an LFI or TPP must implement.

01 · Configuration read model

Expose the effective connectivity and application-layer-authentication configuration for an API Hub instance and environment, read from the configuration the Hub enforces rather than from a stored copy of the onboarding submission. Read-only: no write path is introduced.

02 · Admin Portal Configuration section

A new section in the portal rendering the values in section 03, using the same field names as the onboarding documentation so the two read as one thing. The API family table resolves each path against the base URL and shows the forwarded URL alongside it. Fields that are not set are shown explicitly as not set, with the resulting default path, rather than being omitted.

03 · Documentation

A new page under Admin Portal describing the section and each field it shows, cross-linked from Environment-Specific Configuration, Ozone Connect Base URL, Authorization Endpoint, and Application Layer Authentication, each stating plainly that the configured value can be viewed in the portal and changed via the Service Desk.

06 · Pros

What the view buys

✓Gives an LFI one current answer for its own connectivity configuration, held by the party that actually enforces it, instead of a state that has to be reconstructed by replaying every ticket that ever touched it.
✓Removes a class of Service Desk ticket entirely — the ones that ask what a value is set to rather than asking to change it.
✓Closes the gap that opens after every change ticket, where the newest value is known to whoever raised it and to nobody else.
✓Makes forwarded-URL problems self-diagnosable. Seeing the resolved Ozone Connect URL per API family turns "why is the Hub calling a path that does not exist?" into something the LFI can answer in seconds.
✓Makes pre-production and production drift visible, because each environment's portal shows its own values side by side with the same field names.
✓Access control comes free too: Trust Framework SSO already gates the portal, so no new identity, credential, or permission model is introduced.
✓It is a read model over configuration the API Hub already holds — no change to the Ozone Connect contract, the headers, the schemas, the onboarding process, or anything TPP-facing.
✓Shortens onboarding handover. A new engineer joining an LFI's Open Finance team can read the live configuration instead of being walked through it.

07 · Cons

What it costs

×It is still a build — a read model over the Hub's live configuration, an API, a portal page, and documentation — for information an LFI could in principle keep its own copy of.
×It widens the audience for operational detail. Backend base URLs, internal paths, and egress IP addresses move from an onboarding ticket to a screen visible to everyone the Trust Framework grants portal access, so the access model has to be right before this ships.
×Read-only is the smaller half of the problem. It tells an LFI what is configured without letting it change anything, so a value that is wrong still costs a Service Desk ticket and a wait.