[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [security-services] Some tech overview comments
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]