Subject Re: affiliate student?
From Nicole Harris <n.harris@xxxxxxxxxx>
Date Wed, 7 Jul 2010 13:23:00 +0100

One of the main problems with the whole process is just lack of clarity across the board, particularly within the licences, so I am looking at starting at the other end and working our institutions through their processes from registration to provisioning to attribute release and then telling them what it is and isn't possible to therefore have in a licence. Most of our licences are horribly vague saying things like 'authorised user is x, y, student (including but not limited to undergraduate and postgraduate)' - so does that mean that a student studying that is not deemed UG or PG can, or cannot have access? We don't have an attribute that says 'and other stuff' :-) At the moment my thinking is along the lines of firstly pushing these institutions to clearly define what they mean by a registered student - there seem to currently be three options: only students that attract funding / are reported to HESA, absolutely everyone studying at the institution, or something in between. The people with 'something in between' have quite some internal defining to do. Then I'm asking them to look at provisioning as it turns out for many that no matter what definition of 'studentyness' you give them, all users get automatically provisioned with member@xxxxxxxxx anyway. This means that everyone is getting access no matter what, so it really isn't worth arguing about group definitions unless you want to change this process. Once you have all of this properly sorted out, you are then effectively declaring your user groups and it is up to the publisher whether or not they allow access for those groups. However there is a feeling amongst some of the institutions that I have been dragging through this process that in order to effectively declare user groups, they need some sort of affiliate-student value in ScopedAffiliation. I don't think we can look at that properly until I have the registration / provisioning sorted out for enough institutions. The main thing I am trying to stop is that many institutions are going to publishers and saying 'do we have to pay more for these groups of users' and surprise surprise, the answer is nearly always yes. What is frustrating is that these groups nearly always have access anyway due to blanket policies of assigning 'member' at attribute provisioning and / or lazy approaches to parsing values by the publisher. Hope that helps expand the problem space a bit more and I will keep you up to date on progress as I kick a few more institutions through good IDM processes :-)


Brian Gilmore wrote:
One question to ask is whether or not most of the licenses would actually
allow access in the case that Bob proposes?
I suspect not, and is that not why we are having this difficulty?

I think this is what Nicole was meaning but we need to tease out exactly
what the licenses allow and then work out the consequences for our access