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

[Robert A Basch]

FWIW, we are currently using the SAML2NameID AttributeDefinition type for
ePTID, in IdP 2.4; we would need to do some investigation to make sure
that changing this would not present a problem for any of the SPs to
which we are releasing it.

Bob


On Apr 17, 2015, at 10:32 AM, "Cantor, Scott" <cantor.2 at osu.edu> wrote:

> 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
> 
> -- 
> To unsubscribe from this list send an email to users-unsubscribe at shibboleth.net