[Fim4l] FIM4L guidelines

[Peter Schober]

* Jiri Pavlik <jiri.pavlik at mzk.cz> [2019-05-13 18:38]:
> the most of the SPs provide personalisation features nowadays. So
> ProQuest, for example [...]
> could request eduPersonEntitlement, other attributes leave as
> optional. It should request pairwise-id
> instead of eduPersonTargetedID and support CoCo. When an IdP will
> release just eduPersonEntitlement,
> no personalisation features will be provided - users won't be able to
> download e-books for example.
> When IdP will release eduPersonEntitlement, pairwise-id, name, ...
> personalisation and SSO for personalisation will be provided for
> users.

Again, all that exists today. Still many people are not happy.

Also: As long as both possible consequencs (getting the download but
risking to be tracked across the SP vs. not getting the download) make
all people happy there's no issue here.
I don't think we're in that situation, either.

To your example: An SP that signals adherance to the GEANT Code of
Conduct for Service Providers and asks for pairwise-id really should
get all that it requires. (Assuming that the IDP is not ignorant and
wants to support his members.)
So the desired outcome for an SP requesting pairwise-id and carrying
the CoCo category should essentially always be to recieve the stable
identifier (even without CoCo, really[1]).

But that means the SP can track everything the subject accesses while
logged in (because the stable identifier has been sent by the IDP) --
either that, or the subject will not be able to download e-books,
following your example.
So *whose* *choice* is it and at when? The SP (requesting attributes
from the federation during registration)? The IDP (making statements
about what services get what data for all its subjects)?
The subject can only make those herself if all other parties do their
part to enable the subject to do that, and that includes complex
technologies and user interfaces. (I would want the UI to read
something like: "Consenting to the release pairwise-id will enable
downloads of e-books at the service but also allows the service to
track all access being made while logged in." -- but we don't really
have a place to put this, again contextual, information so that it can
be displayed to the subject at the right time.)

If it's OK with folks here that the subject cannot download e-books --
I don't know whether that's a marginal feature of that SP or its
raison d'être; one SAML SP entity may be used for very different
products, after all! -- I guess this case is simple and no stable
identifer will ever be needed here. If that's not OK for some how will
we get consistent treatment of such services across federations and
institutions?

-peter


[1] I'm skipping some technical details here that CoCo today only
talks about RequestedAttribute elements but signaling for the new
pairwise-id attribute works differently. Likewise the Shibboleth IDP
has rules for releaseing pairwise-id included by default that do not
take other things into account, such as CoCo. We'll still have to gain
more experience and agreement on how best to deal with those, I think.