RE: [security-services] Some tech overview comments

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

> While I agree there are solution opportunities available in
> other architectures, this section follows, and references
> the opening section, which introduces some simple SSO
> concepts (relatively speaking, from the client perspective).

Right, which is why I agree with focusing on web SSO in the TO, not ECP.
What I was disputing was your description of ECP and how it applies to new
use cases, which is not the tech overview's focus at the moment.

> Further, we're really bound to talk only of ECP. So can we
> be in the business of referencing LUADs and Advanced Client,
> et al, e.g.?

No, again, I said as much.

> Also, when you say,
> 
> > The browser profile is the one to avoid, especially when
> > designing new work.
> 
> you are speaking of "new work", addressing de novo, in-the-whole,
> architectures, right? That, essentially, all the browser work
> is really already done?

I'm saying that browser SSO kind of sucks. It's designed around a client
that doesn't have things we'd like it to have, lots of limitations. We just
live with it because we have to. You wouldn't start a new project with SAML
by saying "hey, let's copy a profile built around a bunch of hacks that
provides security equivalent to a cookie". That's silly (I hope).

> That doesn't seem the right approach to a TO. And, aren't these
> de novo situations also, then, initially, fairly limited,
> specialized deployments?

Is web services in that category?

> And finally,
> 
> "It is for clients that have intelligence."
> 
> Were, and why, did those clients gain that intelligence?

Because nobody thinks copying a browser's limitations is a sensible thing to
do if you control the client and/or are starting from scratch.

> Moreover, if for now your challenge only _needed_ browser-like SSO, why
> would you overbuild ... taking all those extra technology
> beauty-contest risks (not to speak of implementation and
> deployment risks)?

None of those risks apply if you control the client. You can make it look
entirely like a browser, but fix the internals that cause all the problems.
Most especially, you can provision it to skip discovery, which I will again
argue is the single biggest factor inhibiting wide use of federated SSO
today. Others may disagree, but that's my on the ground experience, mainly
because I deal with groups that have already rationally concluded the
lawyers need to kept in a locked room under guard.

> I don't understand this. The TO is serving many goals. One is
> simply for designers who want to understand how the browser SSO
> works. Perhaps in deciding whether to use SAML V2.0 at all.

Sure, and I think that area of focus should be on what has seen significant
deployment.

> ECP is an important case of that. And this point in the document
> seems appropriate to me, if we can ground it in the "why would
> you do this?" (IOW, what problem was this design intended to
> address in the first place ... before there was a client so-
> enhanced.)

I think that's fine in *addition* to the basic flow, but it's not a good
substitute for it, which I think was Brian's point.

> And in puzzling that out the WAP proxy case ... well, I support
> that mostly because a) it is simple-ish, and b) it ties to Profiles.
> But any other example would equally suffice.

Well, FWIW, I don't think the word WAP should appear in the TO.

> It dawns on me, however, that as far as I know among the explicit
> TO goals we do not find "solution architecture guidance", or only
> weakly.

No, we don't. Which again is my point in agreeing that ECP isn't a great fit
for this document except in an isolated spot, and not as an all-purpose SAML
example. This is definitely not the SAML implementation guidelines doc, or a
"building SAML architectures" doc.

> So, I'm wary of speaking in a way that appears to give
> that guidance, or appears to deprecate a profile/other aspect of
> the SAML V2.0 tool.

I'm not saying it should. I was disputing your claim that people are
mistakenly building on ECP rather than browser SSO for new use cases. I'm
saying they probably *should* be. I think browser SSO is for browsers and
not much else.

-- Scott