Nigel,
> -----Original Message-----
> From: Discussion list for Shibboleth developments
> [mailto:[log in to unmask]] On Behalf Of Nigel Bruce
> Sent: 31 October 2005 12:30
> To: [log in to unmask]
> Subject: Re: Athens DA / Shibboleth gateway and classic Athens
>
> Hi Nicole
>
> I think there more to gateway compliance than just the issue of whether
> you get access? I understand from Eduserv that there are still issues
> with how many of the seemingly gateway-compliant sites handle persistent
> identifiers. The current position is that Eduserv now send an Athens
> username that is always the same for a user from session to session
> because DSP are not yet geared up to do it the way they want. Eduserv
> plan to switch over to sending random Athens usernames in about 12
> months. Even when the Athens username is random it will be temporarily
> recorded and tied to the persistent ID on Eduserv's servers. So in
> theory the DSP can, if they choose, query Eduserv's database to find out
> the persistent ID of the user. This would enable them to maintain the
> user's preferences between sessions once the Athens username has been
> randomised. I understand from Eduserv that getting them to do this is
> not proving easy. When I asked Eduserv what would happen if a DSP hadn't
> changed to working the way Eduserv wanted them to in 12 months I was
> told that they would just be flagged as non-gateway compliant.
This is true, and has in fact been part of the Athens implementation
standards, pre-dating the gateway. As we are all experiencing, there is a
long (very long in some cases) lead-time in getting changes put in place by
service providers, so it is all the same issue really.
> At the moment when I go to some sites I get a message such as "Hello
> _ayq5dqg6g3dzajrjqpm". This is not particularly user friendly. I think
> Eduserv would like to send out the EduPersonPrincipleName value and let
> the DSP use that. Eduserv see releasing this to service providers as a
> privacy/data protection issue but if we've configured our IdPs to
> release this information and the user hasn't overridden the default ARP,
> I can't see why it wrong to send this to the Service Provider.
This is clearly a usability issue. Yes, it could be addressed via a change to
a site's ARP, but in most cases could be changed to something like 'Hello,
University of Leeds user' or something along those lines. This would not
generally require a change to either a default or user ARP and this will be
available to an SP via their customer database.
> There is also the issue of how the changeover is handled. If the
> persistent identifier that is used is suddenly changed this will
> presumably have an impact on all the users who have registered to use
> sites so that their preferences (search histories, etc ) can be
> remembered.
Absolutely. Eduserv provide documentation on how a DSP can implement an
interface to enable the user to migrate preferences from one account to
another, but most have been very reticent to take this up.
On the other hand, one of the developments we're working on at the moment is
to enable a user to explicitly link two sets of credentials together into a
single virtual identity which will persist between sessions. This may go some
way to addressing migration issues (although this is only one use-case) as it
will put the user more in control. It will not provide a universal solution
though.
David
|