* Jiri Pavlik jiri.pavlik@mzk.cz [2019-07-18 14:49]:
Elsevier requests eduPersonTargetedID and eduPersonEntitlement attributes in metadata at eduID.at for Scopus and other services - https://met.refeds.org/met/entity/https%253A%252F%252Fsdauth.sciencedirect.c...
Requested attributes are missing in eduGAIN metadata -
Note that we also include a proper persistent NameID in our copy of the Elsevier Scopus SP: <NameIDFormat>urn:oasis:names:tc:SAML:2.0:nameid-format:persistent</NameIDFormat> which most other federations are missing as well.
At Scopus users can activate personalisation adding name and e-mail address. A screenshot attached.
Sorry, but no: It's simply impossible to "activate personalisation" on top of a federated login if the IDP does not already release an identifier that allows the SP to recognise a returning subject.
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.
(This is why "optional personalisation" by choice of the SP or of the subject herself is a hard problem to solve cleanly: Anything/-one deciding that outside/after the IDP is simply too late: Either the SP can always track the subject whether the subject wants personalisation or not or no subject from an IDP can get personalisation at that SP if the relevant IDP decided not to release a suitable identifier.)
In that second case the only way to "activate personalisation" is to force the subject to register and use Yet Another local account (with Yet Another Password) to log in /instead/ of using the institutionally provided one. But this local account then isn't easily connected with any institutionally licensed resources so that creates not only the problem of increased password overload but also of authorisation:
Either you'd always have to log in /twice/ now -- first via your institution, to get access to institutionally licensed content, then again using Yet Another Username and Password, to get personalisation features -- which could be considered the worst possible user experience. Or the SP "tags" your locally registered Yet Another Account to be authorised with your institutional affiliation but then this creates the issue of when you'd lose those rights again: If access rights are transfered from a federated login (with only an entitlement or scoped affiliation) to a locally registered account in a one-time event how would I ever lose those rights when going forward I'll only be using the local account to log in (in order to benefit from personalisation)? Never? After some default period after which I'd have to log in twice (see above), again?
I have zero experience with how publishers are doing any of that in practice and I'm doubtful that registering local accounts (and logging in with those each time) is an appropriate measure only in order to allow personalisation features, btu YMMV.
But unless I'm overlooking something rather fundamental offering local account registration cannot be seen to be in line with any kind of best practices, IMHO.
Best, -peter