Re: [security-services] Some tech overview comments

[Brian Campbell <bcampbell@pingidentity.com>]

Responses to responses inline...

>> 
>> The example XML in section 4.4.4 "Message Structure and the SOAP Binding"
>> shows an AuthnRequest and subsequent Response containing an assertion being
>> transported via a SOAP envelope.  While I realize this is valid in the ECP
>> profile I think it is somewhat confusing at this point in this document.
>> The user's agent and the idea of a bearer token are important pieces of SAML
>> and this example seems to suggest that SSO can be accomplished without them.
>>   
> Section 4.4 is entitled 'SAML XML Constructs and Examples' so I think
> the SOAP example is perfectly valid here, as we are not claiming that
> this example is in the context of SSO (or any other context).

It's valid, for sure.  My concern wasn't the validity but only that it might
be a bit misleading/confusing for someone new to SAML (which is kind of the
target audience for this doc, right?).  I believe there is some
misconception that  SSO can be done by just making a SOAP call and I fear
that this example might compound that misconception.  But the real fun of
web SSO (which is the main use case for SAML now) is the involvement of the
user agent. 

Admittedly it is kind of a nit, and if others don't think it's an issue,
I'll drop it.  But I was thinking it may be more appropriate to show an
example of SAML message that is more commonly bound to SOAP - like logout or
artifact resolution.

>> 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?