OpenID Foundation vote on Ephemeral Subject Identifier 1.0 as a Final Specification closes

What happened

The OpenID Foundation's member vote on OpenID Connect Ephemeral Subject Identifier 1.0 as a Final Specification ran from September 16 to September 30, 2026, and closed on September 30. It followed a public review from July 17 to September 15, 2026. We have not yet confirmed the result; check the OpenID Foundation for the announced outcome.

The spec comes from the AB/Connect Working Group, authored by N. Sakimura (NAT.Consulting) and E. Jay (Illumila). It adds a third subject_type, ephemeral, alongside OIDC Core's public and pairwise. Key points from the spec text:

• The identifier remains constant for the duration of the authentication session. A later visit gets a different value.
• The OpenID Provider must not reuse an ephemeral identifier value, and needs a cryptographically secure random number generator to avoid account mix-up.
• A relying party requests it by registering subject_type=ephemeral; the OP advertises it in subject_types_supported.
• The spec does not address refresh tokens, UserInfo, or logout behavior.

Why it matters

OIDC has offered two privacy settings for sub until now. Pairwise stops unrelated apps from correlating a user, but each app still recognizes the user every visit. Ephemeral goes further: even the same app cannot link visits through sub. The stated motivation is showing that OIDC and SIOP can meet Unlinkability Level 3A+ of ISO/IEC 27551.

Deepak's take

This is a small spec with a big design implication. Most relying parties key their user table on sub. An ephemeral sub cannot carry an account, by design. So the spec is really an invitation to build a different kind of integration: one that checks an attribute and keeps nothing.

That fits where regulation is heading. Age checks and membership checks increasingly need a yes or no, not a profile. A relying party that only needs "over 18" has no business holding a stable identifier for that person. Ephemeral sub makes the minimal option the easy option, which is how privacy patterns actually get adopted.

The gaps are real, though. The spec leaves refresh tokens, UserInfo, and logout unaddressed. Expect OP implementations to differ there until profiles fill them in.

What to do

• Relying parties doing one-off attribute checks (age over a threshold, membership): evaluate ephemeral sub once your OP advertises it. Do not create a persistent profile keyed on the value.
• Relying parties with accounts: Stay on pairwise or public. If you want less linkability, pairwise with a registered sector_identifier_uri is the stable option.
• Identity providers: Plan CSPRNG-backed generation and a no-reuse guarantee before advertising ephemeral in subject_types_supported.
• Further reading: the OIDC subject identifiers guide compares public, pairwise, and ephemeral side by side.