Advice on planned IdP configuration changes associated with implementing SAML 2

[Julian Williams]

On 11/09/13 15:45, Cantor, Scott wrote:
> On 9/11/13 10:39 AM, "Tom Scavo" <trscavo at gmail.com> wrote:
>
>> On Wed, Sep 11, 2013 at 10:25 AM, Julian Williams
>> <julian.williams at it.ox.ac.uk> wrote:
>>>
>>> 1. That there is no need to include a SAML2 encoding for the old type
>>> of scoped eduPersonTargetedID
>>> (urn:mace:dir:attribute-def:eduPersonTargetedID).
>>
>> That is correct. That URN is strictly a SAML1 construct. See the SAML
>> Attribute Profiles for details:
>>
>> http://middleware.internet2.edu/dir/docs/internet2-mace-dir-saml-attribute
>> s-latest.pdf
>>
>>>  From what I have read it shouldn't be provided in a SAML2 request and
>>> SPs should be able to work without it provided they have the new type of
>>> eduPersonTargetedID. Or are there some instances where a 'legacy'
>>> SP/application might still have to get it?
>>
>> If you send a SAML1 response to the SP, use the URN, but if you send a
>> SAML2 response, use the OID version of the attribute.
>
> Actually you should never use the old URN. That is an improper encoding of
> the attribute, though it's more inaccurately termed "legacy" in the above
> profile. The proper encoding is as a NameID or using the NameID syntax in
> an attribute, the latter using the OID URN for both SAML versions.
>
> See https://wiki.shibboleth.net/confluence/display/SHIB2/NativeSPTargetedID
>
> That also discussed remediation approaches, but those rely on the SPs
> doing work. If they won't help and play their part, there is very little
> you can do to achieve success in any of this.
>

Thanks Tom & Scott for the references and elucidation. It's becoming 
clearer to me and it seems we are on the right track (although I think 
I'll have to reread the refs a few times to take in all the nuances - 
please forgive me).

Julian