Federation With a Partner Who Won't Share Attributes
A regional bank is onboarding a fintech partner to offer co-branded lending. The partner will authenticate its own customers and assert their identity to the bank via OIDC so those customers can view loan offers. The partner refuses to share a stable subject identifier beyond an opaque pairwise ID, will not assert email, and will not assert any group or role claims-citing privacy commitments to its users. The bank's application expects an email address as the primary key and uses group claims to decide whether a user sees 'pre-qualified' offers. The bank's identity architect notes that pairwise subject identifiers mean the same person will appear as different subjects across relying parties, complicating account linking. Legal confirms the partner's privacy stance is contractual and non-negotiable. The launch is in six weeks.
1. Identify the core design conflict and propose how the bank should adapt its application and identity model.
Read the worked answer
The conflict is that the bank's application was built on local assumptions (email as key, group claims for authorization) that the federation partner will not satisfy. Forcing the partner to change violates the contract; forcing the app to accept missing data without redesign creates broken linking and authorization.
Adaptation:
- Stop using email as the primary key. Introduce a bank-side account record keyed on
(partner_id, pairwise_subject). Email, if ever obtained, becomes a mutable attribute, not an identifier. This is correct practice regardless of the partner. - Move authorization inside the bank. Since no group claims arrive, the bank must derive entitlement from its own data-e.g., loan-offer eligibility computed from the partner's loan application data the bank already receives through the business channel, not from an IdP claim. Group claims from a partner should never be the sole basis for entitlement anyway.
- Handle pairwise subjects deliberately. The bank cannot correlate a user across partners by subject; if cross-partner linking is needed, it must be done through a bank-controlled account or a consented linking flow, not by guessing.
This keeps the partner's privacy commitments intact while restoring a sound identity model.
2. What risks does this arrangement introduce, and what controls or contractual terms should accompany launch?
Read the worked answer
Risks:
- Account-linking errors: without a stable identifier, mis-linking could expose one customer's offers to another. Control: link only via bank-issued account or explicit consented flow; never fuzzy-match on attributes.
- Authorization gaps: absence of role claims means the bank's own logic must be authoritative; a bug there is a direct exposure. Control: server-side entitlement checks with tests and monitoring.
- Attribution and audit: opaque pairwise IDs complicate investigations. Control: log the partner, pairwise subject, and session correlation ID; agree with the partner on a lawful process to resolve a subject when required (e.g., fraud or legal request).
- Assurance uncertainty: the bank cannot see how the partner authenticates its users. Control: contractual minimum assurance (MFA, credential standards), plus the right to audit or receive attestations.
- Revocation latency: if the partner deprovisions a user, the bank may not learn promptly. Control: short session lifetimes and a deprovisioning/notification commitment.
Contract terms: assurance standards, breach notification, subject-resolution process for lawful requests, deprovisioning SLAs, and audit rights. Document the residual risk acceptance for the audit committee.