R4.2 · The mediation layer must carry data protection, not only transport

Theme	R4 · API mediation
Domain	Security and data architecture
Status	Proposed
Needs client validation	Yes
Anchored in	Assessment findings A-02, E-01, domain G · the ADS residency NFR · the API Mediation proposal slides 4 and 5
Open questions	Depends on 21, 23 and 26; sharpens 29
Deliverables	D2.5 area 2 · D2.1
Reinforces	R1.1 — controls the later aggregation path that R1.1 keeps out of the launch-first MVP

Concern

The proposal puts data protection on the gateway the dashboard does not use, mandates logging on the one it does, and enforces policy against a decision point that holds no policies.

Data Protection is drawn on the wrong gateway. Slide 4 lists it as a capability of the External Egress API gateways only. It is not listed on the Internal API Gateways. The Unified Dashboard's cross-BU aggregation is internal, inter-application traffic — so the one capability that would enforce field-level redaction and classification does not sit on the path carrying Highly Confidential cross-BU balances.

Message Handling has no redaction anywhere in it. The group is schema validation, input sanitization, message transformation, protocol translation and format translation. No redaction, no masking, no classification tagging. Domain G of the segment assessment already finds no redaction design in the MVP; the mediation layer does not add one.

Mandatory logging at a chokepoint is a new data store. Logging is mandatory at the Inter layer alongside metrics and request tracing. Logging every request where payloads are customer investment, wealth and portfolio data the ADS itself classifies Highly Confidential creates a new copy of that data. A-02's logic applies verbatim — "a cache of Highly Confidential data is a data store" — and so do its consequences: encryption at rest, key custody, residency, retention, purge and classification. The ADS's residency NFR is that all PII resides in Canada and PII in transit is not accessible outside Canada. The deck's "Enterprise Observability Platform" is unnamed; the ADS names New Relic, PromStack and ADX. E-01 already records no PIA and no Quebec Law 25 position.

Mandatory logging plus no redaction capability is the combination that guarantees the problem rather than risking it.

The policy decisioning point has no policies. Policy Enforcement is a mandatory Security capability. The reference architecture's Policy Decisioning Point box lists its contents as "Authorization Server Credentials, Other Credentials" — identical to the Secrets Management box above it. No policy artifact, no policy language, no policy information point, no decision model. A mandatory enforcement point in front of an undefined decision point enforces nothing.

The register that would make it work is drawn and unused. The governance box carries an AuthZ Scopes Catalog. Nothing in the deck references it.

Recommendation

Make the layer accountable for the data it carries and copies, not only for moving it. Four commitments:

Add Data Protection to the Internal API Gateways, and put field-level redaction and data classification tagging into Message Handling. Cross-BU aggregation is internal traffic; that is where the control has to be. This is the one change that turns a chokepoint from a liability into an asset — a mediation layer is the best place in the estate to enforce redaction once, centrally, and that argument only works if redaction is a capability of the layer.

Write the observability data contract before the layer carries production traffic — what is logged, what is redacted at source, where logs reside, under what retention, at what classification, on which named platform. Mandatory logging without that contract is an undeclared data store in a regulated estate.

Populate the PDP. Name the product, the policy language, the policy information points and the decision model, and state whether it is the PingAuthorize PDP named in the June 2026 unified customer architecture. If it is, these two documents describe the same component and neither says so — which is worth more to this engagement than either document alone. Until then, treat "Policy Enforcement" as an unimplemented capability rather than a control.

Make the AuthZ Scopes Catalog the register of record for exchange audiences and per-LOB scopes. It is already in the proposal's governance set and is the artifact a later delegated-aggregation path needs in order to target an audience.

Token exchange is not restated here. R1.1 keeps it off the front-channel SSO launch path and preserves it for a later release that aggregates protected BU data. R4.2 supplies the data controls that release still needs: what the layer may copy, log and disclose.

What it changes

It gives the classification question a second surface. Open question 21 asks what the cross-BU aggregate is classified as, distinct from each source record. Under this recommendation the gateway logs are a third artifact needing the same answer, and the answer has to be given once for all three.

It moves redaction from seven implementations to one. Today each BU API would have to redact for a caller it cannot identify. Centralised at the mediation layer, redaction is written against a classification tag and applied uniformly — which is the strongest argument for the layer that the deck does not make.

It reconciles two client documents that describe the same component. The proposal's PDP and the June 2026 strategy's PingAuthorize are either the same decision point or two, and nobody has said which.

What we are not recommending

Turning mandatory logging off. Observability at the chokepoint is the right default and it is what makes the ten-hop path traceable — domain G's other finding. The recommendation is that the contract exists, not that the logging stops.

Redaction at the mediation layer instead of at source. Both. Classification tagging belongs with the system that owns the record; enforcement belongs at the layer that sees every consumer. A layer redacting fields it has to infer is guessing.

Blocking the layer on the Privacy Impact Assessment. Open question 26 is a dependency with a named owner and its own clock. Naming the data contract is what lets the PIA be written; waiting for the PIA to define the contract inverts it.

Specifying the policies. SOW Schedule "A" §3.0 puts implementation-level solution design out of scope. We recommend that the PDP be defined and by whom. We do not write its rules.

Dependencies and open questions

• Open question 23 — whether PingAuthorize is funded and staffed or aspirational. It decides whether "populate the PDP" is a naming exercise or a programme.
• Open question 26 — the written Privacy Office position on cross-BU aggregation and Quebec Law 25. Gateway logging widens what that position has to cover.
• Open question 21 — the classification of the cross-BU aggregate.
• CR-40 — the authorization server and PDP product decisions, and the enterprise observability platform's residency and retention position.