[Fim4l] Elsevier Federated Authentication changes (was RE: Hello and brief intro)

[Shillum, Chris (ELS-NYC)]

Indeed - I think this is probably best done via the creation of a new Entity Category, rather than signalling required/optional attributes in our SP metadata. We've found that support for required/optional attributes across various federations is patchy to say the least. We recently went through an exercise to make our SP metadata as consistent as possible across all federations we participate in, yet we see quite a bit of variability in our metadata in Edugain because of how each federation supports and handles various attributes.

Cheers
Chris

-----Original Message-----
From: Leif Johansson <leifj at sunet.se> 
Sent: Wednesday, 18 September, 2019 3:07 AM
To: fim4l at lists.daasi.de
Subject: Re: [Fim4l] Elsevier Federated Authentication changes (was RE: Hello and brief intro)

On 2019-09-18 00:22, Koren, Meshna (ELS-AMS) wrote:
> Hi Jiri,
> 
> Thanks for your question.
> 
> We are not going to change our metadata in the federations.
> 
> Elsevier SP requires an entitlements attribute through some federations but not all. The reason we don't require it through all federations, yet, is our historical implementation and the fact if we start requiring it from all IdPs, those that aren't able to release it would lose access. We would like to require it as a rule but that is currently just not possible. Adding an entitlement attribute as a requirement to our metadata when we aren't able to honor it would be misleading.
> 
> Elsevier SP recommends the release of ePTID or a Persistent NameID that is being used for personalization. We recommend its release but we don't require it.
> 
> We don't need any other user attributes and those are that being sent to us are just being ignored.
> 
> Kind regards,
> Meshna

This brings up an important point: whatever this group agrees to in terms of signalling for privacy-focused attribute release we have to think about how to transition from whatever is done today to how we want things to work tomorrow.

Any such transition will likely look like a breaking change for the SP for much the same reasons so its probably a good idea for us to think about and discuss some transition strategies.

On idea might be to have multiple SPs for the same entity and involve the federation operator to make a choice to facilitate the transition by filtering one or the other entity. The local federation op is often the one that can communicate with IdP etc

	Cheers Leif