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:]
Sent: Thursday, April 06, 2006 8:50
AM
To: Tony Gullotta
Cc:
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
'
src="gif00058.gif" width=16>"Tony Gullotta"
<>
"Tony Gullotta"
<>
04/06/2006 12:05 AM
To
<>
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
