ECID or the existing CIAM ID — which identifier keys the enterprise customer

Prepared for	Canada Segment architecture review, alongside the enterprise ID and entitlement review brief
Purpose	Justify introducing a single Enterprise Customer Identifier (ECID) rather than promoting the existing CIAM ID to the enterprise key
Status	Draft for feedback — no client decision is implied
Builds on	R1.2 · R1.3 · R5.2 · R5.5 · O3
Open questions	23, 40, 42, 43, 44

Position

Introduce ECID as the enterprise customer key, and keep the CIAM ID doing the job it already does well: identifying who authenticated. The two are not competitors. The CIAM ID answers "which login is at the door"; ECID answers "which customer does Manulife hold a relationship with". The target state needs both answers, and only the second can be the key that product relationships, consent, policy decisions and the operational profile hang from.

ECID is issued and governed by the enterprise relationship registry (R1.3), which records each CIAM ID as one verified alias beneath it. CIAM carries ECID in the token as minimum trust context; PingAuthorize reads it as a policy input (R1.2). MVP1 keeps running on the CIAM ID it already has — the change is that new contracts treat the customer key as opaque, so the later swap is non-breaking rather than a re-key of every consumer.

Manulife's own strategy has already drawn this line. The June 2026 unified customer architecture describes the starting position as "zero unified customer identifiers at runtime" — while the UCL deck rates CIAM CAN healthy in all six lines of business. The strategy does not count the CIAM ID as an enterprise customer identifier, and its workstream 07 plans for "interim correlation keys swapped for enterprise relationship ids over time." The GARB ADS puts ECID mapping in Phase 2. Reusing the CIAM ID as the enterprise key would reverse a client position, not just choose an implementation.

Why the CIAM ID cannot carry the enterprise key

1. It exists only where a login exists. An enterprise key must cover every customer the enterprise holds a relationship with, and several of those have no CIAM login, or reach Manulife through another one. The UCL deck's identity row flags Group Benefits as "CIAM CAN · ⚠️ SSO with employer" and Investments as "⚠️ Seg funds and Vitality on Salesforce." Its authentication principles require that "if CIAM is down, BU local auth continues with reduced scope", so BU-local identities persist by design. The back book — products held by customers who never linked them, the population R1.3 routes to MDM — has no CIAM subject to attach to until the customer registers. A key that only exists after digital registration cannot master a relationship that predates it.

2. Its lifecycle follows the credential, not the customer. A CIAM ID is created when someone registers and changes when they register again, lose access, or hold two logins. The strategy's identity-resolution section states that "recovery must not mint a new identity when an existing one should have been recovered" — a rule that is only enforceable when the customer key is separate from the credential. ECID carries explicit allocation, merge, redirect and recovery rules (R5.5); when two logins turn out to be one person, the registry redirects one ECID to the other and every downstream key keeps resolving. With the CIAM ID as the key, the same merge means rewriting product links in six business units. How often this happens today is not in the material we hold — see open question 44.

3. It ties the enterprise key to an identity product. The CIAM ID is minted by ForgeRock. Any re-platform, tenant split or migration inside the Ping support boundary (R5.2) would then re-key every customer relationship in the enterprise. R5.5 applies the same rule to the registry itself: ECID is a business identifier governed by Manulife; it must not be the PingIDM internal _id. Using the IdP's subject as the business key would break that rule one layer up.

4. Relationships are not always a property of one login. In Group Benefits — the MVP1 pilot — a member's right to see a plan derives from their employer's sponsorship, so the enterprise has to express person → member → plan → sponsor. The registered advisor entitlement API (ent-api-adv) serves an audience whose visibility is relationship-derived by definition (O3). The strategy's MDM graph and operational profile are keyed by relationship id for the same reason. A login identifier can be one node in that graph; it cannot be the key for all of it.

5. Its current reach is mostly in the contracts that were flagged. Option B's strongest argument is that the CIAM ID is already everywhere. Look at where: the BU Mapping Service table that the segment assessment's B-02 finds unfit for disclosure, GET /api/v1/investments?ciamId= where customer scope is a caller-chosen parameter (B-01), and /entitlements/{ciamid} and GetUserByCiamID entitlement queries whose decisions are unestablished (open question 33). Those contracts are changing under R1.1 and R1.2 regardless, so the reuse saving is smaller than it looks. To be precise about what ECID does not fix: an ECID passed as a request parameter is exactly as unsafe as a CIAM ID. ECID is a key, not a permission; the customer-verification fix is R1.1's.

What the CIAM ID keeps doing

Introducing ECID removes nothing from CIAM.

• Authentication subject. Every token keeps its CIAM subject under the one token contract in R5.2. ECID is an added claim, not a replacement subject.
• The MVP1 key. The BU Mapping Service and the first PingAuthorize decision stay keyed on the CIAM ID until ECID exists (R1.2). Nothing in MVP1 waits for ECID.
• The seed for ECID. At onboarding, the registry allocates or reuses ECID from the verified CIAM identity — the provisioning link in R1.3, which needs no MDM merge and no merge consent.
• A recorded alias. The registry stores the CIAM ID as a sourceIdentity beneath ECID, with its verification state and effective dates, alongside BU-local identifiers such as policy, membership and CIF numbers.

Pros and cons

Option A — Introduce ECID, with CIAM ID as an alias (recommended)

Pros

• Covers every customer relationship, including those with no CIAM login, employer-federated members, Salesforce-held products and the unlinked back book.
• Survives credential events: recovery, re-registration and duplicate logins become a governed merge and redirect inside one registry, not a re-key across six business units.
• Decouples the enterprise key from ForgeRock, so an IdP migration or tenant change does not touch product relationships, consent records or policy history.
• Matches the client's own strategy (workstream 07, ADS Phase 2), the MDM graph and the operational profile's relationship-id keying, so it needs no position reversed.
• Gives PingAuthorize, OneTrust consent and the operational profile one stable join key, and gives regulatory replay one identifier to trace a decision through.
• Lets the BU Mapping Service survive as a compatibility read API while its manually authored table stops being the source of record (R5.5).
• Can start without MDM: new customers get ECID at onboarding from the verified CIAM identity; only the back book depends on match and merge.

Cons

• A new system of record with its own lifecycle — allocation, merge, redirect, recovery — to design, run and staff. Custom delivery remains even on PingIDM (R5.5).
• Needs one named owner. The strategy assigns auto-association to MDM + BU, which is not an operating model, and open question 43 leaves the owner undecided.
• A migration: BU Mapping rows must be reconciled to ECID, and every CIAM-ID-keyed consumer must either accept ECID or read it through a compatibility facade.
• A token change: CIAM must carry ECID as a claim, which means a claim source and a defined behaviour when no ECID exists yet.
• Depends on per-BU ownership signals that do not yet exist — onboarding is rated red in all six lines of business (open question 42) — and on a date the client has written three ways (open question 40).
• A universal cross-BU join key raises the privacy stakes. ECID must stay out of URLs, trace spans and logs (R5.4) and must not become a de facto permission.
• Two identifiers run side by side through the transition, and every contract has to say which one it carries.

Option B — Promote the existing CIAM ID to the enterprise key

Pros

• Exists today, is issued for every registered customer, and is already in every token the dashboard validates.
• Already keys the BU Mapping Service, the Seg Funds API and two registered entitlement queries, so no migration is needed for those consumers.
• No new identifier, registry or allocation service to build, own or run; operational ownership stays with the Canada Digital Identity platform that already holds CIAM.
• No token-claim change and no dual-identifier transition period.
• Removes the ECID programme from the critical path, which matters if Phase 2 slips or stays unfunded (open question 23).

Cons

• Cannot key customers without a CIAM login: employer-federated GB members, Salesforce-held products, BU-local identities and the unlinked back book.
• Inherits the credential lifecycle. Recovery or re-registration that mints a new CIAM ID silently orphans every product link, consent record and policy history keyed to the old one.
• Merging duplicate logins means re-keying data across six business units with no redirect mechanism.
• Couples every enterprise relationship to ForgeRock's subject format; an IdP change becomes an enterprise data migration.
• Reverses the client's strategy (workstream 07, ADS Phase 2) and conflicts with the MDM graph and operational profile, which key on relationship id — a decision open question 43 would have to take explicitly.
• Entrenches the contracts the assessment flagged: the BU Mapping table stays both the resolution record and the disclosure control (B-02), and ?ciamId= stays the customer-scope pattern that business units copy.
• Pushes identity resolution back to the BU: without an enterprise key, each line of business keeps matching its own records to a login, which is the manual linking problem the Chief Architect named as the primary pain point.

The cost of keeping the decision cheap

Most of Option A's cost is avoidable today. If MVP1's new contracts name the customer key generically and treat it as opaque — rather than spelling ciamId into paths, parameters and schemas — then the swap the strategy assumes is a value change, not a contract change. Whether the MVP's BFF and Integration API contracts already have that property is unverified, and it is the cheapest item on this page to check (D2.1 forward-compatibility question).

What would change this recommendation

• CIAM is already 1:1 with the customer. If Manulife can show that every relationship-holding customer has exactly one CIAM ID, that recovery never mints a new one, and that GB sponsor-managed members are CIAM subjects, reasons 1 and 2 weaken substantially. Reason 3 — IdP coupling — still stands, but the case becomes a judgment on migration risk rather than coverage.
• Phase 2 is unfunded indefinitely. Then Option B is the outcome by default. Record it as a decision, and still make the contracts opaque so the choice can be revisited.
• Resolution moves to MDM (open question 43). The case for ECID stands; only its owner changes from the registry to MDM.