This piece is still being written. When it's finished it will work through the design of a pairwise pseudonymous subject identifier system for OIDC, the kind of thing the specification leaves quietly to implementers. The four constraints any good solution has to clear (deterministic, uncorrelatable across clients, performant under load, and revocable when something goes wrong), and the HKDF-with-per-app-salts construction we settled on at ConsentKeys to hit all four.
It will also cover the things you don't read about in the spec: how the salt strategy interacts with key rotation, what breaks when a client legitimately needs to correlate identities across two of its own apps, and the small operational surprises that only show up at production scale.
— Planned outline —
- What the OIDC spec actually says about pairwise subjects, and what it deliberately doesn't.
- Four constraints any production solution has to satisfy.
- HKDF with per-app salts: why this construction, and what alternatives we ruled out.
- The operational concerns the spec doesn't mention.
- What we got right, what we'd reconsider.