Hi List,
erroneously this discussion was without CC to the list. Well here it is.
Cheers,
Peter
-------- Weitergeleitete Nachricht --------
Betreff: Re: ICOLC & FIM4L
Datum: Thu, 23 May 2019 13:16:46 +0200
Von: Peter Gietz <peter.gietz(a)daasi.de>
An:
Hi Jos,
Thanks a lot for this very interesting pointer. I think the ALR comments
make the FIM4L activity even more important, since we address at least
parts of the gaps analyzed by ALR.
1.) Obviously this is the case with regards to privacy and I feel
encouraged to stick to our current recommendations but also to be more
explicit and detailed about the potential privacy related consequences.
To not further delay of the publication of the guidelines I would like
to propose to star another document only dealing with privacy related
consequences of FIM.
The other two main subjects of the ALR gap analysis are:
2.) accessibility aspects, which are more directly directed to the RA21
Javascript-enhancements for easing the discovery process, where I am
unsure whether FIM4L should take this up
3.) auditing and statistics: Here I do see FIM4L subject space and again
I would recommend to write yet another document on that, instead of
addressing too much more (than the already discussed attribute for
statistics) in tzhe guidelines text.
As to your question: I very much propose to try to get ALR into FIM4L.
Cheers,
Peter
Am 22.05.19 um 09:33 schrieb Jos Westerbeke:
> Hi,
>
> An interesting response from ARL to RA21:
> https://www.arl.org/news/arl-news/4780-arl-comments-on-ra21-proposal-for-ac…
>
> Should we reach out to ARL?
>
> cheers,
> Jos
>
--
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(a)daasi.de
web: www.daasi.de
Sitz der Gesellschaft: Tübingen
Registergericht: Amtsgericht Stuttgart, HRB 382175
Geschäftsleitung: Peter Gietz
A more general take on the "service requires no personal data"
vs. "services requires to recognise returning subjects" vs. "some
functionality of the service requires recognising returning subjects"
problem in conjunction with FIM, prompted by off-list communications:
One of the open issues is that an SP simply cannot offer any
personalisation based on federated authentication (i.e., ask the
subject for more data when needed) *unless* the IDP already sent along
an identifier that allows the SP to recognise the subject every time.
I've made a note for this here
https://docs.google.com/document/d/1pIaEXfw9ZWnXM4p6Dd2Lri7RFWKgr7ObKLEGfUy…
but this needs more words than are appropriate to add there.
At the point of sending an stable identifier along during login
("option 5.b" in the document) some people are already up in arms --
see some of the comments submitted on the RA21 paper[1] and the two
articles that prompted the "myth busting"-response[2] -- because if
IDPs now always send along (even opaque, pairwise/SP-specific)
identifiers with every login (in order to enable the SP to provide
personalisation features) that also necessarily allows an SP to track
every access from that subject to that SP while being logged in
(whether such tracking happens or not; it's then possible).
Which would arguably lessen the subject's privacy compared to some
other access models, e.g. if access only comes from/via an
EZproxy/reverse proxy server it's the proxy's IP address and HTTP User
Agent that the publisher sees, not the subject's. The presence of the
proxy makes tracking of accessed content per subject more difficult,
though certainly not impossible given modern and ever-improving
de-anonymisation techniques. (I.e., the privacy-enhancing features or
side-effects of reverse proxies will only diminish over time due to
the increasing compexity of web applications. An arms race that
proxies will not be able to keep up with, IMHO.)
Note that I'm not saying that reverse proxying is the overall
preferrable model over FIM -- it's major drawback lies in the
assumption of a certain access starting point during content discovery
(also no standards exist for their behaviour or configuration) -- and
the privacy protection proxies can offer will be reduced going
forward as claimed above.
There are a few ways to deal with this:
1. Accept the potential consequences of user tracking (while enabling
easy access to all features at SPs, including those that require
personalisation) by recommending to always send along an opaque
service-specific identifier.
2. Prevent easy personalisation by recommending to avoid sending along
any (stable) identifiers.
Of course offering personalisation would still be possible but it will
require the subject to register a local account with the publisher,
resulting in other problems:
2.1 Authorization: Since the subject is authorized to access licensed
resources on behalf of the institution/library covering the license
costs a local login to the SP using SP-issued credentials breaks the
connection the subject has with its linstitution/library (and therfore
the signal whether the subject is authorized to access a given
resource is lost -- or at least frozen at the point of registration of
the local account. Changes in the affiliation the subject has with the
linstitution/library cannot be reflected automatically when using the
local account).
2.2 Ease of use: Having to register and maintain a local account with
the SP -- with *every* SP I need to rely on features that require
personalisation -- means having to manage Yet Another Username and
Password. And this often comes with hightened support costs and may
also raise the barrier to get legal access to the desired
resources/features due to having to manage another set of credentials.
2.3 Security: There should be plenty of evidenve that subjects to not
manage credentials for the many web sites well (or securely) and that
re-use of credentials across independent sites creates security many
problems.
3. I guess one could also try to categorise SPs into two separate,
non-overlapping sets: Those that require personalisation and those
that do not.
Not sure how useful such a distinction would be going forward, when
more personalisation may be added by platform providers (or expected
by subjects using those platforms) or how (and by whom) the decision
what category a publisher/SP should be in would be made for each SP.
4. Technically it's possible today to have the IDP ask the subject to
consent before sending data along to an SP. But there is no technology
widely deployed that can make that process sufficiently easy to use
and understand here, IMO.
(E.g. required attributes -- those granting access based on purely
non-personal data signalling the institution's assertion that the
subject should be allowed access -- should always be sent, but asking
the subject for consent may lead to the subject not enabling release
of that data, resulting in "Access Denied" errors at the SP, which
may not be that easy/obvious to be fixed by the subject.
Similarly, optional identifying data would have to be conciously
allowed by the subject -- but only if/when s/he intends to use
personalisation at the given SP -- but there's noone there to inform
the subject about the finer details of this decision at this
point. Should the IDP then remember that choice? Or ask every time?
Or ask when to ask again? Too much choice here is bad as the UX can
easily be overwhelming, resulting in bad decisions, etc.)
So 4 is probably too hard to get deployed and to get done right
everywhere (esp. if people already think releasing name and email by
mistake is too easy as it is in current systems).
I'm not sure 3 provides enough benefit/s to justify the problems in
getting it deployed.
Which would mostly leave options 1 or 2 for us to recommend:
* Accept tracking possibilities by publishers (and the fact that we
might not prevent that even with reverse proxies going forward),
or
* Accept that no (easy, secure) personalisation will be possible and
that personalisation offered still has problems with tying local
accounts at the SP to institutionally licensed content.
TBH I don't know what listing the options in section 5 of the
guidelines draft is intended to achieve -- that each SP is clearly
sorted into one of those classes (I'm avoiding the term "category"
here)? Or that each IDP picks their local preference?
The aim of this activity should be a consistent, easily-understood and
easily-deployed set of guidelines, right? So how many "options" would
still be presented on equal terms next to each other in such a
document?
Best regards,
-peter
[1] https://groups.niso.org/apps/group_public/document.php?document_id=21376
[2] https://scholarlykitchen.sspnet.org/2018/02/07/myth-busting-five-commonly-h…
Hello Tom,
Thank you so much for joining us and for your kind words!
I'm very pleased and we very welcome US libraries, especially those from the "Stanford Statement";)
And thank you for your contributions to the Guidelines document. You're welcome!
thanks,
Jos
From: FIM4L <fim4l-bounces(a)lists.daasi.de> on behalf of Tom Cramer <tcramer(a)stanford.edu>
Date: Thursday, 16 May 2019 at 05:09
To: "fim4l(a)lists.daasi.de" <fim4l(a)lists.daasi.de>
Subject: [Fim4l] introductions
Hello fim4l,
I am a recent member of this list, and am writing to introduce myself. I am the CTO and director of technology for the Stanford University Libraries; I helped draft the "Stanford statement" on privacy<https://library.stanford.edu/using/special-policies/statement-patron-privac…> and have been tracking (and commenting on) the RA21 draft specifications.
This list came to my attention after one of the current members (hi Jos) reached out to a colleague after the Stanford statement was published, and after fim4l was highlighted in discussions of RA21 with members of the Ivy Plus Libraries Confederation in the US. (Hi Heather.)
I have been following the discussion on this list for the last month, and have found it quite illuminating.
First off, thank you for doing this work; not enough attention has been paid to bridging the business concerns of libraries with the technology and power offered by federated identity management.
Second, I am pleased that as with GDPR, Europe is perhaps more advanced than the US in these matters. I hope those of us from US institutions might benefit from your work, and also contribute to the discussions.
Third, I have made several suggestions and comments on the draft guidelines & recommendations<https://docs.google.com/document/d/1pIaEXfw9ZWnXM4p6Dd2Lri7RFWKgr7ObKLEGfUy…>. I hope they are useful. In some cases, the suggestions may be questions, or comments based on uncertainty around some of the intricacies of attributes.
Finally, from a library and privacy perspective, I believe both the list discussion and the draft recommendations would benefit by focusing on establishing a minimal set of attributes to be released, and then exploring how individual users might explicitly allow more sharing of attributes through their IdP (such as Duke University has developed), or through decoration of a user profile by the user post-authn.
Best regards,
- Tom
| Tom Cramer
| Associate University Librarian
| Director, Digital Library Systems & Services
| Chief Technology Strategist
| Stanford University Libraries
| tcramer(a)stanford.edu<mailto:tcramer@stanford.edu>
Dear all,
let me share with you an issue which Charles University is facing at
Cambridge Core.
Charles University is running evidence based acquisition trial at
Cambridge Core [1]. The university will select e-books according to
usage reports once the trial period is over. Cambridge University
Press is able to provide usage statistics for whole university and
also for its faculties based on IP address ranges. Cambridge
University Press is not able to provide any usage statistics for
off-campus usage based on users affiliations provided in federated
authentication.
Hoping that FIM4L guidelines and recommendations could help to fix
also such kind of issues.
Have a nice weekend everyone
Jiri
1. https://www.cambridge.org/core/services/librarians/evidence-based-acquisiti…
Hello fim4l,
I am a recent member of this list, and am writing to introduce myself. I am the CTO and director of technology for the Stanford University Libraries; I helped draft the "Stanford statement" on privacy<https://library.stanford.edu/using/special-policies/statement-patron-privac…> and have been tracking (and commenting on) the RA21 draft specifications.
This list came to my attention after one of the current members (hi Jos) reached out to a colleague after the Stanford statement was published, and after fim4l was highlighted in discussions of RA21 with members of the Ivy Plus Libraries Confederation in the US. (Hi Heather.)
I have been following the discussion on this list for the last month, and have found it quite illuminating.
First off, thank you for doing this work; not enough attention has been paid to bridging the business concerns of libraries with the technology and power offered by federated identity management.
Second, I am pleased that as with GDPR, Europe is perhaps more advanced than the US in these matters. I hope those of us from US institutions might benefit from your work, and also contribute to the discussions.
Third, I have made several suggestions and comments on the draft guidelines & recommendations<https://docs.google.com/document/d/1pIaEXfw9ZWnXM4p6Dd2Lri7RFWKgr7ObKLEGfUy…>. I hope they are useful. In some cases, the suggestions may be questions, or comments based on uncertainty around some of the intricacies of attributes.
Finally, from a library and privacy perspective, I believe both the list discussion and the draft recommendations would benefit by focusing on establishing a minimal set of attributes to be released, and then exploring how individual users might explicitly allow more sharing of attributes through their IdP (such as Duke University has developed), or through decoration of a user profile by the user post-authn.
Best regards,
- Tom
| Tom Cramer
| Associate University Librarian
| Director, Digital Library Systems & Services
| Chief Technology Strategist
| Stanford University Libraries
| tcramer(a)stanford.edu<mailto:tcramer@stanford.edu>
Hi,
you may like to have a look at RA21 webinar tomorrow and OpenAthens
Wayfinder short presentation from OpenAthens Conference 2019 -
https://www.youtube.com/watch?v=XtIBHT1ik9o&list=PLa3SZHu7wc-D1_Ssl0oP8F587…
Best regards
Jiri
---------- Forwarded message ---------
From: Julia Wallace <julia(a)ra21.org>
Date: Mon, Apr 29, 2019 at 2:46 PM
Subject: Reminder: 30 April 2019 - RA21 webinar
To: <announce(a)ra21.simplelists.com>
Reminder:
Following the release of the draft NISO Recommended Practice on
Improved Access to Institutionally-Provided Information Resources
arising from RA21, you are invited to join a public RA21 webinar on
April 30, 2019 at 10:00 – 11.00 AM Eastern Time (US and Canada) /16.00
- 17.00 CEST.
Ralph Youngen (ACS) co-chair RA21, Chris Shillum (Elsevier) co-chair
RA21 and Todd Carpenter, Executive Director of NISO will present and
demonstrate the RA21 solution and associated best practice
recommendations, explaining what publishers, platform providers and
other service providers need to know about implementation.
Further information at:
https://www.niso.org/events/2019/04/niso-working-group-connections-live-res…
No registration is required.
We would like to keep you informed of developments in RA21. If you
would prefer not to receive news updates, please either use the
unsubscribe function or contact julia(a)RA21.org to opt out from
further messages.
To unsubscribe from this list please go to
http://www.simplelists.com/confirm.php?u=NIaVDGWHiuDtEQ2BRo6RLhZQc6DgC6pD
Hi all,
Just a short question: Who is at the TNC conference in Estonia? (https://tnc19.geant.org/ )
These have planned already: Peter, Barbara, Heather, Sander, ...
Maybe there could be a chance to meet each other.
cheers,
Jos
(I hope I can manage it to be there too;)
Sorry, late to the party (catching up with email):
Who am I? I work for Jisc (the UK NREN operator) in the Trust & Identity directorate. Why am I here? Because I was involved in FIM4R, it makes sense for me to keep an eye on what others are doing elsewhere (like RA21 and FIM4L).
I'm ok with having my name published, although it's not as an official Jisc representative for libraries (I believe we have other people who are more appropriate and who were informed of this list's existence).
:-)
Stefan Paetow
Consultant, Trust and Identity
t: +44 (0)1235 822 125
gpg: 0x3FCE5142
xmpp: stefanp(a)jabber.dev.ja.net
skype: stefan.paetow.janet
jisc.ac.uk
Jisc is a registered charity (number 1149740) and a company limited by guarantee which is registered in England under Company No. 5747339, VAT No. GB 197 0632 86. Jisc’s registered office is: One Castlepark, Tower Hill, Bristol, BS2 0JA. T 0203 697 5800.
From: FIM4L <fim4l-bounces(a)lists.daasi.de> on behalf of Jos Westerbeke <jos.westerbeke(a)eur.nl>
Date: Thursday, 11 April 2019 at 14:16
To: "Fim4l(a)lists.daasi.de" <Fim4l(a)lists.daasi.de>
Subject: [Fim4l] Participants of FIM4L - list update
Dear participants of the FIM4L initiative,
The email list of FIM4L is growing. That's a good thing; we get attention from libraries, NREN's, and many supportive partners, from EU and recently the US. (As you can see in the email just send by Peter G. containing a PDF with names for the charter doc.)
To keep track of all participants of FIM4L, we decided in our last call to ask every participant for a short introduction. At least your name, function and affiliation. And why you're on FIM4L would be nice too. Just because many of the list don't know everyone involved.
We also want to ask you whether you're fine with publishing your institution and personal name on the http://fim4l.org website. (in development)
Future participants will be asked to give a short introduction too.
So, could you please give:
1. short intro
2. consent to publish your name on website (name and affiliation only)
@Gerrit: thank you for your already given extensive intro!
Thank you in advance!
Jos
