<?xml version="1.0" encoding="utf-8"?>
<!-- name="GENERATOR" content="github.com/mmarkdown/mmark Mmark Markdown Processor - mmark.miek.nl" -->
<rfc version="3" ipr="none" docName="openid-connect-ephemeral-subject-identifier-1_0-02" submissionType="IETF" category="std" xml:lang="en" xmlns:xi="http://www.w3.org/2001/XInclude" indexInclude="true" consensus="true">

<front>
<title abbrev="oidc-esid">OpenID Connect Ephermeral Subject Identifier 1.0 - Draft 02</title><seriesInfo value="openid-connect-ephemeral-subject-identifier-1_0-02" status="standard" name="OpenID-Draft"></seriesInfo>
<author initials="N." surname="Sakimura" fullname="Nat Sakimura"><organization>NAT.Consulting</organization><address><postal><street></street>
</postal><email>nat@nat.consulting</email>
</address></author><author initials="E." surname="Jay" fullname="Edmund Jay"><organization>Illumila</organization><address><postal><street></street>
</postal><email>ejay@illumi.la</email>
</address></author><date/>
<area>Internet</area>
<workgroup>Connect</workgroup>
<keyword>openid</keyword>
<keyword>ephemeral</keyword>
<keyword>subject</keyword>
<keyword>privacy</keyword>

<abstract>
<t>OpenID Connect specifies the public and pairwise subject identifier types. These types of subject identifiers allow relying parties to keep track of the End-User across multiple visits to the relying party application by correlating the subject identifier. This document specifies an ephemeral subject identifier type that prevents correlation of the subject identifier across multiple visits to enhance user privacy.</t>
</abstract>

<note><name>Warning</name>
<t>This document is not an OIDF International Standard. It is distributed for review and comment. It is subject to change without notice and may not be referred to as an International Standard.</t>
<t>Recipients of this draft are invited to submit, with their comments, notification of any relevant patent rights of which they are aware and to provide supporting documentation.</t>
</note>

<note><name>Foreword</name>
<t>The OpenID Foundation (OIDF) promotes, protects and nurtures the OpenID community and technologies. As a non-profit international standardizing body, it is comprised by over 160 participating entities (workgroup participants). The work of preparing implementer drafts and final international standards is carried out through OIDF workgroups in accordance with the OpenID Process. Participants interested in a subject for which a workgroup has been established has the right to be represented in that workgroup. International organizations, governmental and non-governmental, in liaison with OIDF, also take part in the work. OIDF collaborates closely with other standardizing bodies in the related fields.</t>
</note>

</front>

<middle>

<section anchor="introduction"><name>Introduction</name>
<t>This document specifies an ephemeral subject identifier type for <eref target="https://openid.net/specs/openid-connect-core-1_0.html">OpenID Connect Core 1.0</eref>. The ephemeral subject identifier identifies the End-User for a short time and remains constant for the duration of the authentication session. In subsequent visits by the End-User to a Relying Party application that requires authentication, the authorization server will return a subject identifier with a different value. The authorization server provides an ephemeral subject identifier to the Relying Party in the ID Token and UserInfo endpoint response as specified by <eref target="https://openid.net/specs/openid-connect-core-1_0.html">OpenID Connect Core 1.0</eref>.</t>
<t>There are several reasons for defining it:<br />
* It is already used in some ecosystems. Standardizing it would therefore reduce existing variations.
* It is a condition needed to mathematically prove that OIDC/SIOP fulfills the Unlinkability Level (UL) 3A+ defined in ISO/IEC 27551 Information security, cybersecurity and privacy protection — Requirements for attribute-based unlinkable entity authentication.</t>
<t>Examples of attribute-based unlinkable entity authentication include Overage verification, Underage verification, Registered domicile verification, etc.</t>
</section>

<section anchor="requirements-notation-and-conventions"><name>Requirements Notation and Conventions</name>
<t>The key words &quot;MUST&quot;, &quot;MUST NOT&quot;, &quot;REQUIRED&quot;, &quot;SHALL&quot;, &quot;SHALL NOT&quot;,
&quot;SHOULD&quot;, &quot;SHOULD NOT&quot;, &quot;RECOMMENDED&quot;, &quot;NOT RECOMMENDED&quot;, &quot;MAY&quot;, and
&quot;OPTIONAL&quot; in this document are to be interpreted as described in BCP
14 <eref target="https://tools.ietf.org/html/rfc8174">RFC2119</eref> when, and only when, they appear in all
capitals, as shown here.</t>
<t>In the .txt version of this document, values are quoted to indicate that they are to be taken literally. When using these values in protocol messages, the quotes MUST NOT be used as part of the value. In the HTML version of this document, values to be taken literally are indicated by the use of this fixed-width font.</t>
</section>

<section anchor="terms-and-definitions"><name>Terms and definitions</name>
<t>For the purpose of this document, the terms defined in <eref target="https://tools.ietf.org/html/rfc6749">RFC6749</eref>, and <eref target="https://openid.net/specs/openid-connect-core-1_0.html">OpenID Connect Core 1.0</eref> apply.</t>
</section>

<section anchor="ephemeral-identifier"><name>Ephemeral Identifier</name>
<t>This document adds a new subject identifier type as follows, in addition to what is defined in Section 8 of <eref target="https://openid.net/specs/openid-connect-core-1_0.html">OpenID Connect Core 1.0</eref>:</t>

<dl spacing="compact">
<dt>ephemeral</dt>
<dd>type of an identifier when the sub provided by ID Token is different for every authentication request</dd>
</dl>
<t>To ensure that it is not possible for Clients to correlate multiple authentication response, an OP</t>

<ol spacing="compact">
<li>MUST NOT reuse an ephemeral identifier value;</li>
<li>MUST generate the value with a guessing probability of 2<sup>-128</sup> or less;</li>
<li>SHOULD target 2<sup>-160</sup> or less; and</li>
<li>SHOULD generate the value with a collision probability that is infeasible for the expected lifetime and scale of the deployment.</li>
</ol>
</section>

<section anchor="openid-provider-discovery-metadata"><name>OpenID Provider Discovery Metadata</name>
<t>The OpenID Provider indicates support for ephemeral subject identifiers in the metadata document.</t>
<t>This document defines the following new value for the <em>subject_types_supported</em> metadata of <eref target="https://openid.net/specs/openid-connect-discovery-1_0.html">OpenID Discovery 1.0</eref>:</t>

<ul spacing="compact">
<li><em>ephemeral</em> - ephemeral subject identifiers</li>
</ul>
</section>

<section anchor="client-registration"><name>Client Registration</name>
<t>The RP requests the OP to return ephemeral subject identifiers by registering <em>ephemeral</em> as the <em>subject_type</em> in <eref target="http://openid.net/specs/openid-connect-registration-1_0.html">OpenID Dynamic Registration 1.0</eref> or by other means.</t>
</section>

<section anchor="security-considerations"><name>Security Considerations</name>
<t>The generated ephemeral identifier needs to be unique over time.
Otherwise, the RP may link two different users to the same record and will cause a security incident.
One way to achieve uniqueness is to use the hash of the combination of a cryptographic
random and the timestamp as the <em>sub</em> value.</t>
</section>

<section anchor="privacy-considerations"><name>Privacy Considerations</name>
<t>The privacy objectives of this document are as follows:</t>

<ol spacing="compact">
<li>to make it unfeasible for the RP to link two independent visits by the user. Inclusion of cryptographic random in the input to the hash function that generates the subject identifier would achieve it.</li>
<li>to make it unfeasible for colluding RPs to link two independent visits among them.</li>
</ol>
</section>

<section anchor="references"><name>References</name>

<section anchor="normative-references"><name>Normative references</name>
<t>The following referenced documents are indispensable for the application of this document. For dated references, only the edition cited applies. For undated references, the latest edition of the referenced document (including any amendments) applies.</t>
<t><eref target="https://tools.ietf.org/html/bcp14">BCP14</eref> - Key words for use in RFCs to Indicate Requirement Levels</t>
<t><eref target="https://tools.ietf.org/html/rfc2119">RFC2119</eref> - Key words for use in RFCs to Indicate Requirement Levels</t>
<t><eref target="https://tools.ietf.org/html/rfc8174">RFC8174</eref> - Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</t>
<t><eref target="https://tools.ietf.org/html/rfc6749">RFC6749</eref> - The OAuth 2.0 Authorization Framework</t>
<t><eref target="https://openid.net/specs/openid-connect-core-1_0.html">OIDC</eref> - OpenID Connect Core 1.0 incorporating errata set 1</t>
<t><eref target="https://openid.net/specs/openid-connect-discovery-1_0.html">OpenID.Discovery</eref> - OpenID Connect Discovery 1.0</t>
<t><eref target="http://openid.net/specs/openid-connect-registration-1_0.html">OpenID.Registration</eref> - OpenID Connect Registration 1.0</t>
</section>

<section anchor="informative-references"><name>Informative references</name>
<t><eref target="https://www.iso.org/standard/72018.html">ISO/IEC 27551</eref> - Information security, cybersecurity and privacy protection — Requirements for attribute-based unlinkable entity authentication</t>
</section>
</section>

</middle>

<back>

<section anchor="acknowledgements"><name>Acknowledgements</name>
<t>We would like to thank the following people for their valuable feedback and contributions to this specification.</t>

<ul spacing="compact">
<li>Frederik Krogsdal Jacobsen</li>
<li>Mark Haine</li>
<li>Andy Barlow</li>
<li>Edmund Jay</li>
<li>Nat Sakimura</li>
</ul>
</section>

<section anchor="notices"><name>Notices</name>
<t>Copyright (c) 2026 The OpenID Foundation.</t>
<t>The OpenID Foundation (OIDF) grants to any Contributor, developer, implementer, or other interested party a non-exclusive, royalty free, worldwide copyright license to reproduce, prepare derivative works from, distribute, perform and display, this Implementers Draft, Final Specification, or Final Specification Incorporating Errata Corrections solely for the purposes of (i) developing specifications, and (ii) implementing Implementers Drafts, Final Specifications, and Final Specification Incorporating Errata Corrections based on such documents, provided that attribution be made to the OIDF as the source of the material, but that such attribution does not indicate an endorsement by the OIDF.</t>
<t>The technology described in this specification was made available from contributions from various sources, including members of the OpenID Foundation and others. Although the OpenID Foundation has taken steps to help ensure that the technology is available for distribution, it takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this specification or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any independent effort to identify any such rights. The OpenID Foundation and the contributors to this specification make no (and hereby expressly disclaim any) warranties (express, implied, or otherwise), including implied warranties of merchantability, non-infringement, fitness for a particular purpose, or title, related to this specification, and the entire risk as to implementing this specification is assumed by the implementer. The OpenID Intellectual Property Rights policy (found at openid.net) requires contributors to offer a patent promise not to assert certain patent claims against other contributors and against implementers. OpenID invites any interested party to bring to its attention any copyrights, patents, patent applications, or other proprietary rights that may cover technology that may be required to practice this specification.</t>
</section>

<section anchor="document-history"><name>Document History</name>
<t>[[ To be removed from the final specification ]]</t>
<t>-02 Tightened the ephemeral identifier definition. Added names to acknowledgements.</t>
<t>-01 Added rationale for this document and a reference to ISO/IEC 27551.</t>

<ul spacing="compact">
<li>initial revision</li>
</ul>
</section>

</back>

</rfc>
