Subject RE: affiliate student?
From Andrew Cormack <Andrew.Cormack@xxxxxx>
Date Wed, 7 Jul 2010 07:20:24 +0000

How about the following as a strawman (to be kicked, burnt, etc.)?

IdP enumerated (e.g. ePE)
SP enumerated (e.g. ePPN)

I'm consciously trying to make it as simple as possible, so may have overdone it. This is very much looking at the publisher use-case, and taking inspiration from licensing of content in dead-tree form (i.e. if you are physically here then you can see it). 

So, actually, "library-walk-in" is the sense of the original basic authenticator
But now we do distance/home/etc. learning so (as UK copyright law has just recognised) we'll allow access to "members" who are "on-site" at the e-library ;-)
And there's an increasing trend to give logins to people who aren't "members", so use "affiliate" to carve those out and allow publishers to exclude them from licences if they want.
My appeal at TNC for use cases that required differentiation between "student" and the various flavours of "faculty/staff/employee" hasn't revealed any, so I'm dropping those for now.

My "IdP-" and "SP-"enumerated covers a range of options (including by-subject, by-course, by-site, by-role, etc.) whose common feature is that I suspect they'll need to be negotiated individually between the SP and IdP. Clearly that's a cost on both of them, so I'd hope that they don't want to do it unless it's really necessary :-) I'm definitely not proposing that ePE be used for all of them, though it could obviously be useful for some.

I'm aware that some of the past JISC work has looked at licences restricted to non-commercial use, but I don't think that's expressible by an attribute of the user, so I've not included it here.

I'm also punting the question of "what is a member?" which seems to have been the topic of endless discussions. But, again starting from the IP-authZ perspective, a significant number of resources are clearly prepared to accept quite a lot of wiggle-room, and I'd rather not tie up the whole progress of federations till we've sorted out every mote of dust for the few who do. Inspired by a load of talks on clouds, I'm trying to give a commercial incentive to simple licences: if you want something non-standard then you can pay/work extra for it.

And I do like Nicole's model of splitting provisioning from authorisation. It took our schools people to work out that exchanging someone's complete list of classes every time they logged in wasn't terribly efficient. So that makes the authorisation attributes a whole lot simpler :-)


Andrew Cormack, Chief Regulatory Adviser
JANET(UK), Lumen House, Library Avenue, Harwell Science and Innovation Campus, Didcot, OX11 0SG, UK
Phone: +44 (0) 1235 822302
Fax: +44 (0) 1235 822399

JANET, the UK's education and research network

JANET(UK) is a trading name of The JNT Association, a company limited
by guarantee which is registered in England under No. 2881024 
and whose Registered Office is at Lumen House, Library Avenue,
Harwell Science and Innovation Campus, Didcot, Oxfordshire. OX11 0SG

> -----Original Message-----
> From: David L. Wasley [mailto:dlwasley@xxxxxxxxxxxxx]
> Sent: 06 July 2010 17:25
> To: 'refeds@xxxxxxxxxx'
> Subject: RE: [refeds] affiliate student?
> Yes -- there is danger in allowing for infinite flexibility, for many
> reasons.
> Clearly publishers and their customers should seek as few
> "variations" as possible.  While "one size fits all" may be too
> limiting, fewer than, say, 8 might be quite workable.
> What are the factors that actually make sense, and how might that
> list be developed?  Etc...
> 	David
> -----
> At 3:58 PM +0000 on 7/6/10, Andrew Cormack wrote:
> >  > -----Original Message-----
> >>  From: Thomas Lenggenhager [mailto:lenggenhager@xxxxxxxxx]
> >>  Sent: 06 July 2010 16:40
> >>  To: 'refeds@xxxxxxxxxx'
> >>  Subject: Re: [refeds] affiliate student?
> >>
> >>  The Shibboleth IdP includes a powerful scripting capability for
> >>  attribute mappings e.g. useable for entitlements.
> >>
> >>  For many purposes there is no need to tweak the IdM system, which
> is
> >>  often more complicated to achieve.
> >
> >Agreed, *if* the source information for the attribute mapping is
> >present in the IdM system. But as I understand it some of the
> >licences that Nicole is talking about make distinctions that aren't
> >currently in universities' IdM systems at all :-(
> >
> >Andrew
> >
> >>  Thomas
> >>
> >>  On 06.07.10 15:25, Andrew Cormack wrote:
> >>  > Sounds like there will be good sales for entitlement-management
> >>  plugins for IdM systems, then :-(
> >>  >
> >>  > Andrew (student@xxxxxxxxxx or if coming via EZproxy)
> >>
> >>  --
> >>  SWITCH
> >>  Serving Swiss Universities
> >>  --------------------------
> >>  Thomas Lenggenhager
> >>  P.O. Box, 8021 Zurich, Switzerland
> >>  phone +41 44 268 1505  direct +41 44 268 1541
> >>