* Peter Gietz peter.gietz@daasi.de [2019-03-20 19:30]:
I know, but it is a common fear in the library community and we should therefore address such fears.
OK. I merely tried to analyse the arguments presented in that article and I'm happy to hear that my positions are not contentious as far as this group is concerned. (At least the Peters agree! ;))
Some other things worth mentioning:
Strategically I wouldn't want to be advocating for a regime change from IP-based auth to FIM (in case anyone assumed that), simply because the UX with IP-based auth when the subject is on-campus/on-premise is unsurpassed and can never be matched by FIM. (For off-campus/off-site it's more of the reverse, sadly, and so we want both, IMO.) FWIW, I know of one local (and not generalisable) use-case where the publisher tried to get rid of any and all IP-based access and argued this with fulfilling the academic institutions' own long-stanading requests for SAML support. (Basically: "Here's the SAML support you asked for for the last 10 years. Now it's the only access method. I hope you're happy.") I don't know where this group intends to take things but I'd agree that there's a certain danger in asking for e.g. SAML support and then losing IP-based access in the process. Though the above is the sole exception to a vast amount of e-resource providers that just added SAML to the existing methods available instead of replaced existing ones that had (some) desirable properties. (And of course managing "authorised" IP ranges is a drag, esp if done in manual out-of-band workflows. Not sure it's worth investing effort into making that more automated or scale better in the general case, though.)
The other issue is the fate of the eduPersonTargetedID attribute. I'd hate to see anything remotely resembling Best Current Practices or Recommendations, esp ones newly published, that promoted/prolonged use of this historical artefact. Of course we have to get from where we are (some existing support for eduPersonTargetedID, some existing support for proper persistent SAML 2.0 NameIDs) to SAML pairwise-id, but any language that makes continued use of that legacy attribute "OK" might be actively damaging. (Note that any IDP already supporting ePTID should also be able to support pairwise-id, it's actually much simpler. So by allowing legacy bahaviour into new guidelines this would potentially undermine global efforts to get away from ePTID.)
But let's first see whether the federation community can actually muster up their courage to finally "deprecate" ePTID. If that happens I'm firmly counting on FIM4L not to subvert this effort.
-peter