On Fri, Mar 14, 2008 at 9:57 AM, Scott Cantor <> wrote:
> > So
> > you have to read between the lines to implement an IdP-first profile,
> > for example.
>
> And how would you do it for standard SSO? I think it's the same answer.
> Initiating IdP-first was never included, so the presumption is that you
> "spoof" an SP.
Well, if that's the case, then the profile should remove the sentence
"If initiated by the identity
provider, start with Section 2.4.5." I don't think it's possible to
start the flow at that section without reading between the lines.
> > Yes, and in fact, I've already profiled a SOAP-based use case that
> > produces an equivalent assertion, but that's why this one is an
> > appealing alternative, since it doesn't require SOAP.
>
> Then I would suggest that what you're after is an HTTP binding where the
> user agent is the SAML requester. Which was debated ad nauseum and rejected
> on the basis that HTTP authentication blows and SOAP already covers the use
> case well enough.
Are you invoking some past unpublished consensus on this issue? If
this was discussed previously, I can only conclude that no resolution
was reached since there is no holder-of-key subject confirmation in
[SAML2Prof].
> But that is not this profile, IMHO. It's the same distinction between ECP
> and a SOAP-based SSOS. The requester is the SP in the former and the client
> in the latter.
Yes, you're right about that. The two cases have different
requirements, but there's a lot of overlap, so my earlier comments
were asking if this overlap can be reasonably exploited, that's all.
I'm sorry, but I feel like you're trying to squelch the discussion
instead of allowing it to take place.
> > I will (again) but I'd rather leverage the authentication request
> > handlers that are already present (or will be present) at the IdP.
>
> But you're not...you're asking for the profile to turn into a different
> profile so that the profile you want will get implemented instead. ;-)
I don't think it's either-or but maybe I'm being naive.
> I think there are different profiles required for this use case and the one
> you're after isn't suited for a browser.
TLS client authentication isn't suited for a browser either, but that
shouldn't stop anybody from profiling it if it's found useful in
isolated instances.
Tom
