[Fim4l] Statistics issue use-case

Peter Gietz peter.gietz at daasi.de
Tue May 14 16:41:12 CEST 2019


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 at 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 at lists.daasi.de
> http://lists.daasi.de/listinfo/fim4l

-- 

Peter Gietz, CEO

DAASI International GmbH
Europaplatz 3
D-72072 Tübingen
Germany

phone: +49 7071 407109-0
fax:   +49 7071 407109-9
email: peter.gietz at daasi.de
web:   www.daasi.de

Sitz der Gesellschaft: Tübingen
Registergericht: Amtsgericht Stuttgart, HRB 382175
Geschäftsleitung: Peter Gietz




More information about the FIM4L mailing list