Two new identifier attributes: subject-id and pairwise-id

The new identifier attributes gain more and more traction in the SAML-based identity federations. Find out what issues they address, what characteristics they have and who can use them in which scenarios.

Uniquely identifying an authenticated user is a very common use case for federated services. But how can users be identified exactly? In the SAML world there are two mechanisms: SAML name identifiers and attributes.

SAML Name Identifiers, as the name implies, are theoretically intended to identify subjects. In practice it’s much more likely that users are identified by a SAML Attribute. The concept of Name Identifiers is complex, often not well implemented and therefore confusing to many service providers.

Attributes, on the other hand, are easy to understand and there are many to choose from for identifying users. In the SWITCHaai federation, the most common identifier attribute is the swissEduPersonUniqueID attribute, which contains the same value as the international versions eduPersonPrincipalName and eduPersonUniqueId.
If data privacy is a requirement or if the service needs to query user information out-of-band, a service would have used the deprecated eduPersonTargetedID or now uses the persistent NameID format instead.

More about the characteristics of these and other identifier attributes is available in this overview.

Unfortunately, none of the existing identifier attributes turned out to be perfect. More than two decades of practice have shown that they all lack one or another feature that a good identifier attribute should have. Be it that the attribute is not case-insensitive, not scoped, reassignable or does not come as a compact value but as an XML structure. Therefore, in 2019 the specification “SAML V2.0 Subject Identifier Attributes Profile” was created.

It contains the description for two new attributes to address these problems and thus create the near-perfect attributes to identify users:

• General Purpose Subject Identifier
• Pairwise Subject Identifier

The short names of these attributes are “subject-id” and “pairwise-id”.

Both attributes look like the swissEduPersonUniqueID. So they have the form localpart@domain.name, e.g. 123456789@eduid.ch or 123456789ABCDEFGHIJKLMNAOP@switch.ch. What makes them special is the specification that defines the characteristic. Both attributes are case-insensitive, scoped, non-reassignable and come as compact values.

The pairwise-id is also a direct replacement for the deprecated eduPersonTargetedID and Persistent NameID format, which consisted of a random string, entity ID of SP and IdP packed in XML. The XML syntax and the data “triple” of these identifiers are in the pairwise-id replaced with a simple flat string that encodes all this information. The pairwise-id can also be used to query data out-of-band to update user information. Of course, like eduPersonTargetedID/Persistent NameID, the pairwise-id is a target attribute, which means that its value for the same user will vary depending on the relying party.
The local part before the @ of both identifiers should start with a number or a letter and  be maximum 127 characters long. Also, only ‘-‘ and ‘=’ are allowed as special characters.

One notewhorty aspect of the specification is that it requires services that used these attributes to signal their usage in SAML2 metadata. Thus, services need to declare via an entity attribute if they need one, any or none of these attributes.

The only downside to these two new identifier attributes is that they are not yet supported by many identity providers and therefore not yet used by many services. So it’s a bit of a chicken and egg problem.

All organisations that have adopted Switch edu-ID will automatically support both new attributes if they are enabled in the AAI Resource Registry. Other organisations may need to adjust their configuration and, in some cases, the generation of their identifier attributes.

The subject-id does not offer much advantage over the swissEduPersonUniqueID for services operating in the SWITCHaai federation. Services that allow users from several identity federations should, request the subject-id, and as backup also the eduPersonPrincipalName. Even though far from perfect in many regards, the eduPersonPrincipalName still has the best coverage of all international identifier attributes among eduGAIN Identity Providers. Once an Identity Provider supports the subject-id, however, a service should prefer the subject-id over all other identifiers from that Identity Provider.

The pairwise-id should in general be used for all services that need to query user attributes out-of-band. Also, services (e.g. publisher services) that need a persistent identifier but no other identifying data like name or e-mail, should use the pairwise-id for data privacy reasons.