Jon Warbrick wrote:

> The problem that I'm seeing is that some suppliers appear to be enabling 
> Shib access (at least for their current customers) based on ePSA of 
> member@<inst>, and perhaps release of an ePTID, despite the fact 
> that the 'authorised users' clauses in the relevant contracts may not 
> match either the UK federation definition of member@... or that of the 
> institution.
> For example I believe that one service, currently restricted to staff, 
> will shortly grant access via Shib based on member@<inst>

The way I'd want to look at this (wishful thinking, perhaps) is that in 
this situation, you're authenticating and making an attribute statement; 
the service provider is the one authorising access on the basis of your 

> This obviously worries the people who sign the contracts - if 
> unauthorised access comes to light as a result, who will be held 
> responsible?

If the service provider has read the (admittedly vague) eduPerson and UK 
TRP definitions of member@x and chooses to regard your assertion of 
member@x as sufficient for them to authorise access to their resource, 
I'm frankly a little bewildered that your contracts people would think 
that would be your responsibility.

Accepting member@x as adequate information for authorisation seems to me 
to be an implicit acceptance by that SP that the definition of member@x 
is close enough to what they want.  If they aren't happy with that 
definition, they shouldn't accept member@x and should come to you 
looking for something more specific.  They haven't done so in your case, 
as I understand it.

> There is also a danger that it will influences the 
> allocation of member@... ePSA values, perhaps only to that subset of 
> people who fall within the 'authorised users' clauses of _all_ an 
> institution's electronic resources. This is clearly wrong and overly 
> restrictive, and will really come home to haunt us if/when Shib access 
> takes off further - perhaps into the e-science arena.

Yes, this would clearly be wrong.  Let's not do that.

	-- Ian