on eduPersonTargetedID (ePTID) and SAML interoperability

[Cantor, Scott]

On 4/23/13 10:05 AM, "Roberto Benedetti" <r.benedetti at cineca.it> wrote:

>[1] and [2] are respectively the pieces of assertion coming from a
>Shibboleth and the SUN IdP.

By choice in the first case. What you want it to send is up to you, not
the IdP. If you want to use a NameID instead of an attribute, then you can
do so. Or you can even use both.

>as expected, [1] ends up at the SP side with an environment variable
>made up of the three chunks ("IdP!SP!opaqueID");
>[2] ends up with the SP entityID omitted (as well as not sent by the IdP).

Also a choice. See the documentation on attribute decoding on how to
change that if you want the SP name defaulted in.

>I tried to read the SAML specs [3] as well as some Shibboleth wiki pages
>[4] but I cannot say if the Shibboleth implementation came from the
>specs or if it is the opposite (the egg-or-chicken-problem ;-), anyway
>that product adheres to the specs and the examples given there.

What spec are you asking about?

>is [2] SAML compliant?

Yes.

>would an appropriate encoder populate the missing chunk?

There are scenarios which have been discussed within the last week on the
list about the Shibboleth IdP not populating SPNameQualifier.

A configured decoder on the SP side can deal with that regardless. Many
systems have no need to serialize the data with the SP name included
anyway. The shibboleth.net services don't. Again a choice.

-- Scott