On 14.05.19 17:08, Peter Schober wrote:
Leaving the Entity Category specifics (as that's about implementation and "how", whereas we're still talking about the "what"/"why"):
Yes, I meant what I wrote above. If we cannot agree on "the one" method to recommend (which I was aiming/hoping for, possibly as consequence of a misunderstanding of how much this group wanted to achieve) then the main point of contention seems to be an SPs [in]ability to track subjects accessing its resources over multiple visits, i.e., the stable identifier. So maybe two "buckets" for SPs could be defined. But I also explained (option 3, IIRC) how any form of classification of SPs may fall short with SPs offering multiple services with multiple requirements, etc. and how to determine if a given SPs "needs" a stable identifier for subjects or doesn't -- as that requires specific knowledge of all the services offered by a given SP and which of those wouldn't work without a stable identifier and how essential those are vs. some core service that's available without the identifier, etc. I.e., if such a complicated and deep analysis of every SP will still be required to be performed by every IDP, what has been gained?
So to me the only positive outcome of an effort would be to significantly improve on the status quo (by weighing the hard issues and suggesting one compromise widely applicable, even if not ideal anywhere). I just don't see how saying "there are SPs that do require PII and ones that don't" in a guidelines document is going to achieve that (or anything, really).
My expectation would be that we define requirements and recommendations from the library perpective that, if followed by the SPs and IdPs, would avoid most of these issues. This probably should include the recommendations to not use the same entityID for multiple services with different attribute requirements and to avoid using proxy SPs (single SP/entityID for multiple platforms, as currently used by Atypon and Highwire).
The starting point in my opinion should be a "basic service", that is authorization based on standard attributes/attribute values and optionally personalization if a stable identifier is available. An entity category for this basic service would simplify the attribute release configuration, and it still would allow the institutions to decide whether to release or not release a stable identifier or to leave that choice to the user (if they have a technical solution for that). The entity category also would signal to the institutions that the service works with just these attributes. If more SPs would offer such a basic service and also a better UX, including the RA21 discovery and meaningfull error message if something goes wrong, this already would be a big improvement compared with the situation today.
I'm not sure if it would make sense to include more attributes in the basic service to cover more cases, for example email address and name. These attributes would have to be optional, and the application might have to ask the user for this information in some cases. Of course it only would make sense to release these attributes when a stable identifier is also released which makes the situation more complex.
Best regards, Bernd