NEW Issue: Sample wsdl in conflict w WS-I BSP in WS-Trust 1.3, 1.4

["Rich.Levinson" <rich.levinson@oracle.com>]

PLEASE DO NOT REPLY TO THIS EMAIL OR START A DISCUSSISON THREAD UNTIL THE ISSUE IS ASSIGNED A NUMBER.  
The issues coordinators will notify the list when that has occurred.

Protocol:  ws-trust 

  	ws-trust-1.4-spec-ed-03: p 79, Appendix B, lines 3177,3184,3188; 3204,3208
  	  http://www.oasis-open.org/committees/download.php/28255/ws-trust-1.4-spec-ed-03.doc

    the problem described here also relates to these ws-trust 1.3 documents

  	ws-trust-1.3-os:
  	  http://docs.oasis-open.org/ws-sx/ws-trust/200512/ws-trust-1.3-os.pdf
	wsdl:
	  http://docs.oasis-open.org/ws-sx/ws-trust/200512/ws-trust-1.3.wsdl

Artifact:  
	wsdl

Type:
	editorial

Title:  
	Sample wsdl in conflict w WS-I BSP

Description:
	ws-trust-1.4-spec-ed-03: p 79, Appendix B, lines 3177,3184,3188; 3204,3208

	It was found during preparation of use cases for the 
	  web services test forum (wstf) committee:
		http://www.wstf.org/
	   (need to join to read archives, but if so, then issue was 
	    discussed here: http://www.wstf.org/mail/sc006/200805/msg1)
	that the sample wsdl in Appendix B appears to possibly have
	inadvertently included wsdl that is in conflict with WS/I BP:

		http://www.ws-i.org/Profiles/BasicProfile-1.0-2004-04-16.html		
	
WS-I BS text:
5.6.7 Wire Signatures for Operations
An endpoint that supports multiple operations must unambiguously identify the operation being invoked based on the input message that it receives. This is only possible if all the operations specified in the wsdl:binding associated with an endpoint have a unique wire signature. 

R2710 The operations in a wsdl:binding in a DESCRIPTION MUST result in wire signatures that are different from one another. 

The Profile defines the "wire signature" of an operation in a wsdl:binding to be the fully qualified name of the child element of the soap:Body of the SOAP input message it describes. For the case of an empty soap:Body this name is an empty string. 

In the case of rpc-literal binding, the operation name is used as a wrapper for the part accessors. In the document-literal case, since a wrapper with the operation name is not present, the message signatures must be correctly designed so that they meet this requirement.

	
Here is the wsdl for ref w problem lines marked by "<---***" on RHS:

<!-- This portType models the full request/response the Security Token Service: -->

    <wsdl:portType name="WSSecurityRequestor">
        <wsdl:operation name="SecurityTokenResponse">
            <wsdl:input message="tns:RequestSecurityTokenResponseMsg"/>    <---***
        </wsdl:operation>
        <wsdl:operation name="SecurityTokenResponse2">
            <wsdl:input 
                message="tns:RequestSecurityTokenResponseCollectionMsg"/>
        </wsdl:operation>
        <wsdl:operation name="Challenge">
            <wsdl:input message="tns:RequestSecurityTokenResponseMsg"/>    <---***
            <wsdl:output message="tns:RequestSecurityTokenResponseMsg"/>
        </wsdl:operation>
        <wsdl:operation name="Challenge2">
            <wsdl:input message="tns:RequestSecurityTokenResponseMsg"/>    <---***
            <wsdl:output 
                message="tns:RequestSecurityTokenResponseCollectionMsg"/>
        </wsdl:operation>
    </wsdl:portType>

<!-- These portTypes model the individual message exchanges -->

    <wsdl:portType name="SecurityTokenRequestService">
        <wsdl:operation name="RequestSecurityToken">
            <wsdl:input message="tns:RequestSecurityTokenMsg"/>
        </wsdl:operation>
    </wsdl:portType>

    <wsdl:portType name="SecurityTokenService">
        <wsdl:operation name="RequestSecurityToken">
            <wsdl:input message="tns:RequestSecurityTokenMsg"/>    <---***
            <wsdl:output message="tns:RequestSecurityTokenResponseMsg"/>
        </wsdl:operation>
        <wsdl:operation name="RequestSecurityToken2">
            <wsdl:input message="tns:RequestSecurityTokenMsg"/>    <---***
            <wsdl:output 
                 message="tns:RequestSecurityTokenResponseCollectionMsg"/>
        </wsdl:operation>
    </wsdl:portType>
</wsdl:definitions>

The problem with violating this convention is that if you try to do
automatic code generation, in at least one popular implementation
language you cannot have 2 methods in the same class with the same
signature, which is what happens with these identical input messages.

Related issues:

	N/A

Proposed Resolution:

  None: Not sure what would be intended here, because the example is showing
  messages to an STS, which can reply with different responses for
  output w same input. However, as shown the methods violate the WS-I
  guidelines. (appears that concept of in/out "signature" may be overloaded 
  here as there is both input/output at the message-in/message-out level as 
  well as creation of input message level)