[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [security-services] Groups - hirsch-sstc-lecp-draft-04.pdf uploaded
>The authentication request and response formats might be slightly different >from the formats defined by Liberty, e.g., original SAML, and similarly the >envelopes might be slightly different. What, however, is the really >distinguishing feature from other authentication and key-exchange protocols? I think the basic idea behind it is that while a LEC/P *could* potentially be an active intermediary in terms of actively going and asking for assertions and then sending them to an SP, it doesn't have to. The idea that I always read into it was to let it fit into the more passive browser-oriented framework that most of this stuff uses, but take advantage of the IdP provisioning and some optimized message exchanges. Sort of a middleground. >(2) Lines 107-113: What about SOAP 1.2 support ? I think I asked this generally. Is it done? Being used? Do we hand wave or get serious and fully specify against it? Is that something we have time for? >(5) Line 151: Is this limited to X509 Tokens only ? This is a general issue that applies across most of the SAML work. I think ID-FF tries to have the usual sort of "hand wavy" language that in theory anything accepted by the providers is acceptable but we all know the reality... >(6) Line 155: I can't find the SOAP Binding for Liberty document. I assume >that we would just use the WSS: SAML Token Profile and not have another SAML >SOAP binding, this can then solve the issues in #5 allowing different token >types Basically what that reference is talking about is the equivalent to the SAML SOAP binding, which is about how to package SAML protocol messages in SOAP/HTTP. It's in ID-FF Bindings and Profiles, and it's an attempt to copy the SAML binding with some additional latitude. It is *not* at all related to the SAML Token Profile. This is the old SOAP binding vs. SOAP profile mess. The token profile says how to secure SOAP messages with SAML assertions. The binding says how to send SAML messages in SOAP. Orthogonal beasts. >(9) Line 193: Issue here is that WS-Security should be used here to protect >the message, this goes back to the issue around the use of a single SAML SOAP >binding as defined in WSS-TC WSS does not define a SAML binding (in the SAML sense of that word) in any way shape or form. Totally different concepts. I believe WSS should be an option (but not a requirement) for authenticating SAML protocol messages. And for many of us, TLS or straight XML signatures over the SAML object remain common and simple options. New options shouldn't preclude or replace the existing ones. >(10)Line 231: Is this saying that the SP vouches for the entities in the >list, why aren't these attributes ? It's advisory since ultimately the the SP will get the assertion and would reject it if untrusted. This just prevents a pointless rejection. They aren't attributes because there's no assertion needed. -- Scott
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]