Subject Re: affiliate student?
From "David L. Wasley" <dlwasley@xxxxxxxxxxxxx>
Date Fri, 9 Jul 2010 10:20:37 -0700

Life was so simple when we lived in small villages, everyone knew each other, and the rules were always flexible (if not always fair). But now we are looking to create clear boundaries, uniformly followed rules, and BTW anonymity. But I digress.

Bob's point about the bar SPs are generally willing to meet might be a motivation for publishers to work with this community to develop a small set of more clear and easier to manage access rules. This could help with Nicole's first task since it would let schools know what relationships actually matter to publishers.

I would guess, for example, that a distinction allowing access to an additional 10,000 users (e.g. an affiliate community college) would be of much greater interest to a publisher than a distinction that encompassed only a few hundred users (e.g. library walk-ins). The goal would be to "tease out" what distinctions are actually meaningful to relying parties (and perhaps to institutions as well).

Having said that, I have a different but related concern: how to best deal with denial of access when the rules become more fine grained. This is the help desk problem. It could be mitigated at the time of denial if some explanation could be offered but which party is better suited to do that: the IdP or the SP/RP?

If 'entitlement' is used then all the SP/RP could say is "You are not entitled." However, the IdP could say "This resource is available only to ____ or _____."

On the other hand, if attributes are given to the SP/RP and it does the algebra, then it would have to provide the explanation to the denied user.

As an institution supporting a community of users, I would prefer to implement the former since it would allow for better treatment of the frustrated user.

Just a thought FWIW.

At 1:23 PM +0100 on 7/7/10, Nicole Harris wrote:

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