Attribute definition type for eduPersonTargetedID?

[Peter Schober]

* Cantor, Scott <cantor.2 at osu.edu> [2021-07-26 14:17]:
> What SP claims to "only" support something that virtually no
> software even supports?

Hundreds, potentially:
https://lists.refeds.org/sympa/arc/refeds/2021-07/msg00008.html

> For example in eduGAIN right now there are 3475 SPs 569 of which
> request eduPersonTargetedID (which is concerning in itself, though in
> many cases ePTID will only be requested as part of a set of other
> acceptable alternatives, I would hope, not as the only identifier).
> Only 100 of those also list persistent in a NameIDFormat element, i.e.,
> 469 out of 569 could be seen as not supporting proper persistent
> NameIDs which in turn requires IDPs to support the old and formally
> deprecated eduPersonTargetedID attribute.

I'd have to do further searching (and possibly manual checks) to
determine the likelihood that those SPs positively require ePTID to be
present in order to function.  E.g. I didn't take @isRequired into
account or check for the presence of obvious alternatives also being
requested (as a hint that ePTID is not actually required but accepted
if no other usable identifier is available.)

As to the suspicion (below) about certain implementations being
primarily responsible for the proliferation of the deprecated ePTID
attribute: Looking at the SP's ACS Location value to determine the
SAML implementation out of the 469 SPs requesting ePTID (and not
listing persistent as NameIDFormat) 136 have the string "module.php"
as part of their ACS URL and so are likely of the SSP implemenation,
that's 29%. (For comparison: 197 / 42% are likely Shibboleth SPs,
containing the string "Shibboleth.sso/" in an ACS URL.)

> There was a time that SimpleSAML supposedly didn't support
> persistent NameIDs, something I questioned even at the time. Is that
> really still the case? And why wouldn't it take a very trivial
> change to fix that, unless it doesn't support any NameIDs at all...

SimpleSAMLphp supports NameIDs just fine. It's just that those would
need to be handled explicitly (and differently from attributes) and
most deployers likely never did that.

(FWIW, here's my own suggestion for SSP SPs to handle selected NameID
formats and then use them in a precedence list together with SAML
attributes, much like the Shib SP's REMOTE_USER feature:
https://gitlab.com/-/snippets/2121223
Without something like this -- and I've never heard about anyone else
doing that -- deployers would have to use the SSP API to get at the
NameID in their own code, e.g.:

  $auth = new SimpleSAML_Auth_Simple('sp');
  $nameid = $auth->getAuthData('saml:sp:NameID');
  if ($nameid['Format'] == 'urn:oasis:names:tc:SAML:2.0:nameid-format:persistent') {
    $id = $nameid['NameQualifier'] . '!' . $nameid['SPNameQualifier'] . '!' . $nameid['Value'];
  }
  // handle empty $id or continue with $id with value

And /then/ process the NameID together with any recieved attributes to
get at the preferred or most appropriate identifier. That seems a bit
involved. Hence my guesstimate that most deployers simply never did
that extra work.)

Cheers,
-peter