OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

security-services message

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