O3 · "Enterprise ID and entitlement" is three problems wearing one name

Artifact affected	The recommendations set — theme R1 — and the Sept 23 readout
Source	Presentation review with the client, 2026-09-14 · resources/meetings/2026-09-14-presentation-review.pdf
Sources in conflict	UCL capabilities and HLD · GARB ADS · API Mediation proposal · API landscape · capability roadmap
Position taken elsewhere	R1.1 · R1.2 · R1.3 · R5.2 — one per part below, plus the product set
Open questions	Raises 41 and 42 · raises 43 · depends on 17, 33 and 40
Status	Standing — this is our reconstruction of the ask, not a client statement. Confirm it with the Chief Architect before it is presented. Part 1's authority is now settled: MDM is the enterprise relationship registry and ECID is rel_id (ADR-0006)

The ask

The 2026-09-14 presentation review closed on one instruction. Its written takeaway:

Core technical priority is establishing a central trust service using an Identity Provider (IDP) as the enterprise source of truth. Gopi highlighted that auto-linking products across Lines of Business (LOBs) is a primary pain point because enterprise IDs have complex, interconnected entitlements.

And, in the running notes: "focus on identity & entitlement, bring mediation layer (give hypothesis) — he never arrived at what that should look like, pain point, that's what they couldn't agree on it." Two lines earlier: "IDP is where he landed, hence APM layer."

Read the second half of that first. We are not being asked to choose an identity provider — that is settled and every source says so. We are being asked for the thing the Chief Architect has not been able to get his own organisation to agree on, and the meeting record says plainly that he has not converged on it either.

The note is a summary, not a transcript. Nothing quoted above is verbatim beyond the takeaway block, and the running notes are shorthand taken in the room. That matters because this page attributes a position to a named executive: treat every phrase as our paraphrase of his until he confirms it.

The problem statement

Manulife can identify a customer once, and cannot say what that identity is worth.

One authority — CIAM CAN — establishes who is at the door, consistently, across all six lines of business. No authority establishes what they hold, decides what they may see, or proves either fact to the system that holds the data. Those three gaps are what "enterprise ID and entitlement" names. Each is owned by a different party, implemented differently in every business unit, or owned by nobody at all.

The three parts, and the state of each:

	The question	Who answers it today	What the corpus gives us
1 · Resolution	Which products does this identity hold?	The customer, by hand	A goal, no mechanism
2 · Decision	May this identity be shown this product?	A row in the BU Mapping table	A stated position, unowned and undated
3 · Handoff	How does the customer enter the BU security boundary?	OIDC SSO for a launched app; nothing trustworthy for aggregated API calls	Two paths the MVP treats as one

They are one problem because the record that resolves is the record that decides. The BU Mapping table is simultaneously the answer to part 1 and the control for part 2, which is precisely the segment assessment's B-02 — a mapping fit for navigation carrying a disclosure decision it was never designed to carry. Automating part 1 without separating it from part 2 automates the defect.

Why agreement never came

Five client sources use "entitlement" for five different contracts. An architecture forum cannot converge on a word that changes meaning between speakers.

Used to mean	Where it says so	The contract implied
Product ownership — this customer holds a GB plan	ADS: BU Mapping Service, POST /mappings/search, populated by a "manual customer product-linking process" · experience map: ext-cdt-account-linking	A fact, sourced from a system of record
Coarse access — this identity may be shown GB	UCL deck: "enterprise decides 'can access product'" · API landscape: int-cdt-cet-di-can-ent-api-{adv,cp,gb}-prod, POST /entitled	A policy decision over that fact
Fine-grained action — this identity may transact	UCL deck: "BU decides 'can do action'" · June strategy: "what the customer sees is not what the customer can do"	A decision inside the BU, over its own resources
A set to retrieve — what is this ID entitled to	API landscape: rtl-can-passportbff /v2/admin/ondemand/entitlements/{ciamid} · gip-can-entitlement /v1/Entitlements/GetUserByCiamID	A query returning a list, not a yes or no
A provisioning input — what to set up at onboarding	UCL deck current-state matrix, Retirement column: onboarding orchestration is "Local based on entitlement"	A BU-internal process input

A sixth reading arrives from the product side. In a composed portal, "should this tile appear?" is equally answerable by a feature flag — the ADS's stack table names Unleash for runtime toggles — and the same meeting asked us to flush out "feature flagging, entitlement managing, and LOB linking" in one breath, with the note that "they are different approaches to the same problem." They are not. They are three mechanisms that produce the same pixel and carry entirely different obligations: a flag is a release control, a link is a fact, an entitlement is a disclosure decision that has to be logged and attested.

Separating those meanings is most of the deliverable. It is also the cheapest thing on this page to do, and the only one that does not need a client decision first.

Part 1 — resolution, and why it is genuinely hard

Auto-linking looks like a join and is not one, and the takeaway states the reason: "enterprise IDs have complex, interconnected entitlements." Two pieces of evidence make that concrete.

There is no shared ownership signal to join on. The UCL deck's current-state matrix — the only per-BU current state in the corpus — rates onboarding and provisioning orchestration red in all six lines of business, with six different mechanisms: policy and membership based (GB), CIF based (Bank), policy based (Insurance, Affinity), vendor specific (Wealth), local based on entitlement (Retirement). The same matrix rates identity and authentication healthy in all six. The identity layer is the strong one; provisioning is the problem, which is preliminary observation 8.

Ownership is not always a property of the person. The UCL deck lists B2B relationship traversal as a capability of its Enterprise Entitlement Service, and it is not decoration. In Group Benefits — MVP1's pilot — a member's right to see their benefits derives from their employer's plan sponsorship: the matrix flags GB identity as "CIAM CAN · ⚠️ SSO with employer", and the pilot's listed dependencies are "MDM participation, CIAM resolution for sponsor-managed authentication, sponsor contractual obligations." An enterprise ID that resolves to a person cannot express person → member → plan → sponsor without traversing a relationship. The estate has already met this shape at least once: one of the three entitlement APIs registered in PROD serves the advisor audience (ent-api-adv), and an advisor's right to see a client's position is relationship-derived by definition.

GB is also the only business unit with no match and merge and product data "in multiple applications, not mapped." The hardest BU to resolve is the one the pilot starts with.

What the corpus offers for this part is a goal and a date, not a mechanism. The UCL deck's first deliverable is "automatic product linking and delinking" for GB/GR; the capability roadmap puts "one verified identity" in Next (2027–2028) against a Today column that reads "manual product linking by customers"; the ADS puts auto-linking and ECID in Phase 2. Three dates, which is open question 40. No artifact we hold describes how a product-ownership event leaves a BU system and reaches the enterprise.

Part 2 — decision, which the client has already answered on paper

One sentence on the UCL deck's Enterprise Entitlement slide is Manulife's position:

Enterprise coarse, BU fine — enterprise decides 'can access product'; BU decides 'can do action'

With supporting principles on the same slide: deny by default, externalized authorization, consent as a mandatory PDP input, relationship-derived entitlements, full replay for regulatory review. The June strategy names PingAuthorize as the decision point. The API landscape shows a policy administration point, a distribution path and per-audience decision endpoints already registered in PROD on the Canada Digital Identity platform.

Three things are missing, and none of them is the position:

• An owner and a date. The UCL deck's path-to-solution slide shows validation with BU IT architects, VPs and CIOs as not yet done. The readiness review puts "Unified Entitlements · PDP · centralized authorization" and "Enterprise customer context token provider" on the MVP1 NOT-IN-SCOPE list, and lists WS 1 Unified Identity MVP among the workstreams cancelled in the CAUCE-to-CAUEX replan with no inheritor — open question 15.
• A connection to the thing being built. No artifact links the registered entitlement platform to the unified dashboard, and what those endpoints actually decide is unestablished — open question 33.
• Agreement from the MVP. The ADS states "no change to authorization" and reads the manual mapping table instead. The disagreement on this part is between two client documents, not between Konrad and Manulife — which is the single most useful thing to say out loud in the readout.

Part 3 — handoff, with two paths conflated

The ADS documents one safe handoff and one unsafe one. When the customer opens an existing product application, the customer remains authenticated through SSO federation. When the new dashboard aggregates BU data, both new hops carry service principal, and the Seg Funds contract GET /api/v1/investments?ciamId= makes customer scope a parameter the caller chooses. That is B-01, and the experience map records it running: the PROD path strips x-federated-id, while gb-core-authx is not wired and memberId is hardcoded.

The launch-first recommendation chooses the safe path for MVP1: the portal opens an independently secured BU application, which runs its own OIDC Authorization Code + PKCE flow against the shared ForgeRock CIAM session. Protected BU data stays inside that application. RFC 8693 remains the later answer if the portal restores customer-data aggregation; SSO does not make a server-to-server call customer-delegated.

Why the mediation layer is in the same sentence

"IDP is where he landed, hence APM layer." The chain is coherent for API aggregation: if one IdP is the enterprise source of truth, something has to carry that truth to every business unit, and the mediation layer is the only surface every server-to-server call already crosses. It is not needed for front-channel OIDC SSO when the customer enters the BU application.

And the same proposal shows where the chain stops. Slide 5 marks JWT Exchange mandatory — the transport for an answer. It also draws a policy decisioning point whose box contents are rendered identical to the secrets-management box beside it: "Authorization Server Credentials, Other Credentials." No policy artifact, no policy language, no information point. The deck specifies how the decision travels and leaves the thing that makes it as an empty box.

That is our reading of "he never arrived at what that should look like." The hypothesis being asked for is the content of that box and its relationship to the layer around it — which component decides, on what inputs, and how the answer reaches a BU Data API in a form that system can verify. Three prior questions gate it: whether the proposal is live at all (29), whether the mediation layer orchestrates (31), and whether the model is centralized, federated or the two-tier split its own slide 4 draws (36).

Where this leaves our recommendations

Our R1 theme now answers all three parts. It answered two when this page was written, and R1.3 was written to close the third.

Part	Our position
1 · Resolution	R1.3 — derive ownership from a business-unit event, and split the provisioning link from the entity-resolution one
2 · Decision	R1.2 — PingAuthorize decides enterprise visibility; the BFF enforces it and the launched BU app and APIs retain action authorization
3 · Handoff	R1.1 — launch each BU application through one CIAM SSO under one token contract; use exchange later if aggregation returns
Products	R5.2 — ForgeRock and PingAuthorize in one support boundary; gb-core-authx retained for future delegated API calls

The gap that produced R1.3 was one of altitude, not oversight. R1.2 scopes itself to MVP1, where auto-linking is out of scope, and at that altitude its exclusion — "we are not reopening it" — is correct. The ask is target state, where resolution is the half named first in the room.

The R1 theme now carries both altitudes: the MVP sequencing keeps manual linking as a controlled fallback and starts with OIDC SSO launch. The target state assigns rel_id (the ADS's ECID) and accepted relationships to MDM as the enterprise relationship registry (ADR-0006). Visibility goes to PingAuthorize and action authorization to the BU. Delegated API calls remain a later contract rather than being mislabeled as SSO. The review brief presents that foundation for client feedback.

What would show this reading is wrong

• "Enterprise ID" means the identifier, not what it resolves to. If the ask is ECID and entity resolution as an MDM problem, part 1 belongs to the MDM workstream and our contribution is parts 2 and 3 plus the seam between them. ADR-0006 confirms this for authority: part 1 is MDM's. Our part 1 contribution narrows to the BU ownership event MDM receives.
• "Entitlement" already has an agreed definition we have not been shown. The overload table is built from five artifacts; a sixth may settle it.
• The Enterprise Entitlement Service is funded and staffed. Then part 2 is a design question inside somebody else's programme, and the ask is integration, not architecture.
• The mediation layer is settled and the PDP box has since been specified. The proposal is eighteen months old and nothing written since cites it — open question 29.

Each is one question to a named person, and all four are in the same conversation.