Questions about the OpenID Connect Ephemeral Subject Identifier have been pouring in since the OpenID Foundation announced the vote. Risk analysts and architects are eager to understand its impact on their current systems. Let's dive into the most common inquiries.
Understanding the Context
The OpenID Connect Ephemeral Subject Identifier 1.0 Final Specification is up for a vote. If you're using OAuth 2.0, federated authentication, or Open Banking, you're likely curious about its effects on your threat model, privacy stance, or compliance duties.
These questions arise from discussions with teams managing identity infrastructure. Some are exploring Financial Grade API implementations for Open Banking, while others aim to reduce identifier correlation across relying parties. All need clarity on what ephemeral subject identifiers offer.
Q1: What's the difference between an ephemeral subject identifier and the sub claim I'm already using?
Your current sub claim is persistent, providing the same identifier each time a user authenticates. While useful for session linking, it also poses a tracking risk.
An ephemeral subject identifier creates a unique, single-use identifier for each Authorization Code Flow. It can't be correlated across sessions or relying parties without additional context from the authorization server. You're not replacing the sub claim; you're adding an option for flows where correlation risk is a concern.
Consider a user sharing financial data with a third-party app under Open Banking. The relying party needs to verify authorization but doesn't need a persistent identifier across sessions. An ephemeral identifier meets the authorization requirement without creating a long-term tracking token.
Q2: Does this break my existing OpenID Connect flows?
No, this is an additive specification. Your current implementations using persistent sub claims will continue to function as they do now.
You'll choose to use ephemeral identifiers when necessary. This involves updating your authorization server to support the new identifier type and adjusting relying party logic to handle ephemeral claims. Existing flows using standard subject identifiers remain unchanged.
The transition is gradual. You can operate both identifier types simultaneously while assessing which flows benefit from ephemeral identifiers and which require persistent ones.
Q3: How does this help with GDPR's data minimization requirement?
GDPR Article 5(1)(c) mandates collecting only necessary data. Persistent identifiers create a retention obligation. Once stored, a sub claim tied to user attributes requires lifecycle management, access controls, and eventual deletion.
Ephemeral identifiers reduce retention needs. If session linking isn't required, you don't need a persistent handle. The identifier serves its purpose in a single Authorization Code Flow, then becomes useless for correlation.
This doesn't eliminate GDPR obligations but narrows their scope. You're still processing personal data during the Authorization Code Flow, but you're not creating long-term correlation points that expand your data inventory.
Q4: We use Financial Grade API for Open Banking. Should we switch to ephemeral identifiers?
It depends on your data-sharing model. Financial Grade API already provides strong security for Open Banking. The key question is whether your use case benefits from reduced identifier correlation.
If you're implementing consent-based data sharing where a user authorizes one-time access to specific financial data, ephemeral identifiers align with minimal disclosure principles. The relying party gets authorization proof without a persistent user handle.
However, if you're managing ongoing account aggregation where the relying party needs to recognize returning users and maintain session state, persistent identifiers are more appropriate. You can't aggregate transaction history over time without correlating the user across authorization flows.
Evaluate your specific flows. Open Banking often involves both one-time consents and ongoing relationships. You might use ephemeral identifiers for the former and persistent ones for the latter.
Q5: What's the correlation risk you keep mentioning?
Correlation is the ability to link user activity across different contexts. If multiple relying parties receive the same persistent sub claim, they could potentially pool data to profile user activity across services.
This is significant in federated environments where one authorization server serves multiple relying parties. Even if parties don't intentionally collude, a data breach at one could expose identifiers revealing user activity elsewhere.
Ephemeral identifiers disrupt this correlation path. Each Authorization Code Flow gets a unique identifier that can't be linked to others without access to the authorization server's internal mapping, limiting the exposure risk.
Q6: How do I implement this without breaking audit trails?
The authorization server keeps the mapping between ephemeral identifiers and the underlying user identity. Your audit logs can still trace activity back to specific users, but that mapping stays with the authorization server, not every relying party.
When investigating suspicious activity or responding to legal requests, query the authorization server to resolve the ephemeral identifier to the actual user. The relying party's logs contain the ephemeral identifier, enough to trace the flow without exposing persistent identity.
This can enhance your audit posture. If a relying party's logs are compromised, the attacker only gets ephemeral identifiers that don't reveal user identity or enable correlation. Your audit trail remains intact, but exposure is contained.
Next Steps
The OpenID Foundation provides the specification and reference implementations. If you're considering ephemeral identifiers, start with the technical documentation to understand cryptographic properties and flow modifications.
For Open Banking, review how ephemeral identifiers interact with Financial Grade API security profiles. The two specifications complement each other, but you'll need to align them with your regulatory requirements.
Work with your privacy team to document how ephemeral identifiers reduce retention scope. While not a magic bullet for GDPR compliance, they're a technical control that narrows your data footprint.
