RE: [security-services] Some tech overview comments

["Nick Ragouzis" <nickr@enosis.com>]

Well, I don't see what you're suggesting we do --within the scope--
a SAML V2.0 TO should properly claim. 

A couple of points:

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

And the SAMLv2.0 Profiles? It was in there last time I looked, but
going by memory for now. Perhaps that historical path should not
be overlooked in helping folks understand this mechanism?

And it seems we're kind of in agreement about *existing* work,
which is, isn't it, the kind of work that many, many, folks just 
coming to SAML V2.0 will be dealing with?

While you rightly point out that given a lot of design latitude
you might do something entirely different, I've seen folks think
of ECP as a panacea, and get mired. I'm talking, e.g., about
designers ALREADY in command of a fully-capable embedded user
agent, in deployment, thinking they "want" or "need" to add SOAP, 
etc. in order to deliver basic SAMLv2.0 capabilities. Something
is wrong with that. And I suspect the TO has contributed somewhat
to that.

There's one edit that I made before sending my first suggestion,
which at this point I guess I'd reverse:

In:
 > a client deployment context requires assistance 
 > through proxy service, or requires enhancement.

s/requires enhancement/requires or offers enhancement/

I fully favor even basic ECP when actual client enhancements are
actually on offer. I would love to see a fuller explanation of
how that works, or could work. But that, it seems to me, strays
into these other design advice areas, and threatens to create
an imbalance in what should be, basically, a simple elaboration
of how to understand the specification.

In that vein I restrained myself, for example, in that second
bullet, from elaborating on the ways in which discovery can be 
enhanced, or the ways in which the principal could be assisted
with enhanced services, even such as UIs. This is just a bit
beyond a neutral TO, and also somewhat outside of SAMLv2.0's
scope (even with shades of the dashed-line controversy, for
a third/fourth time).

--Nick


> -----Original Message-----
> From: Scott Cantor [mailto:cantor.2@osu.edu] 
> Sent: Thursday, February 14, 2008 09:48 AM
> To: 'Nick Ragouzis'; 'Brian Campbell'; 'Paul Madsen'
> Cc: security-services@lists.oasis-open.org
> Subject: RE: [security-services] Some tech overview comments
> 
> 
> > 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
> 
> 
>