Federation to a low-assurance partner app currently releases full Social Security numbers with every login. What trust-boundary fix is required?
Select an answer to reveal the explanation.
Short Explanation
Handing SSNs to a low-assurance partner app is oversharing at login. Trim the claims to what that app actually needs—and skip SSNs unless policy truly demands them. More sensitive fields, public identity dumps, or cleartext assertions pour fuel on federation risk.
Full Explanation
Federation trust boundaries include how many—and which—attributes ride in each assertion. When a low-assurance partner application currently receives full Social Security numbers with every login, minimize claims to only those attributes the partner truly needs at its assurance level, and exclude SSNs unless strictly required, formally approved, and protected. Attribute minimization limits privacy harm and fraud impact if the partner is breached, misconfigured, or if assertions are intercepted. Low-assurance apps especially should not be default recipients of government identifiers.
Increasing attribute volume by also releasing full medical record numbers “to be helpful” worsens oversharing and expands breach blast radius. Publishing the city’s entire identity graph to a public metadata URL for partner convenience exposes identity data far beyond any legitimate federation need. Disabling encryption of assertion payloads so partners can debug fields faster removes confidentiality of claims in transit and turns troubleshooting convenience into a wiretap opportunity.
Exam caveat: cryptographic validation of federation is necessary but not sufficient—attribute governance and minimization are first-class controls. Operational check: review per-partner claim release policies, strip SSNs and other sensitive identifiers unless justified in writing, encrypt assertion payloads, remove public identity-graph dumps, and re-test partner logins after claim reduction to confirm only needed attributes remain.