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

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

> Will the first IdP disco service have a "none of these, sorry!" button?
> Will the user be presented with potentially three or four different
> one of these completely irrelevant choices" pages before getting to one
> 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.
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.

-- Scott

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