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
Dear all,
many thanks for your comments and discussions. There is new simplified
wrap up at FIM4L Guidelines and recommendations draft reflecting the
comments and discussions -
https://docs.google.com/document/d/1pIaEXfw9ZWnXM4p6Dd2Lri7RFWKgr7ObKLEGfUy…
Once everyone is fine with the new simplified wrap up it will replace
the current one.
Sunny regards from Prague
Jiri
Dear Colleague,
We would value your insights as we explore the future of access to
research and scholarly services.
SHARE YOUR OPINIONS IN A SURVEY
More than 60 countries collaboratively operate a global federated
identity infrastructure that enables scholars, researchers, students,
and staff to login to academic resources and services. This
infrastructure helps to enable research and scholarly activities by
giving users a simple single sign-on experience using their home
institution credentials.
The international organisation representing this global effort, called
REFEDS <https://refeds.org/>, is undertaking a strategic review of how
the global identity infrastructure affects individuals and what
circumstances may arise over the next 10-15 years that operators of this
global infrastructure should anticipate and prepare for. Please share
your input via the following survey, which should take about 20 minutes:
https://forms.gle/MdZM3FXN6nsj7Krn8
If this link is not accessible, please contact
federation2-survey(a)lists.refeds.org
<mailto:federation2-survey@lists.refeds.org>.
OR PARTICIPATE IN A FOCUS GROUP DISCUSSION
If you would prefer to share your feedback interactively, we are hosting
live discussions via video conference based on the survey questions, at
the times below. Join us by connecting to
https://internet2.zoom.us/j/8853848902at the times listed below (and at
this calendar)
<https://calendar.google.com/calendar/embed?src=of1k8hh8q6ibkfgt7gh4efa40g%4…>.
UTC
date
Sydney
Tokyo
New Delhi
Kampala
London,
Kinshasa
New York,
Santiago
San Francisco
M 4/29
4:00a T 4/30
3:00a T 4/30
11:30p
9:00p
7:00p
2:00p
11:00a
T 4/30
11:00p
10:00p
6:30p
4:00p
2:00p
9:00a
6:00a
W 5/1
11:00a
10:00a
6:30a
4:00a
2:00a
9:00p T 4/30
6:00p T 4/30
W 5/8
10:00p
9:00p
5:30p
3:00p
1:00p
8:00a
5:00a
W 5/8
1:00a H 5/9
midnight
8:30p
6:00p
4:00p
11:00a
8:00a
M 5/13
9:00a T 5/14
8:00a T 5/14
4:30a T 5/14
2:00a T 5/14
midnight
7:00p
4:00p
T 5/14
1:00a W 5/15
midnight
8:30p
6:00p
4:00p
11:00a
8:00a
Some additional times may be offered in the second half of May: check
the Working Group
<https://wiki.refeds.org/display/GROUPS/Federation+2.0>page for more
details.
AND SHARE WITH OTHERS
We also ask that you forward this request to others you think may have a
perspective on this topic, either as a user, a planner, or an enabler.
We hope to have your responses by Friday, May 10.
Thank you very much!
Tom Barton, University of Chicago and Internet2
Judith Bush, OCLC
Co-chairs, REFEDS Federation 2.0 Working Group
<https://wiki.refeds.org/display/GROUPS/Federation+2.0>
Federated Identity infrastructure:
https://library.educause.edu/resources/2019/1/7-things-you-should-know-abou…
Scenario planning: https://en.wikipedia.org/wiki/Scenario_planning
Working group charter: https://wiki.refeds.org/display/GROUPS/Federation+2.0
Calendar for conversations:
https://calendar.google.com/calendar/embed?src=of1k8hh8q6ibkfgt7gh4efa40g%4…
Direct link to survey:
https://docs.google.com/forms/d/e/1FAIpQLSdDQrff3R3sELqDuZlYSufKhN7FUVv0r_C…
