RE: [ws-sx] Issue 31: Token properties

["Levinson, Richard" <Richard.Levinson@ca.com>]

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