The use of the eduPersonTargetedID attribute should be phased out and replaced in all SAML 2.0 usage, by sending the exact same data in a different part of the SAML Assertion (references below).
The content (or attribute value) of the eduPersonTargetedID attribute is defined to be a SAML 2.0 persistent NameID (see link below). This data structure is sometimes called a "long-lived service-specific pseudonym" in that it's a stable and opaque identifier that differs for each service a subject is accessing. I.e., Service A and Service B cannot profile (or match) subjects based on the identifier alone, as each service will know the subject by a different NameID value.
Note that saml2int (the Interoperable SAML 2.0 Deployment Profile, which is a normative part of eduID.at, cf. section "Requirements" in the eduID.at Technical Profile) recommends to transmit persistent NameIDs in the Subject of the SAML Assertion, not as an (eduPersonTargetedID) Attribute (value). So any time you see mention of the eduPersonTargetedID attribute (esp. if the context is not specific to SAML1.x only) you should read that to mean "persistent SAML 2.0 NameID" and also assume "transmitted in the Subject of the SAML Assertion, not as a SAML Attribute (value)".
Please report services that break when not being sent the eduPersonTargetedID attribute version (i.e., services that require a SAML 2.0 NameID as eduPersonTargetedID attribute value, but fail to accept it in the place SAML 2.0 specifies) to the ACOnet team.
More technical information:
- MACE-Dir SAML Attribute Profiles, "3.3.1.1 eduPersonTargetedID", p.11f, and esp. lines 390-393
- saml2int.org
- TODO: Instructions for the Shibboleth 3.x IDP to generate the SAML 2.0 persistent NameID in the recommended format.
Overview
Content Tools
Tasks