EXA28
— Onboard partners or customers —
OAuth Identity Token Slimming
Single sign-on tokens leak the full user profile to every relying party — Polymonial wraps the assertion so only requested claims decrypt.
The problem to solve
Every SSO login mints an ID token containing the full user profile — name, email, all groups, all attributes. The relying party only needs claims like 'is over 18' or 'is in payroll group'. The plumbing forces them to receive everything, then ignore most of it — but the data sits in their session store, their logs, and their breach surface forever.
The solution it enables
IdP schema-wraps the token. Relying party's schema asks for the specific claim it needs; the rest stays sealed. The IdP doesn't need to know in advance which RP wants which claim — the RP's schema decides at consumption time. Same OAuth / OIDC / SAML flow; same redirect dances; just selective claim decryption.
What it looks like
An identity provider serves 200 SaaS apps via OIDC for a multinational's 45,000 employees. Each ID token carries 28 claims. The expense-tool RP needs only 'employee_id' and 'cost_centre'; the HR-tool RP needs identity + manager + grade. Today: each app receives the full claim set and stores it. After Polymonial: each RP's schema unseals only its required claims; the rest stays encrypted. The expense-tool's session store no longer holds the employee's manager identity, grade, location. The PII each app holds shrinks to the claims it asked for.
“Single sign-on. Single-claim disclosure. The RP gets the answer to its question — not your whole profile.”
Who’s this for you?
We have this problem.
Your organisation needs this for its own data, product or programme of work.
We deliver this for clients.
A consultancy, integrator, service provider, industry programme or technology vendor.