O2 · The two service-principal hops
| Artifact affected | MVP architecture diagram — The MVP — Unified Dashboard, as submitted to GARB (Lucid), labelled connectors |
| Source | GARB ADS (MVP Phase), authentication table, pp. 10–11 |
| Corroborated by | Segment architecture assessment B-01 and B-02 · experience map runtime gaps |
| Position taken elsewhere | R1.1 · R1.2 |
| Status | Standing — this is the walkthrough for the labelled connectors on the MVP diagram |
The ADS's own authentication table (pp. 10–11) has four rows. Two are marked (Existing); two are what the MVP builds — and those two are the labelled connectors.
| Hop | Authenticates as | Marked |
|---|---|---|
| Customer → CIAM | Customer identity — Manulife ID, OIDC/OAuth 2.0 | Existing |
| Unified Dashboard → Integration API | Service principal / application identity | New |
| Integration API → BU backend services | Service principal | New |
| Unified Dashboard → product portals | Authenticated customer identity — SSO token federation | Existing |
Walking the login path as the diagram draws it:
- The customer authenticates at CIAM. Real customer identity, and the green connectors carry it that far.
- The Dashboard Shell holds the session and still knows who the customer is.
- First red hop. The Shell calls the Integration API. The credential on the wire now says "I am the Unified Dashboard application" — not "I am this customer". The customer's identity stops being a credential and becomes a parameter.
- Second red hop. The Integration API calls each BU Data API, again service-to-service. The BU API sees the Integration API calling, and is told which customer to answer for. The ADS's own signature shows how:
GET /api/v1/investments?ciamId=— which is why that's printed on the Seg Funds box rather than paraphrased.
The consequence. A BU Data API that receives no customer credential cannot make an authorization decision about the customer — it can only trust its caller. So which customer's balance gets rendered is decided by whoever sets ciamId, which is the Integration API, reading the BU Mapping Service — a table built by customers linking products by hand. The assessment classes this as OWASP API1 broken object-level authorization (B-01), and adds in B-02 that the table has no integrity control, change audit or attestation.
So "no change to authorization" is true for row four and false for rows two and three. Row four is a customer clicking through to a BU portal to transact — unchanged, correctly. Rows two and three are display, they're new, and the boundary moved into a component the ADS doesn't describe as enforcing it.
That's the whole of Gopi's ask in one picture: the identity that CIAM establishes doesn't survive to where the data lives. And the fix already exists in Manulife's estate — the API Mediation proposal marks JWT Exchange mandatory for the Inter layer, and gb-core-authx is already running as an RFC 8693 token-exchange service in Group Benefits. That's R1.1.