eduPersonTargetedID is defined as follows:
A persistent, non-reassigned, privacy-preserving identifier for a principal shared between a pair of coordinating entities, denoted by the SAML 2 architectural overview  as identity provider and service provider (or a group of service providers). An identity provider uses the appropriate value of this attribute when communicating with a particular service provider and does not reveal that value to any other service provider.
This makes it the best choice for service providers who need to uniquely identify users accessing their service to establish a local security context as the same, globally unique value will always be provided to your SP from the users IdP when they establish a new session.
Integrating eduPersonTargetedID (EPTID) as the primary identity for your service can be undertaken a number of different ways. The best way for your application will depend on how you consume identity, your local storage limits, flexibility in your authentication pipeline and other service specific concerns.
The standard format for eduPersonTargetedID is as follows:
Which consists of the entityID for the issuing IdP, the entityID of the local service and a hash generated by the users IdP based on part of their local credentials. We've often seen developers fall into the trap of thinking that the generated hash is unique.
This is not the case, the same hash could mathematically be provided by two separate IdP for two different users. To ensure uniqueness the entire string must be evaluated as provided.
A secondary, less frequently seen format for eduPersonTargetedID is as follows:
Which consists of the entityID for the issuing IdP, the entityID of the local service and a GUID generated by the users IdP.
Services MUST be able to consume both forms of eduPersonTargetedID
Usage in your application
Overall what we're looking to achieve is using the supplied value for eduPersonTargetedID to look up details in the local applications data store in order to setup some local security context.
In the past developers would have achieved similar by requesting a username and password through a web form. If the password is correct the supplied username would have been used to query the local data store. For our purposes we can now consider EPTID to be the username with the requirement to validate passwords/identity already handled for us by the users IdP who the federation trusts.
At this point you have a number of options for the unique identifier your application stores:
- Simply store the complete EPTID and look up account detail directly. We do this in federation registry and it works wonderfully. To achieve this though you'll need to be able to store upto 254 char for identifiers.
- Configure your SP to not use the SP entityID in targetedID values it sends to your application to shorten it. In this way the above would become:
https://vho.aaf.edu.au/idp/shibboleth!-!Mza74xVcOOJ/I/Z3NFFY86+nfOk it is your service entityID that gets removed which will always be the same anyway so you continue to get absolute uniqueness. This will still require substantial space for storing identifiers. At present the average size of entityID's within the federation is 41 characters. It is feasible then that the space required could be as low as 100 char but you'll need to be prepared for the odd error if you constrain this far.
Using this method you'd once again look up accounts directly as with 1.
In your authentication pipeline create a hash (SHA256 for example) of the supplied value for ETPID. You could then store this as your unique identifier for each user. As the same hash will be able to be generated on the fly each time a user visits you can use this to lookup the account in your services datastore. Using SHA256 will allow you to further reduce the space required for identifiers to 64 char.
If you proceed with the hash approach you should log the supplied EPTID for every session establishment at a minimum. If you need to communicate with an IdP about an account that is mis-behaving on your service you'll need to be able to provide them the original EPTID as your stored hash will mean nothing to the IdP itself.