RE: [security-services] Some tech overview comments

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

I've noted Paul's good suggestions about TOv2d14, Sect5.2.1.
In thinking about Brian's comments a bit, I am wondering: 
is balance or perspective in portrayal the problem at hand? 
Even: should we be a bit "less balanced"?

Yes, it seems to me difficult or even unwise to "promote" one 
approach over another in such a document, this can result in 
confusion and unintended consequences. 

But we're a bit on now, in terms of work and deployment, from 
where this was written, and I have a definite feeling that ECP 
comes across too strong. In my narrow experience I have 
repeatedly walked into situations where the ECP diagram is the 
central illustration, and the architecture is in walkthrough: 
the domain doesn't seem to matter -- financial, science, and 
medical. Repeatedly, the task is to find out why they think 
ECP is/was the answer ... and after going back to fundamentals, 
and exploring future difficulties and possible lost opportunities 
for integration, it usually isn't. (I hasten to add, tho, that
ECP has offered an expedient solution to platform challenges,
and even political forces.) Has anyone else seen this? 

So, apart from Paul's note about portraying ECP in terms of 
inabilities, it might be that ECP is overplayed. Possibly by 
just being a _bit_ complicated (therefore attractive to certain
teams). But also by having many aspects that make the ECP Profile 
seem, well, special, even ... enhanced. Leading designers to 
think: "... and why shouldn't we use something that's enhanced, 
and that offers us the most enhancement, after all; even future
flexibility? Let's design our client to use that enhancement
stuff. (Besides, then we get to control everything, and anyway
I don't understand that discovery stuff.)" 

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:

>> That leaves me thinking, would a client that can't do 
>> redirects really be able to do SOAP, PAOS, and some SAML?  
>> And when the IdP and SP can't communicate directly, why not 
>> just use POST?  

Rather than argue that in the document, perhaps something along 
the following lines gets to Brian's initial comments (and 
incorporates your follow-on comments, Brian), about the expected 
design factors in clients, while falling between the existing 
text, and your modifications, Paul.

I propose:

-- -- --

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.

5.2.1 Introduction
The Enhanced Client and Proxy (ECP) Profile enables several
SSO use cases, in particular:

 * Use of a device with limited functionality (such as a non-HTTP-
   based device), which relies on a proxy server's communication
   with the IDP, such as a mobile device relying on a WAP gateway 
   to provide HTTP proxy services.

 * Use of a client that is enhanced to participate as an active 
   party in SAML V2.0 message exchange, allowing such an enhanced 
   client: to assist the requesting SP in IDP discovery for the
   associated principal, to maintain orderly message flow in the 
   presence of disconnected services, and to otherwise provide 
   ancillary services in service of the SAML V2.0 message exchange
   (including, e.g., communications with the principal, or 
   automation on the principal's behalf).

 * Use of clients otherwise incapable of participating in the
   preceding browser SSO profile and its bindings, including such
   limitations as where the client does not support redirects, or 
   where the artifact binding is ruled out because the IDP and SP 
   cannot directly communicate, or where factors such as client 
   scripting limitations inhibit automatic forms posting. If
   these limitations cannot be overcome, one candidate solution
   might be to enhance the client with ECP capabilities.

-- -- --

Best,
--Nick 

  Nick Ragouzis
  Enosis Group LLC
  +1 415 738 0673 VoIP
  +1 415 260 5227 Mobile

> -----Original Message-----
> From: Brian Campbell [mailto:bcampbell@pingidentity.com] 
> Sent: Wednesday, February 13, 2008 06:35 AM
> To: Paul Madsen
> Cc: security-services@lists.oasis-open.org
> Subject: Re: [security-services] Some tech overview comments
> 
> 
...
> >> There are some things in 5.2.1 "[ECP] Introduction" that I 
> >> find confusing - it says that the "(ECP) Profile supports 
> >> several SSO use cases... Clients where it is impossible to
> >> use redirects ... It is impossible for the identity provider 
> >> and service provider to directly communicate (and hence
> >> the HTTP Artifact binding cannot be used)"  That leaves me 
> >> thinking, would a client that can't do redirects really be 
> >> able to do SOAP, PAOS, and some SAML?  And when the IdP and SP 
> >> can't communicate directly, why not just use POST?  
> >>   
> > I agree that it feels strange to portray the relevance of ECP as
> > determined by the client's inabilities, rather than abilities, given
> > that we call the thing 'enhanced'.
> > 
> > I propose modifying the list of use cases to something like
> > 
> >     * Clients with capabilities beyond a browser, allowing 
> >       them to more actively participate in IDP discovery and 
> >       message flow
> > 
> >     * Use of a proxy server, for example a WAP gateway in front of a
> >       mobile device which has limited functionality.
> > 
> >     * When other bindings are precluded (e.g. where the client 
> >       does not support redirects or the artifact binding is ruled 
> >       out because the identity provider and service provider cannot 
> >       directly communicate.
> 
> Definitely better.  Perhaps something about javascript and 
> the auto form post in that last one?
>