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

[Anthony Nadalin <drsecure@us.ibm.com>]

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