Architecture FAQ

Questions raised while preparing the Unified Portal architecture recommendations presentation. This page will grow as stakeholders ask for clarification.

Relationship registry and runtime projection

Informatica MDM is the enterprise relationship registry, and ECID is rel_id (ADR-0006). Where a question below says "the registry", it means MDM.

What does “the registry publishes a low-latency projection for the portal and PingAuthorize, keeping runtime access separate from governed writes” mean?

MDM, the registry, publishes approved customer-to-product relationships as events. The operational profile projects them into a fast, read-only view for the portal and PingAuthorize. Only authorized processes can add or change the records in MDM.

The projection is the view used to serve requests. MDM is where relationships are validated, recorded, corrected and ended.

What is a low-latency projection for the portal?

A projection is a simplified view of MDM's data, not a project. It answers runtime questions such as:

Which approved products are linked to rel_id 123?

“Low latency” means the portal can receive that answer quickly enough to render the customer experience without querying MDM on every page load. The target draft's projection is the D3 Cosmos DB profile. The projection could be implemented as a read-only API, database view or cache; that choice remains implementation design.

What is an example of runtime access being separate from a governed write?

1. Group Benefits reports that rel_id 123 has plan GB456.
2. The ingestion process authenticates the source and validates the identity evidence, product relationship, effective dates and provenance.
3. MDM records the approved relationship. This is the governed write.
4. MDM publishes the change, and the projection is updated with the current approved relationship.
5. When the customer opens the portal, the portal reads the relationship from the projection. This is runtime access.

The portal may display the relationship, but it cannot create or modify the source record. PingAuthorize may use the same projected fact as policy input, but it does not master the relationship.

See ADR-0006. R5.5, which proposed a separate PingIDM-backed registry, is withdrawn.

What does “if the connection is deterministic” mean?

Trusted evidence links the product relationship to one specific CIAM customer without guessing or manual matching.

• Deterministic: a signed-in customer purchases a policy and the transaction records the authenticated CIAM subject.
• Ambiguous: a legacy policy has only a name and date of birth that could match several people.

If the evidence identifies one customer unambiguously, MDM can accept the relationship by a deterministic match. If it does not, the relationship remains pending while MDM's match and merge, or stewardship, resolves the identity.

Resolution, decision and propagation

How does the resolution path change, and why?

Today: The customer enters a business-unit identifier manually. The resulting mapping row is treated as evidence that the customer owns the product. A relationship may be absent if the customer never completes the journey, or stale if it later changes.

Recommendation: The business unit asserts the product relationship. Verified evidence binds it to the authenticated CIAM subject, and MDM records the accepted relationship and its lifecycle. Ambiguous cases go to MDM's match and merge or to stewardship.

Reason: Product ownership should originate with the business unit that owns the product record, not with a manual linking journey. The resulting relationship is more complete, current and auditable.

See R1.3 · Product ownership signal.

How does the visibility decision change, and why?

Today: The dashboard effectively interprets the existence of a mapping row as permission to show the product. There is no separate policy decision or reason-coded record explaining why it was shown.

Recommendation: The portal asks PingAuthorize whether this customer may see this product in the current context. PingAuthorize considers the authenticated identity, accepted relationship, consent, jurisdiction and enterprise policy, then returns allow or deny with a reason.

Reason: A relationship fact should not automatically become permission. An explicit decision is consistent and auditable, while business units retain authority over account access and transactions.

See R1.2 · Enterprise visibility.

How does customer identity propagation change, and why?

Today: The portal and integration services authenticate as applications. The business-unit API may receive a customer identifier, but it cannot independently verify that the request is authorized for that customer.

Recommendation: For a navigation-first MVP, the portal launches the business-unit application. That application reuses the CIAM session, receives a token restricted to its own audience and authorizes the customer directly. If the portal aggregates protected business-unit data, RFC 8693 token exchange carries delegated customer context to the business-unit API.

Reason: One sign-on experience can be preserved without weakening business-unit security boundaries. The API can verify both the calling application and the customer behind the request.

See R1.1 · Customer identity propagation.