oidc-esid June 2025
Sakimura & Jay Standards Track [Page]
Workgroup:
Connect
Published:
Authors:
N. Sakimura
NAT.Consulting
E. Jay
Illumila

OpenID Connect Ephermeral Subject Identifier 1.0 - Draft 01

Abstract

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.

Warning

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.

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.

Foreword

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.

Table of Contents

1. Introduction

This document specifies an ephemeral subject identifier type for OpenID Connect Core 1.0. 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 OpenID Connect Core 1.0.

2. Requirements Notation and Conventions

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 RFC2119 when, and only when, they appear in all capitals, as shown here.

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.

3. Terms and definitions

For the purpose of this document, the terms defined in RFC6749, and OpenID Connect Core 1.0 apply.

4. Ephemeral Identifier

This document adds a new subject identifier type as follows, in addition to what is defined in Section 8 of OpenID Connect Core 1.0:

ephemeral
This provides a different sub value to each visit by the End User to a relying party, so as not to enable Clients to correlate the End-User's multiple visits.

5. OpenID Provider Discovery Metadata

The OpenID Provider indicates support for ephemeral subject identifiers in the metadata document.

This document defines the following new value for the subject_types_supported metadata of OpenID Discovery 1.0:

6. Client Registration

The RP requests the OP to return ephemeral subject identifiers by registering ephemeral as the subject_type in OpenID Dynamic Registration 1.0 or by other means.

7. Security Considerations

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 sub value.

8. Privacy Considerations

The privacy objectives of this document are as follows:

  1. 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.
  2. to make it unfeasible for colluding RPs to link two independent visits among them.

9. References

9.1. Normative references

The following referenced documents are indispensable for the application of this document. For dated references, only the edition cited applied. For undated references, the latest edition of the referenced document (including any amendments) applies.

BCP14 - Key words for use in RFCs to Indicate Requirement Levels

RFC2119 - Key words for use in RFCs to Indicate Requirement Levels

RFC8174 - Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words

RFC6749 - The OAuth 2.0 Authorization Framework

OIDC - OpenID Connect Core 1.0 incorporating errata set 1

OpenID.Discovery - OpenID Connect Discovery 1.0

OpenID.Registration - OpenID Connect Registration 1.0

Authors' Addresses

Nat Sakimura
NAT.Consulting
Edmund Jay
Illumila