The OpenID Connect Core 1.0 specification defines two subject types, public and pairwise.
The 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.
The 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 eduPersonEntitlement attribute.
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.
We can list three ways to implement an ephemeral identifier in OpenID Connect:
- Issuing non compliant ID Tokens --- i.e. without the
subclaim. - Hack it into the current
pairwisesubject. - 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.
TBD
- 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.
Either add a comment or reach me at [email protected].
Davide Vaghetti Consortium GARR