Re: [security-services] Some tech overview comments

[Paul Madsen <paulmadsen@rogers.com>]

Hi Brian, thanks for comments.

inline below

paul

Brian Campbell wrote:
> I can't recall the last time I looked at this document but I wanted to look
> it over before the CD vote tomorrow.  These two things jumped out at me
> during a quick read of the doc.
>
> 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).

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


>
>
>
> ---------------------------------------------------------------------
> To unsubscribe from this mail list, you must leave the OASIS TC that
> generates this mail.  You may a link to this group and all your TCs in OASIS
> at:
> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php 
>
>
>
>   

-- 
Paul Madsen             e:paulmadsen @ ntt-at.com
NTT                     p:613-482-0432
                        m:613-282-8647
                        aim:PaulMdsn5
                        web:connectid.blogspot.com