* Jiri Pavlik jiri.pavlik@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.