>If they aren't happy with that definition, they shouldn't accept member@x and should come to you looking for something more specific.
Now that's what I'm talking about! That would really help. Doesn't help with the retired employee over 60 though! Not a member. I got excited then, I thought I had something to tell people.

Are Service Providers either on this list or represented? Without sounding too generic, do they even understand the issues faced by an IdP in the UK Federation?

The hardest thing about this is explaining to a non-technical person why they can't simply create and stick each category of user in a permission set like they used to. (unless they spend more money and continue to use Athens directly or via the gateway). It used to be easy. That's not my view, I can see the benefits!

What I don't understand is why no one at any level has raised this before with only 29 days left, when those who haven't paid for Athens will HAVE to be using it and will probably be violating license agreements due to misunderstandings in the underlying technology.

I guess I'm just looking for answers for our customers who are asking me questions which I can't answer fully, many of whom aren't on these lists, although I do encourage them to join in the fun!

In five years time I'll look back at this and laugh wondering what all the fuss was about.....

Matt


>>> Ian Young <[log in to unmask]> 01/07/2008 19:05 >>>
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>.ac.uk, 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>.ac.uk.

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 
statement.

> 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