fluidreview?

[Peter Schober]

* Cantor, Scott <cantor.2 at osu.edu> [2015-10-20 20:42]:
> >Any suggestions on getting vendors who want to use the attribute
> version of ePTID to move away from it (since the IdPv3 support for
> ePTID is deprecated)?
> 
> That whole concept has been deprecated for almost a decade, and the
> migration material is in the page I sent you to.

I guess Laim's question abourt "vendors" didn't include the assumption
that the vendor was using the Shibboleth SP software.
(Not sure what advice one expects on that topic on the Shibboleth
software mailing list, though.)

And our community (academic Identity Federations) has done a great job
of hiding/ignoring the fact that ePTID never was needed in SAML2.0.
(With the exception of saml2int.org, which always was clear about
this.)
Many federations embraced the ePTID attribute even when they only ever
supported SAML2.0 (modulo the odd vendor that still only works with
SAML1.)
So this is something we're only starting to tackle now.

And there's no perfect way forward, even for Shibboleth SPs, as
sending the persistent NameID in both the SAML Attribute and the
Assertion's Subject leads to duplicate values, which many such
deployments are not prepared to handle.
Of course everything that's not Shibboleth would need changes, too.
E.g. while SimpleSAMLphp can access and make available the persistent
NameID from the Assertion's Subject, it does not have an easy way of
falling back from the Subject to the Attribute (or vic versa). You'd
have to explicitly code for that case, code that's probably
nonexistent in virtually all SSP deployments.
So lots of changes in lots of places, for very little gain:
Not to support a new attribute or new use-case, but to send the same
data strucure as ever, only in a slightly different place.
-peter