“He’s not the Messiah”: We Still Don’t Know Who our Users Are

There is a scene in Monty Python’s “The Life of Brian” where Brian is on the run from the Romans and ends up meeting the shop keeper from hell who wants him to haggle (for a beard). For some reason, this popped in to my head whilst reading lis-e-resources this week, and a discussion on ‘can our users access this resource’. This is perhaps a bit unfair, and not quite the same, but I was frustrated with the approach that many institutions seemed to be taking to define who their users are and work out who can access what. The standard approach: ask the publisher.

To me, these seems as futile as the shop keeper in Life of Brian who will get less than Brian was willing to pay by forcing him to haggle. If you approach a publisher and say ‘should I pay more for these extra groups of users’ then the answer will almost inevitably be yes! There seem to be lots of parallel conversations going on in different institutions resulting in different approaches creating complex groups of users, and librarians seem to be bearing the brunt of having to sort this problem out. In addition, these discussions seem to be happening with absolutely no reference to technologies being used and what they can actually deliver at the end of the day. The depressing final conclusion is one I often hear in association with walk-in access: “we aren’t sure, so we don’t offer access to anyone.” How depressing.

I think this needs changing in two ways:

  1. Institutions should be able to tell publishers who they define as member, and not seek permission to extend access rights to groups of users who are clearly registered with an institution.
  2. If more complex groups are created, libraries need to ensure that access management implementations are able to deliver access to these disparate groups of users.

To meeting objective 1, every institution in the UK needs to have a clear approach to identity management. The good news is that a lot of work has been done on this already – the JISC Identity Management Toolkit is a great place to start, particularly the examples given by Cardiff University who have already tackled a huge project in this area.

The key pain-points to look at seem to be:

  1. How does you institution define ‘member’? Which groups are included in this definition? Which are excluded? Does this match the expectations of licenses and access management technologies?
  2. For a student to be a member, must they attract funding to your institution (either personal or government), or merely be registered with your institution?
  3. Do you register students at your institution when running a course in conjunction with a partner organisation in the UK? Do you treat these students in the same manner as funded students?
  4. If you distinguish between funded student and registered student, is this being expressed in your access management policies?
  5. How do you manage overseas affiliates, franchises, partners etc.?

If an institution cannot clearly and definitively answer these questions, librarians have no hope of negotiating access successfully so please do go and look at the Identity Management Toolkit and do get on with this work.

The final point is that there is no point negotiating and defining groups endlessly if this is not reflected in the attributes that are assigned to students. Very few institutions are making good use of granular attributes in their access management implementations, and we often get told that for most publishers, all that is required is ‘member’. This is fine, as long as the institution has a policy of also NOT defining ‘member’ for the groups that you have decided are outside this definition.

When asked if x group or y group are members of an institution, I invariably answer ‘yes’ and most librarians roll their eyes at me and assume I am naive and don’t understand the environment we work in. There is a simple reason for my answer – in most cases those groups of students you have spent hours talking to publishers about and negotiating them out of licences probably automatically get assigned the attribute ‘member’ when they are registered with the institution. Why? Because the institutions don’t have a clear answer to point 1 above. So this means they are getting access anyway and your conversations were pointless.

As I often say to a good friend of mine, in the electronic world a licence is just a stream of meaningless words if you don’t ensure that a) what you can agree CAN be implemented by the technology and b) that they ARE implemented by the technology.

Time to look at that granular access issue again? I think so. After all, he’s not the Messiah, he’s a very naughty boy…with a fake beard.

2 thoughts on ““He’s not the Messiah”: We Still Don’t Know Who our Users Are

  1. David Harrison

    OK – I’ve remembered that job I was supposed to be doing – writing up the Cardiff Membership, Categories and Entitlements work, for the Identity Management Toolkit (additional resources) and of course YOU!

  2. Pingback: JISC Access Management Focus · Middleware Coordination, Coperation and Copenhagen

Comments are closed.
https://access.jiscinvolve.org/wp/hes-not-the-messiah-we-still-dont-know-who-our-users-are/
access.jiscinvolve.org
crawl=CC-MAIN-2021-04
45106
application/http; msgtype=response
sha1:JY6NSLSM4IABHQWYPE4IZJRPMQP3JVSU
<urn:uuid:1412b328-fcd8-4661-81e2-83048f4faf20>
2021-01-24T02:32:37Z
34.253.169.74
text/html
sha1:4L2KQBMMLVSY6J4EU6GSBOPBKLHNMA7L
<urn:uuid:18503f01-39b1-4557-93ba-fc0a407cb25c>
https://access.jiscinvolve.org/wp/hes-not-the-messiah-we-still-dont-know-who-our-users-are/
response
<urn:uuid:a46ef1a9-ba22-4c13-b11c-f36abff3c80c>
isPartOf: CC-MAIN-2021-04
publisher: Common Crawl
description: Wide crawl of the web for January 2021
operator: Common Crawl Admin (info@commoncrawl.org)
hostname: ip-10-67-67-35.ec2.internal
software: Apache Nutch 1.17 (modified, https://github.com/commoncrawl/nutch/)
robots: checked via crawler-commons 1.2-SNAPSHOT (https://github.com/crawler-commons/crawler-commons)
format: WARC File Format 1.1
conformsTo: http://iipc.github.io/warc-specifications/specifications/warc-format/warc-1.1/