[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [security-services] Some tech overview comments
Scott, 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). 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.? 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? That doesn't seem the right approach to a TO. And, aren't these de novo situations also, then, initially, fairly limited, specialized deployments? And finally, "It is for clients that have intelligence." Were, and why, did those clients gain that intelligence? 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)? > I think there's a place to talk about ECP but not as a basic > example of what's currently in the spec and in wide use. 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. 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.) 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. ... 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. 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. --Nick > -----Original Message----- > From: Scott Cantor [mailto:cantor.2@osu.edu] > Sent: Thursday, February 14, 2008 07:33 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 think ECP is actually quite clever, is it not, actually, > > more often, in pre-existing devices/architectures, used like a > > prosthetic/remediation profile? And wouldn't -most- new clients > > be wise to study closely, and give initial favor to, the other > > profiles? Which gets to Brian's questions in: > > Well, no. The browser profile is the one to avoid, especially > when designing new work. ECP, and its Liberty variants and profiles > of plain SOAP SSO are the ones to use for most use cases. They > address discovery and support all applications that can handle > SAML assertions as an attachment. > > If anything we undersell ECP, but that's mainly because you > need ID-WSF to maximize its usefulness. > > > 5.2 ECP Profile > > The browser SSO profile discussed above works with popular web > > browsers, fully-featured web libraries and tool kits, and many > > embedded implementations. This section, in contrast, describes > > a SAML V2.0 profile which fits when, to participate in SAML V2.0 > > use cases, a client deployment context requires assistance > > through proxy service, or requires enhancement. > > But this is simply wrong. It is for clients that have > intelligence. The proxy/WAP angle is the one I find silly. > I'm sure that matters to a particular niche, but it's not > appropriate for an overview. > > None of this is to disagree with Brian's points...I think > there's a place to talk about ECP but not as a basic example > of what's currently in the spec and in wide use. > > -- Scott > > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]