R5.5 · Assess PingIDM as the enterprise relationship registry implementation

Theme	R5 · Technology stack
Domain	Identity and access management
Status	Withdrawn — Manulife made MDM the enterprise relationship registry (ADR-0006)
Needs client validation	No
Reinforces	R1.3 — the logical registry this page gives a candidate implementation
Anchored in	The registered ForgeRock IDM and BU Mapping APIs in the API landscape · the June 2026 strategy's mastered relationship graph and operational projection · the UCL HLD's customer identifiers and real-time BU sync · the API Mediation proposal
Open questions	Depends on 23, 29, 42 and 43; constrained by 31
Deliverables	D2.1 · D2.4 · D2.5 · D3.1

Withdrawn

Manulife ruled on 2026-10-12 that Informatica MDM is the enterprise relationship registry, and that ECID and rel_id are one identifier (ADR-0006). The role this page assessed PingIDM for no longer exists. ForgeRock IDM keeps the role the target architecture draft gives it, an event-fed crosswalk replica that "never matches or mints".

Three properties argued below still apply, and they now constrain MDM's intake contract rather than a PingIDM build. Business units write through a Manulife-owned contract, never through the product's own endpoints. A relationship end is an event, just as a start is. Reconciliation is the repair path, not a substitute for the event. R1.3 carries them forward. The page below is unchanged from when it was proposed, and it uses ECID where it now means rel_id.

Concern

The target state needs an authoritative lifecycle for ECID and verified customer-to-product relationships, but the client material distributes that responsibility across several components and names no system of record for it.

The GARB ADS has a CIAM-owned BU Mapping Service and places ECID mapping, identity resolution and auto-linking in Phase 2. The June strategy gives MDM the mastered relationship graph, assigns product auto-association to MDM + BU, and projects a runtime profile from it. The UCL HLD puts customer identifiers and real-time BU synchronization in Customer Profile Management while giving the Enterprise Entitlement Service B2B relationship traversal. These are compatible capabilities without an agreed ownership boundary.

The API landscape records both ForgeRock IDM (ext-cdt-cet-di-can-idm-prod) and the BU Mapping Service (ext-cdt-cet-di-can-bu-mapping-prod) in the estate. That proves registered endpoints, not how IDM is configured, what scale it carries, or whether it is suitable as the relationship authority. Neither an Enterprise Relationship Registry nor a Relationship API is named in client material. Both are Konrad-proposed logical components.

Recommendation

Assess PingIDM as the first physical implementation candidate for the enterprise relationship registry, behind a Manulife-owned relationship ingestion service. Do not select it until product-fit testing passes.

PingIDM is the first candidate because ForgeRock IDM is already registered in the estate and its native model covers much of the identity-specific foundation: managed objects, object relationships, REST access, synchronization and reconciliation, and audit events. Reusing those capabilities can avoid building another identity repository while keeping the registry inside the identity platform's support boundary.

The recommendation is drawn in two Lucid views:

• Enterprise Relationship Registry — responsibility and implementation options
• New Product Relationship — PingIDM-backed registry flow

The implementation boundary

PingIDM would be the governed write store, not the public enterprise contract. A proposed Relationship Ingestion Service would sit in front of it:

BU event or command → relationship ingestion → PingIDM → operational projection → portal and PingAuthorize

The service owns Manulife's domain behaviour: source authorization, schema validation, idempotency, ECID lifecycle rules, relationship creation and termination, MDM routing, and exception state. PingIDM supplies repository and identity-management primitives underneath that contract.

Business units should not call generic PingIDM endpoints directly. A stable enterprise contract prevents six BU integrations from depending on PingIDM object paths, internal identifiers or product version. It also lets Manulife replace the backing technology without changing every producer.

Technical shape

Managed objects and relationships

Use small, independently governed managed objects rather than putting a customer 360 or a growing product array on the CIAM user:

• enterpriseCustomer — immutable ECID, lifecycle state, merge redirect and recovery status. ECID is a business identifier governed by Manulife; it must not be the PingIDM internal _id.
• sourceIdentity — CIAM subject or BU-local identifier, source namespace, verification state and effective dates.
• productRelationship — relationship ID, ECID reference, source system, product type and source product key, active or terminated state, effective dates, source event ID and provenance.

PingIDM relationships can link these objects, validate references and carry relationship metadata. A first-class productRelationship object is preferable to embedding every product in one customer record: business units can update their own relationships independently, each relationship has its own lifecycle and audit history, and concurrent writes do not contend on one large profile.

Ping documents managed-object relationship references, custom reference properties and validation in Configuring relationships. Relationship validation has query cost, so the product-fit test must decide where it is required rather than enabling it indiscriminately.

New relationship write path

For a new product:

1. The BU system of record emits ProductRelationshipStarted with source, identity reference, product reference, effective time and an immutable event ID.
2. The ingestion boundary authenticates the BU, confirms that it may author that product domain, validates the contract and treats a repeated event ID as a no-op.
3. If the identity is known and unambiguous, the service allocates or reuses ECID and creates the active relationship with provenance.
4. If the identity is unknown or ambiguous, the relationship remains pending until MDM returns a verified resolution outcome. No verified match means no active product visibility.
5. The accepted write produces RelationshipChanged, updates the operational ownership projection and records the audit chain.
6. PingAuthorize consumes the projected ownership as policy input; it does not issue ECID or master the relationship.

ProductRelationshipEnded follows the same contract and terminates the relationship. The end event is as important as the start: it gives the current manual mapping's stale-row problem an explicit lifecycle.

Events, reconciliation and audit

Events provide timeliness; reconciliation repairs missed or inconsistent events. A scheduled PingIDM reconciliation can compare each BU's authoritative holdings with registry relationships, identify missing or orphaned associations, repair deterministic differences and route ambiguity to MDM or stewardship. PingIDM exposes reconciliation runs and persisted associations over REST, as documented in Manage reconciliation. Reconciliation is the repair path, not a substitute for the BU ownership event.

PingIDM audit topics can record access, activity, authentication, configuration, reconciliation and synchronization events. Activity records include the caller, before and after state, changed fields, revision and transaction identifiers. Reconciliation audit is not enabled by default and must be configured deliberately; regulatory retention or tamper evidence may still require export to Manulife's enterprise audit platform. See Audit event topics.

Runtime projection

Do not place PingIDM on every portal request. Publish a low-latency identity-and-ownership projection for navigation and policy input. The portal reads current relationships from the projection; PingAuthorize evaluates enterprise visibility; the BU API retains object- and action-level authorization. CIAM carries only the minimum trust context, such as subject and ECID, rather than a full relationship graph in a token.

The existing BU Mapping Service can remain as a compatibility API over that projection while consumers migrate. Its read contract may survive; its manually authored table does not remain the source of record.

API mediation placement

The Relationship Ingestion Service can be exposed through Manulife's Inter API Mediation Layer; its domain logic and state should not be implemented as gateway policy.

For synchronous commands and queries, the intended path is:

BU → LOB Intra mediation → Inter API mediation → Relationship Ingestion Service → PingIDM

The Inter layer applies the capabilities the mediation proposal marks mandatory: JWT validation and exchange, schema validation, input sanitization, policy enforcement, logging, metrics and request tracing. The service retains idempotency, ECID rules, MDM routing, relationship state and exceptions. Putting those durable rules in APIM would turn a gateway into a business-process engine and couple the relationship lifecycle to policy configuration; the proposal itself marks orchestration optional.

For a true ProductRelationshipStarted event, use the enterprise event platform if one is endorsed:

BU event → event broker → relationship consumer → PingIDM

API mediation can still front administration, replay, query and transitional ingestion endpoints. It should not be forced into broker traffic unless Manulife's mediation product explicitly supports and governs event transport.

How this changes the current problem

This implementation makes R1.3 executable:

• The BU that creates a product authors the ownership fact; the customer no longer builds the enterprise relationship by hand.
• Deterministic onboarding does not wait for MDM. MDM remains responsible for ambiguous and legacy identity resolution.
• ECID, aliases, relationship status and provenance receive one governed lifecycle.
• Termination events and reconciliation expose stale or missing links.
• A CIAM-ID-to-product key can move to ECID without changing every producer and consumer.
• PingAuthorize receives verified ownership rather than treating a navigation mapping as permission.
• The current manual linking journey becomes an exception path with evidence, not the default write path.

The registry does not solve R1.1: BU applications still need their own OIDC client and session under the shared CIAM SSO contract. If protected aggregation is introduced later, RFC 8693 is still required so the BU API can verify the customer. The registry is not an authorization service; PingAuthorize and the BU remain the decision authorities.

Custom delivery remains

PingIDM reduces repository work; it does not supply Manulife's relationship domain out of the box. Delivery still includes:

• ECID allocation, merge, redirect and recovery rules;
• the Relationship Ingestion API and event contract;
• BU-specific adapters and source-authority policy;
• event idempotency, replay and exception handling;
• MDM resolution integration;
• operational projection and change publication;
• migration and reconciliation of the BU Mapping data;
• access controls, observability, HA/DR and audit retention.

The long pole remains the six BU integrations, not the managed-object schema.

Product-fit gate

Before selecting PingIDM, prove:

• the installed ForgeRock/PingIDM version, topology, owner and support horizon;
• relationship cardinality, query shape and write throughput at enterprise scale;
• concurrency behaviour when several BUs update one customer;
• event replay, idempotency and reconciliation performance;
• HA, DR, Canadian residency, encryption and audit-retention requirements;
• whether shallow identity-to-product traversal is sufficient.

The last point is a real boundary. PingIDM is a plausible registry for ECID, aliases and operational relationship links; it is not automatically the replacement for the June strategy's MDM property graph. If sponsor, employer, member, beneficiary and policy traversal requires deep graph queries, MDM retains that graph and the registry stores only accepted operational links.

What we are not recommending

Selecting PingIDM on inventory evidence alone. A registered API is enough to justify assessment, not selection.

Putting the customer 360 in PingIDM. Profile, financial and product data remain in their authoritative systems and operational serving stores.

Exposing raw PingIDM REST endpoints to business units. The enterprise contract belongs to Manulife, not to the product.

Putting relationship workflow in API gateway policy. Mediation governs the call; the domain service owns the lifecycle.

Replacing MDM or PingAuthorize. MDM resolves ambiguity; PingAuthorize decides visibility. The registry records the accepted fact between them.

Dependencies and open questions

• Confirm what ext-cdt-cet-di-can-idm-prod does today, its product version, owner, repository and service levels. The API inventory does not answer those questions.
• Confirm whether the BU Mapping Service can become a projection or migration facade without breaking current consumers.
• Close open question 42 for each BU: what is the earliest authoritative ownership signal, and can it be emitted?
• Close open question 29: whether the mediation proposal is live, and whether the Inter layer fronts or replaces the current APIM estate.
• Name the event platform and its ownership before making ProductRelationshipStarted a transport decision rather than an architecture contract.
• Assign one owner for the registry, ECID lifecycle and exception queue. MDM + BU is not an operating model.