Deprecation of SAML2NameID attribute definitions in the IdP v3 vs. need to transmit eduPersonTargetedID as an attribute

[Cantor, Scott]

On 4/17/15, 10:24 AM, "Kaspar Brand" <kaspar.brand at switch.ch> wrote:

>Given that with the IdP v3, both the StoredId data connector and the
>SAML2NameID AttributeDefinition type are flagged as deprecated
>([1],[2]), what would be a future-proof way of wiring the
>eduPersonTargetedID attribute to the shibpid table? Is there a
>possibility to define an attribute based on the output of a
>new-style NameID generator?

No, there's not. I considered that a deprecated feature because there has never been a good reason to pass it as an attribute in SAML 2, only SAML 1. Since all of SAML 1 is sort of deprecated in a general sense, I didn't plug that gap (and it was essentially impossible to do, they're totally separate features).

The actual timeline for removal of the attribute definitions is much more dependent on community input than, say, the String NameID encoders, which are fully duplicated feature-wise. Which is to say, they ain't disappearing any time soon.

The code that actually does the ID generation underneath is shared between the deprecated resolver plugins and the new plugins, so there shouldn't be any value differences in the results even if both were active.

Now, if there's somebody out there who thinks they need to send it as an attribute in SAML 2, that's either a point of confusion or an SP with a bug.

-- Scott