* Jiri Pavlik <jiri.pavlik@techlib.cz> [2021-03-11 09:05]:
> I am wondering whether everyone could be fine with following set of
> attributes along with CoCo and Sirtfy entity categories support:
> eduPersonScopedAffiliation (required)
> eduPersonTargetedID (optional)
> givenName  (optional)
> sn   (optional)
> mail  (optional)

Ignoring the fact that ultimately existing bilateral (or consortial)
contracts (here with LN) will always trump what GÉANT CoCo says, note
that CoCo v1 (the only released version that currently exists)
explicitly only covers strictly *required* (isRequired="true" in SAML
Metadata) attributes. It cannot be used for optional data.
  People should also be aware that there is no clear indication that
LexisNexis even intended to adhere to the GÉANT CoCo specification:
All that I've seen so far is RENATER's claim that the LN SP is covered
by CoCo. But CoCo also requires that the Privacy Policy for a SAML SP
adhering to CoCo contains a reference to the GÉANT CoCo and this is
NOT the case with LexisNexis here (not even in the URL referenced in
the RENATER metadata).
  So the CoCo-support of the LexisNexis SP is (1) highly questionable,
IMO, and (2) very likely meaningless in light of actual contracts
governing use of / access to the service.

As to the actual question above: If the service continues to work fine
with only the commonly released minimal set of data (common-lib-terms
or eduPersonScopedAffiliation for authorisation; SAML persistent
NameID or eduPersonTargetedID or SAML pairwise-id for personalisation
functionality) I see no reason to change anything in order to encourge
institutions to send *more* personal data to the publisher.
(And even if we did, what makes LN so special here? Wouldn't we also
have to have this discussion then for every other of the hundreds of
SPs we have for "institutionally licensed e-resource access"?)

Best regards,
-peter
_______________________________________________
FIM4L mailing list
FIM4L@lists.daasi.de
http://lists.daasi.de/listinfo/fim4l