Understanding Federated User Identifiers describes a multitude of identifiers that are in use within InCommon. Here's how you should choose which to use:
- First, if you do not need a unique identifier, do not request one. This enhances privacy, and you can still make authorization decisions based on entitlement and affiliation attributes without knowing the user's unique identity.
- If you do need a unique identifier, but that identifier need not be shared with other services (or policy prevents such sharing), request the OASIS Pairwise Subject Identifier. This enhances privacy protection and also shields you from potential security threats arising from breaches of other services that would otherwise share the same identifier.
- If you need a unique identifier, and that identifier must be shared with other services (and policy permits such sharing), request the OASIS General Purpose Subject Identifier. Acceptance of the risk to privacy protection and security is often warranted to support research collaborations involving participants and services from multiple institutions.
What To Do When Your Preferred Identifier Is Not Available
As discussed in Understanding Federated User Identifiers, the OASIS Subject Identifier Attributes represent the best current thinking, but they are not (yet) broadly deployed. If you find that the selected identity provider cannot provide your preferred identifier, what happens next will depend on the nature of your service. Potential, if less desirable, substitutes for the General Purpose Subject Identifier are eduPersonUniqueId and eduPersonPrincipleName. A potential substitute for Pairwise Subject Identifier is eduPersonTargetedID. It may also be appropriate to try another identity provider, or you may simply have to deny access.
Multiple Identifiers for the Same Person
It is possible that additional, more desirable, identifiers will be available from the identity provider at future times. For this reason, a good practice is to use an internal identifier as the "primary key" for each user, if you retain information about your users between sessions. The identifiers you retrieve from the identity provider then serve as "secondary keys" that you map to your users as they become available.