Hi Peter S.,
This post is quite strange and could probably be seen as offensive.
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"
I hope it is just that you didn't have a good day ...
What I find interesting in your post is:
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.
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)
Cheers,
Peter
Am 13.05.2019 um 12:47 schrieb Peter Schober:
- Bernd Oberknapp bo@ub.uni-freiburg.de [2019-05-11 12:38]:
Regarding RA21, this is to some extend based on the fact that some publishers already have tried to enforce in contract negotiations, with reference to RA21, that libraries switch to SAML as the only authentication method and in some cases that they not only provide a persistent/targeted/pairwise ID but also personal data like names and email addresses.
So on the one hand libraries agree to such contract terms -- releasing other people's personal data to such publishers for no reason and without a legal basis (for the sake of the argument we'll have to assume that the SP does not in fact need any of that data, otherwise there'd be no problem to begin with) -- on the other hand libraries here are campaigning and acting as if they were the last and only defenders of privacy.
The argument (made earlier on this list, IIRC) that SAML shouldn't be used because it's possible to misconfigure it is also interesting. Web and e-mail servers can also be (and sometimes are) misconfigured, sometimes resulting in leaking personal data. Still that doesn't stop anyone from using the technology. Why should this be different for SAML?
Wanting some magic bullet that works consistently everywhere everytime, is secure (per the current state of the art), is as privacy preserving as possible but sufficiently flexible to cater to all relevant use-cases, requires no client set-up whatsoever, does not require subjects to change their content discovery strategies or tools and CANNOT POSSIBLY BE MISCONFIGURED to "leak" personal data... is an interesting set of requirements. I'd sure like to see any alternative that satisfies those criteria.
That's why many libraries, at least in Germany, wouldn't support any recommendation that promotes SAML as the only authentication method or doesn't include anonymous access via SAML.
A blanket recommendation to send more data than is (sometimes) necessary would violate fundamental principles of data protection (minimalism) and would possibly risk violating European data protection law. (Though you might ask at what point you're trying to be more catholic than the pope.)
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. 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.
Whether that added granularity is worth the added complexity (yet something that could be misconfigured!) -- for the exact same use-case -- is an open question. Seems we're in for another contradiction: Libraries want stuff that cannot be misconfigured, but they also need more than "one-size-fits-all" to ensure the least amount of data is sent for each of the common cases.
Unless we know that the "cannot work at all without recognising returning subjects" case is not a current (and will not become a common) requirement? Then a single category (or configuration recommendation) would suffice, one that would not recommend to release a stable idenifier for the subject.
Of course then we're still left with the problem of optional personalisation (resulting in Yet Another Username and Password for the subject, at each and every SP where that's required for the desired featurs to work).
-peter _______________________________________________ FIM4L mailing list FIM4L@lists.daasi.de http://lists.daasi.de/listinfo/fim4l