[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [ws-sx] Issue 31: Token properties
I have been following this discussion since the Feb postings with Werner and Martin and would like to try to contribute my 2 cents. The basic discussion seems to be whether ws-sp should define just the specific profile to be used for a token type, such as WssUsernameToken10, WssUsernameToken11, WssSamlV11Token10, WssSamlV11Token11, WssSamlV20Token11, etc. (as is currently being done), or to add detail in addition to these token profile identifiers as to how to use the profile identified. It seems to me from having participated in the WS-Security 1.0 Saml Token Profile Interop, that the profiles themselves, do not even say how to exchange information as to what flavor of the profile is to be used. In fact, the interop specs in some ways are becoming the default set of "typed message interchanges" that are commonly understood to "work" for the profile. In addition there are WS/I definitions for profile usages as well. Therefore, my gut reaction is that to try to interpret the charter as meaning that we should solve all these specific interchanges for all the WS-Security profiles is taking on a prohibitively large task. Therefore, I am leaning to believe that Martin's statement in an early part of this discussion makes the most sense from my perspective. > [MJG] > The client needs to be able to construct a token that matches the > token profile in use. > > If the token profile allows for variation, then the client can choose > to send any token that matches the profile and the service should > accept it. > The bottom line as I see it is that if we create a ws-sp infrastructure and then implement interops with a set of selected token types as is currently being done by Marc and Prateek, then those interop specs can serve as guidance for additional token types and use cases. Thanks, Rich Levinson -----Original Message----- From: Symon Chang [mailto:schang@bluetitan.com] Sent: Thursday, April 06, 2006 1:36 PM To: Scott Cantor; Tony Gullotta; Anthony Nadalin; ws-sx@lists.oasis-open.org Subject: RE: [ws-sx] Issue 31: Token properties The following is from the charter for our WS-SX TC: "WS-SecurityPolicy [4] uses the facilities of WS-Policy [5] to express the conditions and restrictions on the wire formats defined by OASIS Web Services Security [1], WS-SecureConversation [2] and WS-Trust [3] to a specific set of typed message interchanges." From this statement, there is no reason to define the WSS token properties somewhere else. WS-SecurityPolicy has to define properties of token in the WS-Security spec. For example, Username Token with/without nonce or created tags should be definable in the security policy, so that the Policy Enforcement Point can enforce the policy accordingly. Symon Chang, CISSP Sr. Security Architect Blue Titan Software -----Original Message----- From: Scott Cantor [mailto:cantor.2@osu.edu] Sent: Thursday, April 06, 2006 9:53 AM To: 'Tony Gullotta'; 'Anthony Nadalin' Cc: ws-sx@lists.oasis-open.org Subject: RE: [ws-sx] Issue 31: Token properties > I would think that at a minimum we should look at properties required > to ensure the tokens can be authenticated properly like in my first > example. That applies to SAML as well, i.e. SubjectConfirmation. It's meaningless to just say "SAML token". I would say there should be token profiles of many of these specs, if not here, fine, but somewhere. -- Scott
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]