Re: [security-services] comments: sstc-saml-holder-of-key-browser-sso-draft-01

["Tom Scavo" <trscavo@gmail.com>]

On Fri, Mar 14, 2008 at 9:57 AM, Scott Cantor <cantor.2@osu.edu> 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