* Bernd Oberknapp bo@ub.uni-freiburg.de [2019-07-18 16:55]:
On 2019-07-18 16:10, Peter Schober wrote:
So either the IDP is /already/ sending a suitable identifier -- in which case the SP does not need to "activate personalisation" as all requests are traced back to an identified individual (even if that individual is not known by name from the data the IDP provided) -- or the IDP is /not/ sending such an identifier in which case you cannot add "personalisation" to that federated login.
Elsevier forces users to register with their names and email addresses (and maybe also additional data), otherwise the personalized features cannot be used, even though the IdP sends a suitable identifier.
Oh my... :(
This could be regarded as activating the personalization. While asking the users for additional data in exchange for the personalized features might be okay, this of course shouldn't be the recommendation.
So it's not enough to provide them with the ability to track every movement and every resource one accesses (based on a pseudonymous identifier released by the IDP), they will /only/ offer you the benefit of personalisation features if you /also/ tell them exctly who you are with name and email?!
Of course that fully undermines the point of sending them pseudonymous identifiers in the first place. So this more of a collection of anti-patterns contrary to what Jiří suggested:
* Jiri Pavlik jiri.pavlik@mzk.cz [2019-07-18 14:49]:
This is very close match with our FIM4L guidelines and recommendations.
As to the other case:
If the IdP doesn't send a suitable identifier, the users cannot use personalized features on the Elsevier platforms, they can't even register a personal account as with IP access.
Offering that may not be part of any recommendationy yet but clearly is another drawback in this case. Though it's of course not an easy task to combine all access methods and authorisation modes in functionally useful ways (and without throwing out the window any remains of patron privacy). I don't know how many SPs support creation of local accounts (not that those would consitute any kind of best practice[1]) and additionally are able to track which resources you're authorised to access on each request based on your current IP address, e.g. as you're moving on- or off-campus even while logged in to their system. (I know a local publisher that does just that and now adding federated logins to that system makes things quite involved.)
-peter
[1] Due to password overload and re-use of passwords across systems, though WebAuthn may well change that.