* Peter Gietz peter.gietz@daasi.de [2019-05-14 16:41]:
Is this just library community bashing? I haven't read anything on this list that "SAML shouldn't be used because it's possible to misconfigure it". This might have been put forward in a blog post that was quoted on the list (to show that parts of the library community have a negative attitude to RA21), but this shouldn't lead to your conclusion, that library representatives (also here) are naively looking for "some magic bullet"... And then you even polemise against libraries as "acting as if they were the last and only defenders of privacy"
If not mentioned here then those are from the RA12 effort and reactions to it. I didn't expect those two efforts to have widely differing actors, aims or target audiences, but I may be wrong.
So a recommendation would probably have to take into account the differences between two types of service: Those that cannot work at all without recognising returning subjects (need a stable identifier for the subject) and those that do not (need as little data as possible) while in both cases still fulfilling requirements to perform access control as needed.
I think this is what we are doing in the guidelines, since we provide even three profiles for three use-cases, but I agree with you the distinction service with need of persitent ID and service not in need is the main distinction.
The guidelines currently only spell out that kind of differences exist between SPs out there in the wild (the options in section 5). If that is all you intended to achieve (labeling the multiple approaches one could take with any given service) then I apologise: I clearly was expecting more from this effort.
SAML Metadata is of course suitable to express this in as much detail as needed on a per-service basis. But if an Entity Category is needed (not that we know it is, yet) that would mean we'd need two different categories, even for the same general use-case of anonymous/pseudonymous access to licensed e-resources: one with the ability to recognise returning subjects, one without.
Is this a real proposal to use entity categories here? It is something different than what I proposed (and sort of took back, see my last post)
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).
-peter