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

["Tony Gullotta" <tony.gullotta@soa.com>]

It could be for authentication. For example, in the WS-S Username Token profile it states "Note that wsse:PassworDigest" can only be used if the plain text password (or password equivalent) is available to both the requestor and the recipient." If the web service does not have access to that information it may need to state in a policy that it does not support wsse:PasswordDigest. This is definitely security related, not application specific.

 

There are other examples that are application specific. With SAML, for example, an application may requires some attribute statements. Now, this may not be WS-Security specific, but if these requirements are needed by the web service then it would seem to make sense that it would be included within the SAML token assertion we've already defined. So, if some other group needs to define SAML specific policies, I guess that would be ok, but why shouldn't that group define the whole token assertion then, not just parts of it? It just seems odd to me that we've only gone part way with these tokens. They appear to be incomplete. And if left up to another group they may go a completely different way and the clients are left with redundant information in policies that are hard to tie together.

 

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.

 

Tony

---

From: Anthony Nadalin [mailto:drsecure@us.ibm.com]
Sent: Thursday, April 06, 2006 8:50 AM
To: Tony Gullotta
Cc: ws-sx@lists.oasis-open.org
Subject: Re: [ws-sx] Issue 31: Token properties

So one question is does WS-Security, WS-Trust and WS-SecureConversation actually need to know what is in a token ? or is this an application thing ? what is the requirement that we are trying to satisfy ?

Anthony Nadalin | Work 512.838.0085 | Cell 512.289.4122
"Tony Gullotta" <tony.gullotta@soa.com>

"Tony Gullotta" <tony.gullotta@soa.com>

04/06/2006 12:05 AM

To	<ws-sx@lists.oasis-open.org>
cc
Subject	[ws-sx] Issue 31: Token properties

I took the action at the F2F to stir the pot a little on Issue 31. I believe the issue originally posed the question about missing policy assertions within the Username token assertion for optional elements like creationTime and nonce. I believe this is just one example of all tokens that have configurable options, SAML, X.509, etc.

It has been proposed that what is currently defined in the spec is adequate and that any additional properties/policies should be defined using extensions out of the scope of WS-SecurityPolicy using the proposed solution to issue 30.

I am posing the question of whether or not this TC should address the missing properties/policies for the token types already listed in the spec or in separate profiles? It would seem to me that if we are going through the trouble of identifying what tokens are required for communicating with an endpoint that we should have a complete description of the requirements for those tokens. Without this, either out-of-band information has to be communicated or proprietary extensions have to be used.

If we feel that other committees should define these properties/policies, then I guess I'd have to question why we've gone this far already. Why not just identify the placeholders for the tokens like the InitiatorToken, RecipientToken, and SupportingTokens assertions and let the other committees define the token assertions themselves? Maybe just fully describe SCT's since WS-SecureConversation is being produced by us.

Tony