There are multiple problems with the current attribute definition, mainly the way the privacy features are described and some odd text about reassignment (it says both should not and must not at the same time). I also tried to be much clearer about from which perspectives the various properties are intended.
I also added a suggested change to make the size of the identifier portion a SHOULD <= 64 because length continues to be a problem with it.
My proposal is fairly long, of course, because this is a complex topic and I'm trying to answer the constant complaints that "you can't use it for that" . One might entertain a suggestion to include a more brief description within the current document, and call out to another document to elaborate, or perhaps there's another approach I'm missing.
The bottom line is really that the SAML 2.0 identifier construct was intended to be "the identifier" for as many use cases as possible because the alternatives were insufficient or badly under-specified. But it suffers from complexity as a result. I guess the problem is that it's harder to explain than use, at least for apps that know not to display internal user identifiers.
Anticipating one set of possible objections, the thing that's "out of band" with this attribute is the correlatability. Typically, that hasn't been a big issue; the RPs don't usually ask for that ability, they just don't care. When they do care, you really have three choices:
1. Use it, rely on the "Affiliations" concept in SAML, and hope people support that.
2. Use a globally-scoped attribute.
3. Define a service-specific attribute so that it's unambigiously clear that the value needs to be common to all instances of that attribute.
3 seems pointless since it requires the same OOB setup as 1.
-- Scott
2.2.10. eduPersonTargetedID (defined in eduPerson 200312); OID: 1.3.6.1.4.1.5923.1.1.1.10
Application utility class: extended; # of values: multi
Definition
A persistent, non-reassigned, opaque identifier for a principal.
An eduPersonTargetedID value is a tuple consisting of an opaque identifier for the principal, a name for the source of the identifier, and a name for the intended audience of the identifier.
The identifier portion MUST NOT exceed 256 characters, and SHOULD be no more than 64 characters, in length.
This attribute is equivalent to the SAML V2.0 name identifier format of "urn:oasis:names:tc:SAML:2.0:nameid-format:persistent" (see
http://www.oasis-open.org/committees/download.php/35711). As a result, the source of the identifier is termed an identity provider and the name of the source takes the form of a SAML V2.0 entityID, which is an absolute URI. The name of the intended audience also takes the form of an absolute URI, and may refer to a single service provider or a collection of service providers (for which SAML V2.0 uses the term "Affiliation", not to be confused with the ordinary eduPerson use of the term).
In SAML, a service provider is an abstract designation and may or may not refer to a single application or physical system. As a result, and because service providers may be grouped arbitrarily into "Affiliations" for policy purposes, the intended audience of an eduPersonTargetedID may be (and often is) limited to a single "target" application, or may consist of a large number of related applications. This is at the discretion of the identity provider. The value of the principal identifier SHOULD be different for different "audience" values, but this is also at the discretion of the identity provider.
This attribute may or may not be stored in a typical Directory Service because of its potential variance by relying party, but it is defined here for potential use in other service contexts such as Security Assertion Markup Language (SAML) assertions. It is typically used in federated scenarios in which more typical opaque identifiers lack appropriate uniqueness guarantees and uniformity of identification across identity providers is important.
More specific requirements and guidance follows.
Persistence
eduPersonTargetedID values are not required to have a specific lifetime, but the association SHOULD be maintained longer than a single user interaction and long enough to be useful as a key for consuming services. Protocols might also be used to refresh (or "roll-over") an identifier by communicating such changes to service providers to avoid a loss of service. (SAML V2.0 includes one such example.) This may be needed in the event that the association between the principal and the identifier becomes public.
Note that while eduPersonTargetedID identifiers are not required to be permanent in the sense that a service would never see a different value for a given principal, there SHOULD be some period of time during which the identifier is no longer "active" but the association with the principal remains known to the identity provider. The specific duration of that period is subject to policy.
Privacy
This attribute is designed to aid the preservation of user privacy. It is therefore REQUIRED to be opaque, having no particular relationship to the principal's other identifiers, such as a local username or eduPersonPrincipalName. It SHOULD be considerably difficult for an observer to guess the value that would be returned to a given service provider.
It MAY be a pseudorandom value generated and stored by the identity provider, or MAY be derived from some function over the audience's identity and other principal-specific input(s), such as a serial number or UUID assigned by the identity provider.
This attribute is also designed to inhibit, when appropriate, the ability of multiple unrelated services to correlate principal activity by comparing values. This is achieved by varying the identifier based on the intended audience. But as discussed earlier, the specific policy governing the groupings of services, and the actual varying of the identifier is up to the identity provider.
In other words, there is no guarantee of non-correlation, but there is an assumption of non-correlation from the relying party perspective outside of explicitly arranged "Affiliations" of relying parties and cooperating identity providers prepared to recognize them.
Uniqueness
A value of this attribute is intended only for consumption by a specific audience of services (often a single one). Values of this attribute therefore MUST be unique within the namespace of the identity provider and the namespace of the service provider(s) for whom the value is created. The value is "qualified" by these two namespaces and need not be unique outside them; the uniqueness of the attribute value therefore depends on all three pieces of information, and a relying party MUST store/recognize all of them absent additional assumptions.
Reassignment
A distinguishing feature of this attribute is that it prohibits re-assignment. Since the values are opaque, there is no meaning attached to any particular value beyond its identification of the principal. Therefore particular values created by an identity provider MUST NOT be reassigned such that the same value given to a particular relying party refers to two different principals at different points in time. It is allowable (though perhaps confusing) for a given value to refer to two or more different principals when scoped to different audiences.
Human Palatability
This attribute does not meet requirements for human palatability or readability. It is ill-suited for display to end users or administrators, and is not generally useful for privisioning accounts ahead of initial access by users. It may be accompanied by other attributes more suited to such purposes, in which case its privacy properties are presumably of no interest, but its lack of reassignment may well be.
Example applications
Service providers or directory-enabled applications with the need to maintain a persistent but opaque identifier for a given user for purposes of personalization or record-keeping.
Identity or service providers or directory-enabled applications with the need to link an external account to an internal account maintained within their own system. This attribute is often used to represent a long-term account linking relationship between an identity provider and service provider(s).
