OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

ws-sx-comment message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: WS-SP 1.2 questions regarding precedence for conflicting policy, other misc

Attempting to re-post via mailing list after web form post didn't seem to 
make it...

Name: Gary McAfee
Title: Software Engineer
Organization: IBM
Regarding Specification: WS-SecurityPolicy 1.2

It isn't clear to me from the specification what has precedence in several 
situations were there appears to be conflicting policy, or whether the 
policy should be rejected.  I think there are several broad 

1. Whether tokens should be included in a message when their token 
inclusion value appears to conflict with other sections of the 
specification which indicate whether a token should be present in the 
message.  For example, a token inclusion value could indicate a token MUST 
NOT be included in the message, but if the token is represented by a 
SignedSupportingToken or a SignedEndorsingSupportingToken in a Transport 
binding, the specification seems to indicate at least in the example in 
Appendix C, that the tokens need to be included, and no mention is made of 
the token's token inclusion value.

2. Whether Timestamps should be included when there appears to be a 
conflict between the [Timestamp] property and the apparent requirements of 
the supporting token assertions or the Transport binding.  For example, if 
the [Timestamp] property were false and an EndorsingSupportingToken or a 
SignedEndorsingSupportingToken assertion was included in an endpoint 
policy including a Transport binding.  The section on Supporting Tokens 
says the supporting tokens 'should' sign the Timestamp element.  It's not 
clear if the Timestamp element should be added to satisfy the supporting 
token assertion (I suspect not since the [Timestamp] property says a 
Timestamp MUST NOT be present if the value is set to false).  If a 
Timestamp is not present in a message using a Transport binding, then this 
introduces a one-to-many mapping between the message and the various types 
of supporting token assertions.  For example, in a message using a 
Transport binding without a Timestamp element, the message would look the 
same whether the endpoint policy contained a SupportingTokens, 
SignedSupportingTokens, or SignedEndorsingSupportingToken assertion.

3. The very beginning of the "Supporting Tokens" section (first paragraph, 
second sentence) says "The Security Binding will require one to create a 
signature using the token identified in the Security Binding policy". It's 
not clear whether a policy that contains nothing specifically that will 
generate a message signature is still valid.    I'm restricting this 
discussion to Symmetric and Asymmetric bindings since Transport bindings 
have their elements implicitly signed.  For example, if the security 
binding specified not to have a timestamp, and there was no message policy 
(and therefore no SignedParts or SignedElements), and no 
SignedSupportingToken or SignedEndorsingSupportingToken assertions, it 
appears we could have a message without a message signature.  Furthermore, 
this kind of situation makes it much more difficult to map an incoming 
message to a policy since deriving the binding used to generate such a 
message from the message itself is difficult or results in a one-to-many 
mapping between the message and various policies that could map to such an 
ambiguously constructed message.

4. The examples in the appendix for the Symmetric and Asymmetric cases 
show the UsernameToken as being signed and encrypted, yet the example 
policy that goes along with them shows nothing that would cause the 
UsernameToken to be signed and encrypted.  Could the reason for this be 

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]