Shibboleth Developers

["Rod Widdowson" <>]

On consistency, My feeling from talking to some users (OK, my kids and their 
friends) is that they don't care.  Over here for a
whole bunch of universities the behavior is different between on campus and 
off campus so they have to deal with differences anyway.
It could also be said that there is the confusion "Sometime I have to log in 
after I see the DS, sometimes I don't".

On Chad's point I disagree - if the user leaves the machine in such a way 
that SESSION cookies are preserved you have a much bigger
problem than the users getting pointed to the wrong machine (indeed you could 
think of this as a way of improving the security of
poorly set up kiosks...)...

I suppose I could buy that when we have SLO implemented we then might have to 
add the DS in as well but in the face of these
technical hurdles what's another round trip... (yes, I'm being flippant)..

I could buy that there is room for annoyance "Why doesn't this stupid machine 
let me select my IdP", but my feeling is that people
have a natural level of escalation (restart the browser, restart the machine, 
throw machine out of window) which will clear the
issue.  It has been this persistence of a bad choice which always worried me 
about the "alwaysFollow" capability of the existing
DS..

On the other hand I'd guess that an SP could command this behavior by having 
a chain of initiators, one which asks for isPassive to
the DS and one which doesn't...

On the whole however, I'm not feeling a wave of enthusiasm so far.... 

R

> -----Original Message-----
> From: 
> 
>  
> [mailto:]
>  On Behalf Of
> Chad La Joie
> Sent: 24 January 2011 19:16
> To: 
> 
> Subject: Re: [Shib-Dev] Non persistent cookies and the centralized 
> discovery service
> 
> More than the consistency argument, which I happen to agree with, is the
> problem you run in to when the auto-selected IdP is not the correct one.
>  For example, I have actually seen people in the UMich library log in to
> other IdPs.  Presumably because that person was a visiting student or
> faculty or something.
> 
> If you ever have an automatic, show-nothing redirect the user ends up in
> a bind because there is nothing to suggest that a) there should have
> been a screen that asked them where they wanted to go and b) nothing to
> describe how to clear the current state to get that screen back.
> 
> So that's always been my main issue.  The fact that one user can do
> something to "invisibly" screw up another user.
> 
> On 1/24/11 2:06 PM, Cantor, Scott E. wrote:
> >> My immediate instinct is that would really help the usability of 
> >> centralized DS,
> >> potentially at the cost of SP's which do
> >> (multi-IdP) attribute aggregation (and who I'd assume would need to do 
> >> their
> >> own discovery), but I'd like to get your input...
> >
> > My only comment is that one of the continued debates is over whether 
> > users (meaning nobody who would
> be on this list) actually care about this, or in fact find it even more 
> confusing to end up sent to a
> particular IdP in some cases but prompted in others. The consistency 
> argument is that it's better to
> just be uniform in what you give the user in each case, even at the cost of 
> an extra click.
> >
> > -- Scott
> >
> >
> 
> --
> Chad La Joie
> http://itumi.biz
> trusted identities, delivered