The case for an OIDC ephemeral ID
The OpenID Connect Core 1.0 specification defines two subject types,
public subject type is used to provide "the same
sub (subject) value to all Clients" or Relying Parties (RPs), while the
pairwise one is meant to provide "a different
sub value to each Client, so as not to enable Clients to correlate the End-User's activities without permission".
In other terms, the
public subject type is a globally unique persistent identifier, while the
pairwise one is targeted to a specific RP.
Ephemeral vs Pairwise
pairwise subject is presented as privacy preserving since it is meant to avoid correlation. Though, the use of the same
sub with an RP will led to a history of usage of the resource by a particular subject. On the other hand the
pairwise subject type let the RP recognize the user and thus augment the user experience, customize the service, and so on. There are cases where all of that it is not needed.
A practical example is the access to electronic academic journals. Most of the publishers support federated authentication with the use of SAML 2.0 and most of the time they require only an entitlement to prove that the user is eligible for the service. The kind of service they are providing --- access to academic papers --- does not need to be personalized.
In the SAML world this kind of idenfication is accomplished with the use of the transient identifier ---
urn:oasis:names:tc:SAML:2.0:nameid-format:transient --- plus the
Another potential use case is related to the use of the ID Token to convey user identifiers created in other context (eIDAS for example). In such cases it wouldn't really make sense to rely on the
sub to identify the user.
OIDC ephemeral identifier
We can list three ways to implement an ephemeral identifier in OpenID Connect:
- Issuing non compliant ID Tokens --- i.e. without the
- Hack it into the current
- Defining a new subject type.
Both the issuing non compliant ID Tokens and the hack into the
pairwise solutions might appear as fast tricks to achieve the result without having to change much code. In fact one can simple add a new feature to his or her OP that simply says "enable random creation of sub for the same client", or "do not include sub in the ID Token", and that's it. Though, there are potentially great cons. RPs, and the libraries on which RPs are based, are expecting both that the
sub is always present and that the value is expressed according to the spec. So this hacks would work only with custom, uncompliant, RPs and would lead to breakage and meaningless error messages with standard ones.
A new subject type shouldn't cause too much problems to RPs and OPs that don't understand and support it. The new subject type will be used in both the
subject_types_supported metadata parameter for OpenID Provider and it will also be used by RPs requesting it with the
subject_type element in the registration phase. In fact, following a well established convention, any subject type value that are not understood MUST be ignored by RPs and OPs. In some cases that could lead to the client registration to fail, and in that case a meaningfull error message should be issued.
- Define the exact syntax and the requirements of the new subject type.
- Gives guidelines on the algorithm that MAY be used to compute the identifier value.
Comments and Feedback
Either add a comment or reach me at firstname.lastname@example.org.
Davide Vaghetti Consortium GARR