[Fim4l] FIM4L guidelines

[Peter Schober]

* Bernd Oberknapp <bo at 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.)