[Fim4l] Scopus

[Peter Schober]

* Jiri Pavlik <jiri.pavlik at 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.com%252F/?federation=aconet-identity-federation-eduidat
>
> 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