* Bernd Oberknapp bo@ub.uni-freiburg.de [2019-05-13 17:08]:
The recommendation for the SPs clearly should be to offer personalization based on a stable identifier, but to not require such an identifier (or any other personal). Then it is up to the IdP and library to decide whether such an identifier should be released (option 1), should not be released (option 2) or should be released optionally (option 4). I don't think we will all agree on one of the options, so maybe we should simply describe them and their advantages and disadvantages?
If that's all this group tries to achieve (i.e, tell people what could be done, out of a list of possible ways to deal with it, leaving both institutions and publishers with the full complexity that exists today) then is there much harmonisation -- and from that: cost savings through consistent, widely-scalabe configruation, increased usage of easily accessible resources, etc. -- to be gained?
As for the (lack of) one-size-fits-all approach: I mentioned option 3 for that: Create a bucket for SPs depending on whether they require stable personal identifiers. But maybe sometimes that is not easy to determine, give the increasing product portfolio and applications available to licensees?
My preferred choice actually would be option 4, i.e. offer the user to choice to release a stable identifier for personalization along with the required attributes for authorization, with the default that no identifier would be released.
Sure, but the software for doing this in a somewhat user-friendly matter isn't even released[1]. And even then it's the most technically challanging thing to achieve, and has to be done at each IDP. (Again, we're including library folks here that complain that SAML is at fault if a misconfigured IDP released name and email to publisher SPs that did not need that data.)
Cheers, -peter
[1] GakuNin recently released a version of their UAPproveJP software that can prevent the de-selection of required attributes when using the per-attribute consent feature. (You can still decide not to consent by not continuing, but if you do the required attributes will always be there. Of course that's limited to the expressivity of SAML Metadata wrt required/optional attributes, esp if in common one-out-of-several-attributes-is-required cases, but may be good enough here.) Without that per-attribute consent is pretty much unworkable, IMO, and so I don't expect to see much/any deployment of that before this new feature becomes more mainstream. And that alone might take years (and only applies to the Shibboleth software. No other commonly used SAML IDP implementation can do even that, AFAIK.)