Meshna et al.,
When I proposed a way forward to enable (optional) personalisation features without the subject having a say about it: https://lists.daasi.de/pipermail/fim4l/2021-March/000432.html I explicitly excluded "local account registration" to keep this somewhat shorter and on-topic. Your own description heavily featured local account registration as an alternative means to achieve that so I'll finally (sorry for the delay) comment on that below.
* Koren, Meshna (ELS-AMS) M.Koren@elsevier.com [2021-03-16 09:32]:
they click on 'register' or the equivalent and are able to create local account, sometimes providing some additional information about themselves. <- There's nothing preventing them from focusing on the topic of their research in this flow and a local account will be linked to their pseudonymous ID.
Next time they return via their institution, they will get access to other articles *and* their personal features.
Such a user has one set of credentials rather than 4 separate ones. They don't need to remember multiple creds and passwords, change them at random times
Taken the above literally ("a local account will be linked to their pseudonymous ID") it would be easy to discount this solely on the fact that nowhere near all institutions/libraries today will be releasing such identifiers, "just in case", for optional personalisation features.
And if they /did/ always release a stable identifier the suggested "registration" for a "local account" wouldn't even be necessary as you'd already have a stable identifier to recognise returning subjects, i.e., you could already offer personalisation features without having to force/nudge the subject into creating a local account. In fact, it would be virtually identical to my proposal https://lists.daasi.de/pipermail/fim4l/2021-March/000432.html if you simply called the link for "local account registration" something like "Activate personalisation". Only in my proposal you'd ask that right away (at/immedeately after the subject logs in via her institution), making it clear(er) that no use of the identifier is being made before the subject has had a chance to dis-/agree. Whereas you are arguing for a (probably) less disruptive UX of asking *later* that comes at the cost of increased trust requirements that the service provider is not making use of that identifier before the subject was ever asked. (*Maybe* that latter difference is small enough that it could be rolled into one common approach. To the extent that the proposals benefit from having a stable identifier sent by the institution/library present I think it may make sense to tune things towards earning that trust.)
Taking the above less literally (at least) parts of your proposed method -- using local account registartion as the means to enable optional personalisation -- are possible to implement even without a stable identifier having been sent by the institution/library. (In fact the behaviour at the SP is identical in both cases: The subject logs in via her instiution and has a valid session at the SP. In that session they create a "local account" that's then tied to their institutional log in by having both connected to the same SP session.)
Such a user has one set of credentials rather than 4 separate ones. They don't need to remember multiple creds and passwords, change them at random times
If the subject registers for a "local account" how's that not yet another "set of credentials" for her, in addition to the institutional account she had to use at least initially in order to prove her affiliation with the academic institution (which is what authorised her to access the resource in the first place, most likely)? That's still "multiple credentials" -- unless your use of what "register" and "local account" means here is totally different from mine. (As for a possible reading of "register account" to actually mean "activate personalisation"" see above.) To me an account always has a passwort of some kind associated with it, making this yet another "set of credentials".
And finally, any use of the local account would regularly needed to be prompted to be "re-linked" with the institution/library or otherwise lose access to resources only available through (continued) affiliation with the institution/library paying for that access: I don't see either your legal dept nor institutions being happy if you continned to provided access to institutionally licensed resources to people using locally registered acounts, without checking back whether those people are still considered to be entitled to that access by the institutions they initially used to log in with. We've had that conversation a bit over a year ago on the REFEDS list: https://lists.refeds.org/sympa/arc/refeds/2020-01/msg00019.html (were I argued that this is mostly your own problem, *IF* it was clear to everyone that institutions couldn't be held liable for any misuse resulting from that kind of access) but noone else ever chimed in there. Maybe re-starting this particular sub-topic here will give different results (once can always hope).
To summarise, I don't see any clear advantages in having subjects "register local accounts" -- neither in terms of UX (need to register an local account) nor security (Yet Another Username/Password for the local account) nor privacy (when identifiers from the institution or library are involved) nor licensing/legal certainty (due to the separation of the login method from the source of current authorisation data) -- that wouldn't be possible by implementing my proposal. (Which amounts to institutions/libraries always releasing a pseudonymous identifier to service providers of a certain category, where the service provider commits itself to asking the subject before making any use of the identifer for tracking/personalisation.)
Best regards, -peter