OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

saml-dev message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: Re: [saml-dev] Re: Metadata, IdP Disco, AuthnRequest, etc...

Hello --

On 11 May 2007, at 16:56, Scott Cantor wrote:

>> The service will redirect back to the SP, which will allow the SP to
>> redirect to other IdP disco services, but what does the user
>> interface look like for that?
> Up to the SP. I haven't decided what the Shibboleth SP will do yet,  
> and we
> were the ones who proposed this thing, so to the extent that I may  
> be the
> only one who's even thought much about it, there's not much of an  
> answer. I
> was very up front with people that I did *not* think the DS  
> proposal allowed
> for multiple federation SPs. I was very clear on that.

Agreed, and I think multi-federation SPs will be common enough that  
the limitations of the current IdP disco will be felt.  Maybe I'm  
wrong there -- what has your experience been?

>> Will the first IdP disco service have a "none of these, sorry!"  
>> button?
>> Will the user be presented with potentially three or four different
> "choose
>> one of these completely irrelevant choices" pages before getting  
>> to one
> that
>> has the correct choice?
> I've been clear from day one (well, ok, maybe day 400 or so ;-)  
> that AFAIC,
> the SP MUST handle discovery and that seamless SSO even on first  
> contact
> could not and would never work without client code.
> People want to push back on that, and the DS proposal is part of  
> that, but I
> don't think it helps that much.

I agree that for best general experience, the SP should handle IdP  
selection, but in the absence of a workable "global cookie" solution,  
I'm not sure how annoying that would be (ie, to select your IdP at  
each SP you visit, though I suppose an initial passive probe would  
solve that problem for sites after the first one; you run the risk of  
having to do umpteen bazillion redirects, though).

The best thing would be to use some bit of browser (or other client,  
in the non-web world) plugin to determine, and fall back to SP- 
implemented asking, but that would be... difficult at the least to  
get people to buy in on, unless the browser (and other client)  
producers also buy in.

> But to answer you, I considered the multiple DS case more of an  
> option with
> the isPassive flag, because you wouldn't have the UI to worry  
> about. That
> doesn't get the cookie set in the first place, though, so I guess  
> the vague
> notion was that a passive probe might get you something, and if  
> not, you
> could have the SP offer a first choice of branded options to select  
> from to
> get to the right DS. That's a very questionable and unproven idea.

Getting people to remember what an Onyen (or NetID, or whatever an  
institution calls it) is is hard enough.  Making them remember that  
if they're at site X to choose federation Y, but at Z choose W is not  
really feasible.  I think, anyway.


Karsten Huneycutt
Systems Specialist, ITS Identity Management

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]