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

["Scott Cantor" <cantor.2@osu.edu>]

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

My point is we should probably just emulate the original SSO profile
language or change both via errata if something isn't clear. (And I would
not disagree that IdP-initiated SSO is not clear.)

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

The confirmation method is in profiles and the discussion of how to request
any method is in core. The missing bit is a non-SOAP binding for a client to
use, and I was saying that in the past when we raised the idea of a
synchronous HTTP binding, the attitude was "eh". Maybe attitudes about SOAP
in the world have changed that thinking, in which case we can certainly
write such a binding. I'm not arguing against it, just pointing out that
it's been tossed out a couple of times.

> Yes, you're right about that.  The two cases have different
> requirements, but there's a lot of overlap,

The overlap is *extremely* difficult to resolve without ending up with two
separate profiles in form if not name. I've tried, and I don't think it's
worth it. I think it's important and useful to separate the work of profiles
constrained by browsers and those that aren't. I'm *not* arguing against
either type.

> 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'm trying to argue against an attempt to take something designed to emulate
the existing browser SSO profile and turn it into a non-browser profile. I'm
not trying to squelch anything. If somebody is willing to do the work, have
at it but I think it will be very messy and not all that useful to combine
them.

Realize that I'm the all-time champion of layering specs and forcing people
to compose them. I don't say this stuff lightly. When it comes to security,
I think that the actors need to be very clearly defined, and I think that
combining profiles where the actors in the flow switch roles is a big
mistake.

> I don't think it's either-or but maybe I'm being naive.

When you end up with a bunch of processing rules that fork based on the
roles, I think it's pointless to try and merge them.

If one looks at ECP, a case could be made that the ECP version wasn't needed
because an EC is more than a browser. I think that's a sound argument. But
with this particular document, it *is* a browser, so I think the calculus is
very different.

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

Client TLS is perfectly suited for a browser. What's not suitable for humans
is the UI. But this profile sidesteps that issue and presupposed somebody
thinks it's workable, and then proceeds from that baseline.

At no time did I try to stop anybody from profiling it. I'm trying to argue
for sound, distinct, clear profiles for addressing specific scenarios. I
would leave it to implementers to reuse code or endpoints if they think
that's appropriate.

-- Scott