Copyright © 2002-2010 by The Web Services-Interoperability Organization (WS-I) and Certain of its Members. All Rights Reserved.
This document defines the WS-I Reliable Secure Profile 1.0, consisting of a set of non-proprietary Web services specifications, along with clarifications, refinements, interpretations and amplifications of those specifications which promote interoperability. It also contains a set of executable test assertions for assessing the conformance to the profile.
This is a final specification. Please refer to the errata, which may include normative corrections to it.
The material contained herein is not a license, either expressly or impliedly, to any intellectual property owned or controlled by any of the authors or developers of this material or WS-I. The material contained herein is provided on an "AS IS" basis and to the maximum extent permitted by applicable law, this material is provided AS IS AND WITH ALL FAULTS, and the authors and developers of this material and WS-I hereby disclaim all other warranties and conditions, either express, implied or statutory, including, but not limited to, any (if any) implied warranties, duties or conditions of merchantability, of fitness for a particular purpose, of accuracy or completeness of responses, of results, of workmanlike effort, of lack of viruses, and of lack of negligence. ALSO, THERE IS NO WARRANTY OR CONDITION OF TITLE, QUIET ENJOYMENT, QUIET POSSESSION, CORRESPONDENCE TO DESCRIPTION OR NON-INFRINGEMENT WITH REGARD TO THIS MATERIAL.
IN NO EVENT WILL ANY AUTHOR OR DEVELOPER OF THIS MATERIAL OR WS-I BE LIABLE TO ANY OTHER PARTY FOR THE COST OF PROCURING SUBSTITUTE GOODS OR SERVICES, LOST PROFITS, LOSS OF USE, LOSS OF DATA, OR ANY INCIDENTAL, CONSEQUENTIAL, DIRECT, INDIRECT, OR SPECIAL DAMAGES WHETHER UNDER CONTRACT, TORT, WARRANTY, OR OTHERWISE, ARISING IN ANY WAY OUT OF THIS OR ANY OTHER AGREEMENT RELATING TO THIS MATERIAL, WHETHER OR NOT SUCH PARTY HAD ADVANCE NOTICE OF THE POSSIBILITY OF SUCH DAMAGES.
If there are areas in this specification that could be clearer, or if errors or omissions are identified, WS-I would like to be notified in order to provide the best possible interoperability guidance.
By sending email, or otherwise communicating with WS-I, you (on behalf of yourself if you are an individual, and your company if you are providing Feedback on behalf of the company) will be deemed to have granted to WS-I, the members of WS-I, and other parties that have access to your Feedback, a non-exclusive, non-transferable, worldwide, perpetual, irrevocable, royalty-free license to use, disclose, copy, license, modify, sublicense or otherwise distribute and exploit in any manner whatsoever the Feedback you provide regarding the work. You acknowledge that you have no expectation of confidentiality with respect to any Feedback you provide. You represent and warrant that you have rights to provide this Feedback, and if you are providing Feedback on behalf of a company, you represent and warrant that you have the rights to provide Feedback on behalf of your company. You also acknowledge that WS-I is not required to review, discuss, use, consider or in any way incorporate your Feedback into future versions of its work. If WS-I does incorporate some or all of your Feedback in a future version of the work, it may, but is not obligated to include your name (or, if you are identified as acting on behalf of your company, the name of your company) on a list of contributors to the work. If the foregoing is not acceptable to you and any company on whose behalf you are acting, please do not provide any Feedback.
Feedback on this document should be directed to wsi_rsp_comment@mp.ws-i.org.
1. Introduction
1.1. Relationships to
Other Profiles
1.2. Guiding
Principles
1.3. Test
Assertions
1.4. Notational
Conventions
1.5. Profile
Identification and Versioning
2. Profile Conformance
2.1. Conformance
Requirements
2.2. Conformance Targets
2.3. Conformance
Scope
2.4. Claiming
Conformance
3. Reliable Messaging
3.1. WS-ReliableMessaging Support
3.1.1. Requiring
WS-ReliableMessaging
3.2. Use of
Extension Elements and Attributes in Messages
3.2.1. Ignore Unknown Extension
Elements
3.3. SOAP Version
Considerations
3.3.1. SOAP
Version Selection for Sequence Lifecycle Messages
3.4. Targeting
Sequence Lifecycle Messages
3.4.1. CreateSequence Target
3.4.2. Use of the Offer
Element
3.5. Sequence
Identifiers
3.5.1. Duplicate
Identifier in CreateSequenceResponse
3.6. Sequence
Termination
3.6.1. Sequence Termination
from the Destination
3.6.2. Last
Message Number
3.6.3. Sequence Lifecycle
Independence
3.7. Sequence
Faults
3.7.1. WS-ReliableMessaging
Faults
3.8. Sequence
Assignment
3.8.1. Reliable Response
Messages
3.8.2. Scope
of an RM Node
3.9. Retransmission
of Messages
3.9.1. Retransmission of
Unacknowledged Messages
3.9.2. Retransmission of
Sequence Lifecycle Messages
3.9.3. Message
Identity
3.10. Piggybacking
3.10.1.
Endpoint Comparison for Piggybacked SequenceAcknowledgment
Headers
3.10.2. Treatment of
ReferenceParameters in AcksTo EPRs
3.10.3. Preventing Piggybacked
Acknowledgements
3.10.4. Conflicting Requirements
for wsa:Action
3.10.5. Use of the mustUnderstand
Attribute
4. Secure Conversation
4.1. WS-SecureConversation Support
4.1.1. Requiring
WS-SecureConversation
4.2. Optionality
of Operations
4.2.1. Support for Amending
Contexts
4.2.2. Support for Renewing
Contexts
4.2.3. Support for Canceling
Contexts
4.3. Unsupported
Context Tokens
4.3.1. Unrecognized
Extensions in a Security Context Token
4.4. Demonstrating Proof of
Possession
4.4.1. Amending Contexts
4.4.2. Renewing Contexts
4.4.3. Cancelling Contexts
4.5. Claims
Re-Authentication
4.5.1. Re-Authenticating
Claims
4.6. Referencing Security
Context Tokens
4.6.1. Associating a Security
Context
4.6.2. Derived Token
References to Security Contexts
4.7. Addressing
Headers
4.7.1. Protecting Addressing
Headers
5. MakeConnection
5.1. WS-MakeConnection Support
5.1.1. Requiring
WS-MakeConnection
5.1.2. Honoring
EPRs with the MakeConnection Anonymous URI
5.2. Guidance On the Use of
MakeConnection
5.2.1. Action
Values
5.2.2. Binding
to HTTP
5.2.3. Transmission of
MakeConnection Faults
5.3. MakeConnection
Addressing
5.3.1. Addressing Variants
5.3.2. MakeConnection Anonymous
URI
5.4. MakeConnection Fault
Behavior
5.4.1. [Detail] Property
Mapping
6. Secure Reliable Messaging
6.1. Initiating a Secure
Sequence
6.1.1. Secure Context
Identification
6.1.2. Security Token
References
6.2. Signature
Coverage
6.2.1. Single
Signature for Sequence Header and SOAP Body
6.2.2. Signed
Elements
6.2.3. Single
Signature for SOAP 1.1 Fault and SequenceFault
Header
6.3. Secure Use of
MakeConnection
6.3.1. Security Context for
MakeConnection
6.3.2. Signing the MessagePending
header
6.4. Replay
Detection
6.4.1. Unique Timestamp Values
Appendix A: Referenced
Specifications
Appendix B: Extensibility Points
Appendix C: Normative
References
Appendix D: Acknowledgements
Appendix E: Schemas
This document defines the WS-I Reliable Secure Profile 1.0 (hereafter, "Profile"), consisting of a set of non-proprietary Web services specifications, along with clarifications, refinements, interpretations and amplifications of those specifications which promote interoperability.
Section 1 introduces the Profile, and explains its relationships to other profiles.
Section 2, "Profile Conformance," explains what it means to be conformant to the Profile.
Each subsequent section addresses a component of the Profile, and consists of two parts; an overview detailing the component specifications and their extensibility points, followed by subsections that address individual parts of the component specifications. Note that there is no relationship between the section numbers in this document and those in the referenced specifications.
This Profile is intended to be composed with the WS-I Basic Profile 1.2, WS-I Basic Profile 2.0, WS-I Basic Security Profile 1.0 and WS-I Basic Security Profile 1.1. Composability of RSP with the previously mentioned profiles offers the following guarantee to users: conformance of an artifact to RSP does not prevent conformance of this artifact to these other profiles, and vice-versa.
Because the conformance targets defined for RSP may not match exactly the conformance targets for another profile, the following more precise definition of composability is assumed in this profile:
A target T1 is said to depend on a target T2 if either:
In order to conform to this profile (RSP):
The Profile was developed according to a set of principles that, together, form the philosophy of the Profile, as it relates to bringing about interoperability. This section documents these guidelines.
This profile document contains embedded Test Assertions (TA) that are associated with each normative profile requirement. In the HTML rendering of this document, these test assertions are accessible via a toggle link at the end of each requirement. When clicking on such a link, a table pops up that displays the TA parts. At the end of this table is another toggle link ("help-glossary") that displays an explanation glossary for the TA structure. In other formats of this document, the test assertions are grouped in an appendix not controlled by any link, in order to facilitate the printing of hard copies. The resulting set of test assertions embedded in this document represents a conformance test suite for the profile.
Release notes related to the test material included in this document are available here:
TESTING-RELEASE-NOTESNote Item: | Release Notes : 2010-04-06 |
---|---|
test suite |
The test assertions are scripted using XPath2.0 and are automatically processable using the version 2.0 of the WS-I Analyzer tools. Several requirements have been tagged "NOT_TESTABLE". This means that these requirements cannot be tested based on the technology choices (black-box testing, XPath scripting). Other requirements have been tagged "NOT_TESTED". This is the case for most optional requirements (SHOULD, MAY), and for most Extensibility points. Other requirements have been tagged "TESTABLE_SCENARIO_DEPENDENT". This is the case when a specific test scenario is needed in order to exercise the related test assertion, because the test assertion is designed to trigger only on specific input material, e.g. that is known to NEVER be recognizable by an endpoint. A subsequent version may cover untested requirements. In this profile, the core requirements for assessing interoperability of implementations have been initially targeted. |
test assertions notes |
A few test assertions are scenario-dependent: they only trigger if specific values are used in the messages generated by the test scenarios. They are: RSP0001: this TA is designed to only detect messages with unrecognizable extensions that use the namespace: "http://dummy.example.org/unknown/nmspace". RSP0400a: this TA is designed to only detect messages that use an unrecognizable Sequence ID of value : "http://dummy.example.org/unknown/nmspace". RSP0400b: this TA is designed to only detect messages that use an unrecognizable Sequence ID of value : "http://dummy.example.org/unknown/nmspace". RSP1001: this TA is designed to only detect messages that use an unrecognizable element inside an SCT, with namespace of value : "http://dummy.example.org/unknown/nmspace". One test assertion does not match any specific Rxxxx, but stems from general profile requirement: RSP8001: this TA is designed to ensure that all messages are either compliant with SOAP 1.1 or SOAP 1.2. Test assertions are not guaranteed to exhaustively cover every case where a profile requirement applies. In several instances, more than one test assertion is needed to address the various situations where a profile requirement applies. Test assertions are usually scripted as rules of the form: "if situation(X) occurs, then verify that property(Y) is true ". It may be that the situation ("X") that is associated with a test assertion, will never occur because the features concerned by this situation are optional and not implemented by an endpoint. In such a case it is expected that test reports will never exercise such a test assertion, for this implementation. To learn more about the details of test assertion outcomes and how they are reported in the test report, see the glossary link that appears below each test assertion table. |
test log rules |
Test Log content conventions: The test assertions designed for this test suite are written to work over "test log" files that are assumed to follow some rules in their structure and content. These rules are more completely stated in the documentation associated with the log file description. Some of these rules are: - Every message in the log must be uniquely identified: it must have a unique pair of values for: {message/@conversation, message/@id}, where @id is unique within each conversation. Typically, a conversation is used to identify an HTTP connection and the group of messages over this connection. - A response message (for WSDL request-responses as well as RM lifecycle messages) always appears after the request message in the log file. - A wsa:RelatesTo reference always refers to a message that has been logged before. - A Fault message always appears after the message-in-error. - An RM acknowledgement always appears after the messages it acknowledges. - there should not be both a doc-lit and an rpc-lit bindings for the same portType. - imports must be resolved locally to the log file. |
The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC2119.
Normative statements of requirements in the Profile (i.e., those impacting conformance, as outlined in "Conformance Requirements") are presented in the following manner:
RnnnnStatement text here.
where "nnnn" is replaced by a number that is unique among the requirements in the Profile, thereby forming a unique requirement identifier.
Requirements can be considered to be namespace qualified, in such a way as to be compatible with QNames from Namespaces in XML. If there is no explicit namespace prefix on a requirement's identifier (e.g., "R9999" as opposed to "bp10:R9999"), it should be interpreted as being in the namespace identified for this Profile.
Extensibility points in underlying specifications (see "Conformance Scope") are presented in a similar manner:
EnnnnExtensibility Point Name - Description
where "nnnn" is replaced by a number that is unique among the extensibility points in the Profile. As with requirement statements, extensibility statements can be considered namespace-qualified.
This specification uses a number of namespace prefixes throughout; their associated URIs are listed below. Note that the choice of any namespace prefix is arbitrary and not semantically significant.
This document is identified by a name (in this case, Reliable Secure Profile) and a version number (here, 1.0). Together, they identify a particular profile instance.
Version numbers are composed of a major and minor portion, in the form "major.minor". They can be used to determine the precedence of a profile instance; a higher version number (considering both the major and minor components) indicates that an instance is more recent, and therefore supersedes earlier instances.
Instances of profiles with the same name (e.g., "Example Profile 1.1" and "Example Profile 5.0") address interoperability problems in the same general scope (although some developments may require the exact scope of a profile to change between instances).
One can also use this information to determine whether two instances of a profile are backwards-compatible; that is, whether one can assume that conformance to an earlier profile instance implies conformance to a later one. Profile instances with the same name and major version number (e.g., "Example Profile 1.0" and "Example Profile 1.1") MAY be considered compatible. Note that this does not imply anything about compatibility in the other direction; that is, one cannot assume that conformance with a later profile instance implies conformance to an earlier one.
Conformance to the Profile is defined by adherence to the set of requirements defined for a specific target, within the scope of the Profile. This section explains these terms and describes how conformance is defined and used.
Requirements state the criteria for conformance to the Profile. They typically refer to an existing specification and embody refinements, amplifications, interpretations and clarifications to it in order to improve interoperability. All requirements in the Profile are considered normative, and those in the specifications it references that are in-scope (see "Conformance Scope") should likewise be considered normative. When requirements in the Profile and its referenced specifications contradict each other, the Profile's requirements take precedence for purposes of Profile conformance.
Requirement levels, using RFC2119 language (e.g., MUST, MAY, SHOULD) indicate the nature of the requirement and its impact on conformance. Each requirement is individually identified (e.g., R9999) for convenience.
For example;
R9999 Any WIDGET SHOULD be round in shape.
This requirement is identified by "R9999", applies to the target WIDGET (see below), and places a conditional requirement upon widgets.
Each requirement statement contains exactly one requirement level keyword (e.g., "MUST") and one conformance target keyword (e.g., "MESSAGE"). The conformance target keyword appears in bold text (e.g. "MESSAGE"). Other conformance targets appearing in non-bold text are being used strictly for their definition and NOT as a conformance target. Additional text may be included to illuminate a requirement or group of requirements (e.g., rationale and examples); however, prose surrounding requirement statements must not be considered in determining conformance.
Definitions of terms in the Profile are considered authoritative for the purposes of determining conformance.
Conformance targets identify what artifacts (e.g., SOAP message, WSDL description, UDDI registry data) or parties (e.g., SOAP processor, end user) requirements apply to.
This allows for the definition of conformance in different contexts, to assure unambiguous interpretation of the applicability of requirements, and to allow conformance testing of artifacts (e.g., SOAP messages and WSDL descriptions) and the behavior of various parties to a Web service (e.g., clients and service instances).
Requirements' conformance targets are physical artifacts wherever possible, to simplify testing and avoid ambiguity.
The following conformance targets are used in the Profile:
The scope of the Profile delineates the technologies that it addresses; in other words, the Profile only attempts to improve interoperability within its own scope. Generally, the Profile's scope is bounded by the specifications referenced by it.
The Profile's scope is further refined by extensibility points. Referenced specifications often provide extension mechanisms and unspecified or open-ended configuration parameters; when identified in the Profile as an extensibility point, such a mechanism or parameter is outside the scope of the Profile, and its use or non-use is not relevant to conformance.
Note that the Profile may still place requirements on the use of an extensibility point. Also, specific uses of extensibility points may be further restricted by other profiles, to improve interoperability when used in conjunction with the Profile.
Because the use of extensibility points may impair interoperability, their use should be negotiated or documented in some fashion by the parties to a Web service; for example, this could take the form of an out-of-band agreement.
The Profile's scope is defined by the referenced specifications in Appendix A, as refined by the extensibility points in Appendix B.
To claim conformance to this Profile, a deployed instance MUST support one or more of the WS-ReliableMessaging (WS-RM), WS-SecureConversation (WS-SC), or WS-MakeConnection (WS-MC) protocols, either individually or in some combination thereof, in a manner that conforms to the requirements set forth in this profile.
Deployed instances can advertise their conformance to this Profile either through the use of mechanisms as described in Conformance Claim Attachment Mechanisms (see section 2.4.1) or through the use of mechanisms as described in Web Services Policy - Framework [WS-Policy 1.5] and Web Services Policy - Attachment [WS-Policy Attachment 1.5] specifications (see section 2.4.2). Prior agreements between partners on how Profile conformance is to be advertised or required might exist. When no such prior agreement exists and there is a need to advertise, the use of WS-Policy is RECOMMENDED over the use of the Conformance Claim Attachment Mechanisms.
Mechanisms described in Conformance Claim Attachment Mechanisms can be used to advertise conformance to this profile, when the applicable Profile requirements associated with the listed targets have been met:
The conformance claim URIs are:
To claim conformance to the requirements pertaining to WS-ReliableMessaging (Section 3 "Reliable Messaging" ) defined by this Profile, and to require the use of WS-ReliableMessaging when using the claiming endpoint:
To claim conformance to the requirements pertaining to WS-SecureConversation (Section 4 "Secure Conversation" ) defined by this Profile, and to require the use of WS-SecureConversation when using the claiming endpoint:
To claim conformance to the requirements pertaining to WS-MakeConnection (Section 5 "Make Connection" ) defined by this Profile, and to require the use of WS-MakeConnection when using the claiming endpoint:
Use of more than one or a combination of the above conformance
claim URIs is allowed. When the claim URI
"http://ws-i.org/profiles/rsp/1.0/ws-sc/"
is combined
with either "http://ws-i.org/profiles/rsp/1.0/ws-rm/"
or "http://ws-i.org/profiles/rsp/1.0/ws-mc/"
, the
requirements pertaining to such a combination as detailed in
Section 6 "Secure
Reliable Messaging" are also claimed to be conformed with.
The conformance claim URI to claim conformance to all requirements defined by this Profile is
NOTE: Because there is no requirement targeting WSDL constructs in RSP, a conformance claim attached to a wsdl:port only indicates conformance of the service instance to this Profile.
Mechanisms described in Web Services Policy - Framework [WS-Policy 1.5] and Web Services Policy - Attachment [WS-Policy Attachment 1.5] specifications can be used to advertise conformance to this profile.
The Profile defines the following policy assertion for this purpose:
<rsp:Conformant
xmlns:rsp="http://ws-i.org/profiles/rsp/1.0/"/>
The presence of this assertion indicates that policy subject supports one or more of the WS-RM, WS-SC, or WS-MC protocols in a manner that conforms to RSP 1.0. This assertion only has meaning when used in a policy alternative that also contains at least one of wsrmp:RMAssertion, wsmc:MCSupported, or wsp:SecureConversationToken. The semantics of this assertion apply only to those protocols (WS-RM, WS-SC, or WS-MC) whose use is indicated by a policy assertion within the same policy alternative as this assertion. This assertion also requires that clients MUST use the effected protocols in a way that conforms to RSP 1.0. The absence of this assertion says nothing about RSP 1.0 conformance; it simply indicates the lack of an affirmative declaration of and requirement for RSP 1.0 conformance.
The rsp:Conformant
policy assertion applies to the
endpoint policy subject. For WSDL 1.1, this assertion can be
attached to a wsdl11:port
or
wsdl11:binding
. A policy expression containing the
rsp:Conformant
policy assertion MUST NOT be attached
to a wsdl:portType
.
Use of this policy assertion to claim conformance is highly encouraged.
This following example shows a policy expression that indicates/requires support for RSP 1.0 conformant WS-RM.
For example,
CORRECT:
<wsp:Policy xmlns:wsp="http://www.w3.org/ns/ws-policy" xmlns:wsrmp="http://docs.oasis-open.org/ws-rx/wsrmp/200702" xmlns:rsp="http://ws-i.org/profiles/rsp/1.0/"> <wsrmp:RMAssertion> <wsp:Policy/> </wsrmp:RMAssertion> <rsp:Conformant/> </wsp:Policy>
In the following example, the use of WS-RM is advertised as supporting/requiring conformance with RSP 1.0, but it is indeterminate whether or not the implementation of WS-MC supports or requires RSP 1.0 conformance.
For example,
CORRECT:
<wsp:Policy xmlns:wsp="http://www.w3.org/ns/ws-policy" xmlns:wsrmp="http://docs.oasis-open.org/ws-rx/wsrmp/200702" xmlns:rsp="http://ws-i.org/profiles/rsp/1.0/"> <wsp:ExactlyOne> <wsp:All> <wsrmp:RMAssertion> <wsp:Policy/> </wsrmp:RMAssertion> <rsp:Conformant/> </wsp:All> <wsp:All> <wsmc:MCSupported/> </wsp:All> </wsp:ExactlyOne> </wsp:Policy>
This section of the Profile incorporates the following specifications by reference, and defines extensibility points within them:
These extensibility points are listed, along with any extensibility points from other sections of this Profile, in Appendix B
As noted in Section 2 , support for WS-ReliableMessaging by a specific service is optional. However, a service may require the use of WS-ReliableMessaging, in which case, for successful interaction with that service, a client will need to support it.
R0002 If an endpoint requires the use of WS-ReliableMessaging, any ENVELOPE sent to that endpoint MUST conform to Section 3 of this Profile. TESTABLE RSP0002a RSP0002b
Test Assertion Analysis: | RSP0002a |
---|---|
General Notes: | |
Coverage Assessment: | partial: only checks for the common case of presence of an rm:Sequence header, for sequence traffic messages. |
Target Type: | ENVELOPE |
Test Target: | |
Test co-Target(s): | |
Test Prerequisite: | |
Predicate: | |
Prescription: | mandatory |
Reporting: | true=passed, false=failed |
Test Control: |
Test Assertion: | RSP0002a |
---|---|
Description: | |
Target: |
|
co-Target: myOpBinding |
|
Predicate: |
|
Reporting: | true=passed, false=failed |
Prescription: | mandatory |
Error Message: | A SOAP Envelope with an WSDL rpc-lit binding, and for which the use of WS-ReliableMessaging was required, did not contain a wsrm:Sequence header. |
Diagnostic Data: |
|
Test Assertion Part | What it means: |
---|---|
Test Assertion ID: |
[markup: testAssertion/@id] (required) A unique ID for the current test assertion. |
Description: |
[markup: testAssertion/description ] (optional) A plain text description of the current test assertion. At minimum expressing the TA predicate. |
Comments: |
[markup: testAssertion/comments ] (optional) A plain text comment about the TA script and how well it covers the profile requirement. Explanation material for users, and developers (what could be improved, etc.). |
Target: |
[markup: testAssertion/target ] (required) The artifacts to be tested, defined by an XPath expression that returns a list of XML nodes from the log file in input. For every artifact (node) selected by the Target expression, there will be a report entry for this TA in the test report, with a result of either:
See the "reporting" item for the meaning of these results. |
Cotarget: |
[markup: testAssertion/cotarget ] (optional) Artifact that is related to the target, and that needs be accessed for the testing. Identified by an XPath expression that may refer to the related target node using the variable '$target'. For example, the target can be a SOAP message and the cotarget the WSDL file that describes this SOAP message. A cotarget must have a @name attribute that identifies it. The value of this attribute can be used as a variable (when prepending '$' to it) by subsequently defined cotargets, prerequisite and predicate. |
Prerequisite: |
[markup: testAssertion/@preReq ] (optional) [markup: testAssertion/prerequisite ] (optional) The pre-condition for evaluating this Test Assertion on this target. If the prerequisite evaluates to "false" then the target does not qualify for this Test Assertion (the test report is "notRelevant") The first part (preReq attribute) is an enumeration of Test Assertion IDs. Each one of the prerequisite TAs must either use the same target (e.g. SOAP Envelope, or WSDL binding, etc.) as this TA, or a target that is of a more general type than the main TA target. The target must "pass" each one of these prerequisite TAs in order to qualify for this TA. (e.g. the target of TA t1 can be a WSDL binding while the target of a TA t2 prerequisite of t1, can be the entire WSDL file). The second part ("prerequisite" element) is an XPath (boolean) expression of the same nature as the predicate. If present, it must evaluate to "true" for the target to qualify. If it fails, the result for the current TA in the report will be "notRelevant". Otherwise, the target can be further evaluated by the predicate of the main TA. The expression may refer to the target explicitly using the variable name "$target", or to any cotarget using its name as variable name ($[name]). |
Predicate: |
[markup: testAssertion/predicate] required element] A logical expression that evaluates whether this target is fulfilling the profile requirement addressed by this test Assertion. By default: - A result of true means the requirement is fulfilled (reported as a "passed" in the test report).- A result of false means the requirement is violated (reported as a "failed" in the test report). However, in some cases and for testability reasons, the predicate may be designed as a partial indicator e.g. only indicates some cases of fulfillment, or some cases of violation. As a result, when "true" indicates fulfillment it may be that "false" is unconclusive, or conversely "false" will indicate violation, but "true" is unconclusive. In such cases, the "Reporting" element specifies the meaning of the predicate result w/r to the profile requirement. The predicate expression implicitly refers to the target (whic is its "XPath context") although it may explicitly refer to it using the variable name "$target". It may refer to any cotarget using its name as variable name ($[name]). |
Prescription: |
[markup: testAssertion/prescription/@level ] (required) Conveys the level of prescription associated with the profile requirement. At least three values may be used:
|
Reporting: |
[markup: testAssertion/reporting ] (optional) For each possible outcome of the predicate (true or false), specifies how it must be interpreted w/r to the profile feature. Two attributes are used that both must be present, when this element is present:
NOTES: the predicate of the TA may be worded in a negative way so that @false='passed' although that is not recommended. The result of a test should not be related to the prescription level, e.g. a "preferred" or "permitted" level should not imply that @false='warning'. Other test results that are automatically generated and not controlled by the "reporting" element are:
|
Test Assertion Analysis: | RSP0002b |
---|---|
General Notes: | |
Coverage Assessment: | partial: only checks for the common case of presence of an rm:Sequence header, for sequence traffic messages. |
Target Type: | ENVELOPE |
Test Target: | |
Test co-Target(s): | |
Test Prerequisite: | |
Predicate: | |
Prescription: | mandatory |
Reporting: | true=passed, false=failed |
Test Control: |
Test Assertion: | RSP0002b |
---|---|
Description: | |
Target: |
|
co-Target: myOpBinding |
|
Predicate: |
|
Reporting: | true=passed, false=failed |
Prescription: | mandatory |
Error Message: | A SOAP Envelope with an WSDL doc-lit binding, and for which the use of WS-ReliableMessaging was required, did not contain a wsrm:Sequence header. |
Diagnostic Data: |
|
Test Assertion Part | What it means: |
---|---|
Test Assertion ID: |
[markup: testAssertion/@id] (required) A unique ID for the current test assertion. |
Description: |
[markup: testAssertion/description ] (optional) A plain text description of the current test assertion. At minimum expressing the TA predicate. |
Comments: |
[markup: testAssertion/comments ] (optional) A plain text comment about the TA script and how well it covers the profile requirement. Explanation material for users, and developers (what could be improved, etc.). |
Target: |
[markup: testAssertion/target ] (required) The artifacts to be tested, defined by an XPath expression that returns a list of XML nodes from the log file in input. For every artifact (node) selected by the Target expression, there will be a report entry for this TA in the test report, with a result of either:
See the "reporting" item for the meaning of these results. |
Cotarget: |
[markup: testAssertion/cotarget ] (optional) Artifact that is related to the target, and that needs be accessed for the testing. Identified by an XPath expression that may refer to the related target node using the variable '$target'. For example, the target can be a SOAP message and the cotarget the WSDL file that describes this SOAP message. A cotarget must have a @name attribute that identifies it. The value of this attribute can be used as a variable (when prepending '$' to it) by subsequently defined cotargets, prerequisite and predicate. |
Prerequisite: |
[markup: testAssertion/@preReq ] (optional) [markup: testAssertion/prerequisite ] (optional) The pre-condition for evaluating this Test Assertion on this target. If the prerequisite evaluates to "false" then the target does not qualify for this Test Assertion (the test report is "notRelevant") The first part (preReq attribute) is an enumeration of Test Assertion IDs. Each one of the prerequisite TAs must either use the same target (e.g. SOAP Envelope, or WSDL binding, etc.) as this TA, or a target that is of a more general type than the main TA target. The target must "pass" each one of these prerequisite TAs in order to qualify for this TA. (e.g. the target of TA t1 can be a WSDL binding while the target of a TA t2 prerequisite of t1, can be the entire WSDL file). The second part ("prerequisite" element) is an XPath (boolean) expression of the same nature as the predicate. If present, it must evaluate to "true" for the target to qualify. If it fails, the result for the current TA in the report will be "notRelevant". Otherwise, the target can be further evaluated by the predicate of the main TA. The expression may refer to the target explicitly using the variable name "$target", or to any cotarget using its name as variable name ($[name]). |
Predicate: |
[markup: testAssertion/predicate] required element] A logical expression that evaluates whether this target is fulfilling the profile requirement addressed by this test Assertion. By default: - A result of true means the requirement is fulfilled (reported as a "passed" in the test report).- A result of false means the requirement is violated (reported as a "failed" in the test report). However, in some cases and for testability reasons, the predicate may be designed as a partial indicator e.g. only indicates some cases of fulfillment, or some cases of violation. As a result, when "true" indicates fulfillment it may be that "false" is unconclusive, or conversely "false" will indicate violation, but "true" is unconclusive. In such cases, the "Reporting" element specifies the meaning of the predicate result w/r to the profile requirement. The predicate expression implicitly refers to the target (whic is its "XPath context") although it may explicitly refer to it using the variable name "$target". It may refer to any cotarget using its name as variable name ($[name]). |
Prescription: |
[markup: testAssertion/prescription/@level ] (required) Conveys the level of prescription associated with the profile requirement. At least three values may be used:
|
Reporting: |
[markup: testAssertion/reporting ] (optional) For each possible outcome of the predicate (true or false), specifies how it must be interpreted w/r to the profile feature. Two attributes are used that both must be present, when this element is present:
NOTES: the predicate of the TA may be worded in a negative way so that @false='passed' although that is not recommended. The result of a test should not be related to the prescription level, e.g. a "preferred" or "permitted" level should not imply that @false='warning'. Other test results that are automatically generated and not controlled by the "reporting" element are:
|
R0003 If an endpoint requires or supports the use of WS-ReliableMessaging, the corresponding INSTANCE MUST behave in accordance with Section 3 of this Profile. TESTABLE RSP0003
Test Assertion Analysis: | RSP0003 |
---|---|
General Notes: | |
Coverage Assessment: | partial: |
Target Type: | ENVELOPE |
Test Target: | |
Test co-Target(s): | |
Test Prerequisite: | |
Predicate: | |
Prescription: | mandatory |
Reporting: | true=passed, false=failed |
Test Control: |
Test Assertion: | RSP0003 |
---|---|
Description: | |
Target: |
|
Predicate: |
|
Reporting: | true=passed, false=failed |
Prescription: | mandatory |
Error Message: | A SOAP Fault from an INSTANCE is reporting a NotUnderstood fault about a wsrm element, while the use of RM was required (RMAssertion). |
Diagnostic Data: |
|
Test Assertion Part | What it means: |
---|---|
Test Assertion ID: |
[markup: testAssertion/@id] (required) A unique ID for the current test assertion. |
Description: |
[markup: testAssertion/description ] (optional) A plain text description of the current test assertion. At minimum expressing the TA predicate. |
Comments: |
[markup: testAssertion/comments ] (optional) A plain text comment about the TA script and how well it covers the profile requirement. Explanation material for users, and developers (what could be improved, etc.). |
Target: |
[markup: testAssertion/target ] (required) The artifacts to be tested, defined by an XPath expression that returns a list of XML nodes from the log file in input. For every artifact (node) selected by the Target expression, there will be a report entry for this TA in the test report, with a result of either:
See the "reporting" item for the meaning of these results. |
Cotarget: |
[markup: testAssertion/cotarget ] (optional) Artifact that is related to the target, and that needs be accessed for the testing. Identified by an XPath expression that may refer to the related target node using the variable '$target'. For example, the target can be a SOAP message and the cotarget the WSDL file that describes this SOAP message. A cotarget must have a @name attribute that identifies it. The value of this attribute can be used as a variable (when prepending '$' to it) by subsequently defined cotargets, prerequisite and predicate. |
Prerequisite: |
[markup: testAssertion/@preReq ] (optional) [markup: testAssertion/prerequisite ] (optional) The pre-condition for evaluating this Test Assertion on this target. If the prerequisite evaluates to "false" then the target does not qualify for this Test Assertion (the test report is "notRelevant") The first part (preReq attribute) is an enumeration of Test Assertion IDs. Each one of the prerequisite TAs must either use the same target (e.g. SOAP Envelope, or WSDL binding, etc.) as this TA, or a target that is of a more general type than the main TA target. The target must "pass" each one of these prerequisite TAs in order to qualify for this TA. (e.g. the target of TA t1 can be a WSDL binding while the target of a TA t2 prerequisite of t1, can be the entire WSDL file). The second part ("prerequisite" element) is an XPath (boolean) expression of the same nature as the predicate. If present, it must evaluate to "true" for the target to qualify. If it fails, the result for the current TA in the report will be "notRelevant". Otherwise, the target can be further evaluated by the predicate of the main TA. The expression may refer to the target explicitly using the variable name "$target", or to any cotarget using its name as variable name ($[name]). |
Predicate: |
[markup: testAssertion/predicate] required element] A logical expression that evaluates whether this target is fulfilling the profile requirement addressed by this test Assertion. By default: - A result of true means the requirement is fulfilled (reported as a "passed" in the test report).- A result of false means the requirement is violated (reported as a "failed" in the test report). However, in some cases and for testability reasons, the predicate may be designed as a partial indicator e.g. only indicates some cases of fulfillment, or some cases of violation. As a result, when "true" indicates fulfillment it may be that "false" is unconclusive, or conversely "false" will indicate violation, but "true" is unconclusive. In such cases, the "Reporting" element specifies the meaning of the predicate result w/r to the profile requirement. The predicate expression implicitly refers to the target (whic is its "XPath context") although it may explicitly refer to it using the variable name "$target". It may refer to any cotarget using its name as variable name ($[name]). |
Prescription: |
[markup: testAssertion/prescription/@level ] (required) Conveys the level of prescription associated with the profile requirement. At least three values may be used:
|
Reporting: |
[markup: testAssertion/reporting ] (optional) For each possible outcome of the predicate (true or false), specifies how it must be interpreted w/r to the profile feature. Two attributes are used that both must be present, when this element is present:
NOTES: the predicate of the TA may be worded in a negative way so that @false='passed' although that is not recommended. The result of a test should not be related to the prescription level, e.g. a "preferred" or "permitted" level should not imply that @false='warning'. Other test results that are automatically generated and not controlled by the "reporting" element are:
|
Note that two RSP compliant web services implementations might both support the use of WS-ReliableMessaging yet fail to agree on a common set of features necessary to interact with one another. For example, a client might require the use of the "InOrder" Delivery Assurance, yet the service might not support this Delivery Assurance.
The protocol elements defined by WS-ReliableMessaging contain extension points wherein implementations MAY add child elements and/or attributes.
To ensure the ability to safely extend the protocol, it is necessary that adding an extension does not create the risk of impacting interoperability with non-extended implementations.
R0001 A RECEIVER MUST NOT generate a fault as a consequence of receiving a message (e.g. wsrm:CreateSequence) that contains extension elements and/or attributes that it does not recognize, unless that extension is a SOAP Header with a mustUndestand="1" attribute. Any exceptions to this rule are clearly identified in requirements below or the specifications underlying the profile.TESTABLE_SCENARIO_DEPENDENT RSP0001
Test Assertion Analysis: | RSP0001 |
---|---|
General Notes: | NOTE1: the actual test target is the observable artifact under test. NOTE2: given partial coverage, probably better to test for the negative case: predicate=true means failure. Inthe error message (or warning message): mention what to look for NOTE3: need to finalize the expected fault-message correlation. NOTE4: test env alignment: use same unrecognizable extension. |
Coverage Assessment: | partial (only some extension cases, and some messages types to be tested, and also can't sort out the real cause of the Fault) |
Target Type: | ENVELOPE |
Test Target: | for a soap:Envelope (not just wsrm:CreateSequence) with a special extension that is known to be NOT understood |
Test co-Target(s): | |
Test Prerequisite: | |
Predicate: | there is a Fault in response to the message with extension. |
Prescription: | mandatory |
Reporting: | true=warning, false=undetermined |
Test Control: | Align with unrecognizable extension expected in the TA. Generate a wsrm:CreateSequence message that makes use of the unrecognizable extension. Require response for anonymous URI. |
Test Assertion: | RSP0001 |
---|---|
Description: | |
Target: |
some $elt in .//* satisfies string(fn:namespace-uri($elt)) = 'http://dummy.example.org/unknown/nmspace' ] |
co-Target: myresponse |
(@type = 'response' and @conversation = $target/../../@conversation) or (.//*:Envelope/*:Header/wsa:RelatesTo[@RelationshipType = 'http://www.w3.org/2005/08/addressing/reply' or not (@RelationshipType)] = $target/*:Header/wsa:MessageID) ] /wsil:messageContents/*:Envelope |
Predicate: |
|
Reporting: | true=passed, false=warning |
Prescription: | mandatory |
Error Message: | A SOAP Fault was generated in response to a message that contains elements with an unrecognized extension - here, a predefined namespace URI. |
Diagnostic Data: |
|
Test Assertion Part | What it means: |
---|---|
Test Assertion ID: |
[markup: testAssertion/@id] (required) A unique ID for the current test assertion. |
Description: |
[markup: testAssertion/description ] (optional) A plain text description of the current test assertion. At minimum expressing the TA predicate. |
Comments: |
[markup: testAssertion/comments ] (optional) A plain text comment about the TA script and how well it covers the profile requirement. Explanation material for users, and developers (what could be improved, etc.). |
Target: |
[markup: testAssertion/target ] (required) The artifacts to be tested, defined by an XPath expression that returns a list of XML nodes from the log file in input. For every artifact (node) selected by the Target expression, there will be a report entry for this TA in the test report, with a result of either:
See the "reporting" item for the meaning of these results. |
Cotarget: |
[markup: testAssertion/cotarget ] (optional) Artifact that is related to the target, and that needs be accessed for the testing. Identified by an XPath expression that may refer to the related target node using the variable '$target'. For example, the target can be a SOAP message and the cotarget the WSDL file that describes this SOAP message. A cotarget must have a @name attribute that identifies it. The value of this attribute can be used as a variable (when prepending '$' to it) by subsequently defined cotargets, prerequisite and predicate. |
Prerequisite: |
[markup: testAssertion/@preReq ] (optional) [markup: testAssertion/prerequisite ] (optional) The pre-condition for evaluating this Test Assertion on this target. If the prerequisite evaluates to "false" then the target does not qualify for this Test Assertion (the test report is "notRelevant") The first part (preReq attribute) is an enumeration of Test Assertion IDs. Each one of the prerequisite TAs must either use the same target (e.g. SOAP Envelope, or WSDL binding, etc.) as this TA, or a target that is of a more general type than the main TA target. The target must "pass" each one of these prerequisite TAs in order to qualify for this TA. (e.g. the target of TA t1 can be a WSDL binding while the target of a TA t2 prerequisite of t1, can be the entire WSDL file). The second part ("prerequisite" element) is an XPath (boolean) expression of the same nature as the predicate. If present, it must evaluate to "true" for the target to qualify. If it fails, the result for the current TA in the report will be "notRelevant". Otherwise, the target can be further evaluated by the predicate of the main TA. The expression may refer to the target explicitly using the variable name "$target", or to any cotarget using its name as variable name ($[name]). |
Predicate: |
[markup: testAssertion/predicate] required element] A logical expression that evaluates whether this target is fulfilling the profile requirement addressed by this test Assertion. By default: - A result of true means the requirement is fulfilled (reported as a "passed" in the test report).- A result of false means the requirement is violated (reported as a "failed" in the test report). However, in some cases and for testability reasons, the predicate may be designed as a partial indicator e.g. only indicates some cases of fulfillment, or some cases of violation. As a result, when "true" indicates fulfillment it may be that "false" is unconclusive, or conversely "false" will indicate violation, but "true" is unconclusive. In such cases, the "Reporting" element specifies the meaning of the predicate result w/r to the profile requirement. The predicate expression implicitly refers to the target (whic is its "XPath context") although it may explicitly refer to it using the variable name "$target". It may refer to any cotarget using its name as variable name ($[name]). |
Prescription: |
[markup: testAssertion/prescription/@level ] (required) Conveys the level of prescription associated with the profile requirement. At least three values may be used:
|
Reporting: |
[markup: testAssertion/reporting ] (optional) For each possible outcome of the predicate (true or false), specifies how it must be interpreted w/r to the profile feature. Two attributes are used that both must be present, when this element is present:
NOTES: the predicate of the TA may be worded in a negative way so that @false='passed' although that is not recommended. The result of a test should not be related to the prescription level, e.g. a "preferred" or "permitted" level should not imply that @false='warning'. Other test results that are automatically generated and not controlled by the "reporting" element are:
|
While the extensibility points of the profiled specifications
can be used, per R0001 they MUST be ignored if they are not
understood. However if a SENDER wishes to ensure that the RECEIVER
understands and will comply with any such extensions, they need to
include a SOAP header, marked with mustUnderstand="1"
, in the request message that requires adherence to the semantics
of those extensions.
In general, it is not expected that the service descriptions for applications that use WS-ReliableMessaging will include bindings of the WS-RM protocol itself. This being the case, there is some uncertainty about which version of SOAP should be used to carry Sequence Lifecycle Messages.
For messages that flow from the RMS to the RMD, the version(s) of SOAP used for Sequence Lifecycle Messages are constrained to the version(s) of SOAP that are supported by the target endpoint (i.e. the endpoint to which the client is attempting to reliably communicate). For example, if a client is attempting to communicate reliably to an endpoint who's service description indicates that it only supports SOAP 1.1, the RMS should only send Sequence Lifecycle Messages using SOAP 1.1. Sequence Lifecycle Response Messages (CreateSequenceResponse, TerminateSequenceResponse, and CloseSequenceResponse) should use the version of SOAP used by their corresponding request message (CreateSequence, TerminateSequence, and CloseSequence respectively); this applies to WS-RM fault messages as well. For messages that flow from the RMD to the RMS (SequenceAck messages with an empty body, unsolicited CloseSequence messages, and unsolicited TerminateSequence messages) this profile adheres to and expands upon WS-RM's statement that "The SOAP version used for the CreateSequence message SHOULD be used for all subsequent messages in or for that Sequence, sent by either the RM Source or the RM Destination".
R0900 Unless otherwise specified (e.g. through some WSDL or WS-Policy designator), the RMD MUST send Sequence Lifecycle Messages destined to the CreateSequence/AcksTo EPR with the same SOAP version that was used in the CreateSequence message.TESTABLE RSP0900
Test Assertion Analysis: | RSP0900 |
---|---|
General Notes: | When passing around EPRs (that do not have embedded WSDL) it is not clear which version of SOAP should be used when talking to that EPR. This requirement tries to answer this question at least with respect to RM Acks / AcksTo EPR by requiring the RMD to use the same SOAP version that was used in the originating CS message. This means that the RMD needs to save this information, where before this was not required |
Coverage Assessment: | Good |
Target Type: | ENVELOPE |
Test Target: | A SOAP Envelope with a SeqAck Header |
Test co-Target(s): | |
Test Prerequisite: | |
Predicate: | The [target] has the same SeqID value and SOAP Envelope namespace as the previous message that contains a CreateSequence or CreateSequenceResponse. |
Prescription: | mandatory |
Reporting: | true=warning, false=passed |
Test Control: | Run a reliable request/response application message exchange. Create a sequence using a CreateSequence that includes an Offer element. This will ensure that the messages carrying the Acks in both directions are using the correct SOAP namespace. |
Test Assertion: | RSP0900 |
---|---|
Description: | This test assertion takes as prerequisite RSP8001, a "base TA" that does match any particular Rxxxx requirement, but matches fundamental requirements from RSP: namely that an Envelope is either under SOAP 1.2 or SOAP 1.1 namespace. |
Target: |
[(*:Header/wsrm:SequenceAcknowledgement/wsrm:Identifier = preceding::*:Envelope/*:Body/wsrm:CreateSequenceResponse/wsrm:Identifier) or (*:Body/wsrm:CloseSequenceResponse/wsrm:Identifier = preceding::*:Envelope/*:Body/wsrm:CreateSequenceResponse/wsrm:Identifier) or (*:Body/wsrm:TerminateSequenceResponse/wsrm:Identifier = preceding::*:Envelope/*:Body/wsrm:CreateSequenceResponse/wsrm:Identifier) or (*:Body/wsrm:CreateSequenceResponse)] |
Prerequisite: | RSP8001 |
Predicate: |
[*:Body/wsrm:CreateSequenceResponse/wsrm:Identifier = $target/*:Header/wsrm:SequenceAcknowledgement/wsrm:Identifier or (*:Body/wsrm:CreateSequenceResponse/wsrm:Identifier = $target/*:Body/wsrm:*/wsrm:Identifier)] satisfies some $cs in /wsil:testLog/wsil:messageLog/wsil:message/wsil:messageContents/*:Envelope[*:Body/wsrm:CreateSequence] satisfies (($cs/../../@conversation =
$csr/../../@conversation) or
($csr/*:Header/wsa:RelatesTo[@RelationshipType = 'http://www.w3.org/2005/08/addressing/reply' or not (@RelationshipType)] = $cs/*:Header/wsa:MessageID)) and fn:namespace-uri($target) = fn:namespace-uri($cs) |
Reporting: | true=passed, false=warning |
Prescription: | mandatory |
Error Message: | Some RM Lifecycle message related to a requested sequence (CreateSequence) was sent to the AcksTo EPR with a SOAP version different from the version used for the CreateSequence message. |
Diagnostic Data: |
|
Test Assertion Part | What it means: |
---|---|
Test Assertion ID: |
[markup: testAssertion/@id] (required) A unique ID for the current test assertion. |
Description: |
[markup: testAssertion/description ] (optional) A plain text description of the current test assertion. At minimum expressing the TA predicate. |
Comments: |
[markup: testAssertion/comments ] (optional) A plain text comment about the TA script and how well it covers the profile requirement. Explanation material for users, and developers (what could be improved, etc.). |
Target: |
[markup: testAssertion/target ] (required) The artifacts to be tested, defined by an XPath expression that returns a list of XML nodes from the log file in input. For every artifact (node) selected by the Target expression, there will be a report entry for this TA in the test report, with a result of either:
See the "reporting" item for the meaning of these results. |
Cotarget: |
[markup: testAssertion/cotarget ] (optional) Artifact that is related to the target, and that needs be accessed for the testing. Identified by an XPath expression that may refer to the related target node using the variable '$target'. For example, the target can be a SOAP message and the cotarget the WSDL file that describes this SOAP message. A cotarget must have a @name attribute that identifies it. The value of this attribute can be used as a variable (when prepending '$' to it) by subsequently defined cotargets, prerequisite and predicate. |
Prerequisite: |
[markup: testAssertion/@preReq ] (optional) [markup: testAssertion/prerequisite ] (optional) The pre-condition for evaluating this Test Assertion on this target. If the prerequisite evaluates to "false" then the target does not qualify for this Test Assertion (the test report is "notRelevant") The first part (preReq attribute) is an enumeration of Test Assertion IDs. Each one of the prerequisite TAs must either use the same target (e.g. SOAP Envelope, or WSDL binding, etc.) as this TA, or a target that is of a more general type than the main TA target. The target must "pass" each one of these prerequisite TAs in order to qualify for this TA. (e.g. the target of TA t1 can be a WSDL binding while the target of a TA t2 prerequisite of t1, can be the entire WSDL file). The second part ("prerequisite" element) is an XPath (boolean) expression of the same nature as the predicate. If present, it must evaluate to "true" for the target to qualify. If it fails, the result for the current TA in the report will be "notRelevant". Otherwise, the target can be further evaluated by the predicate of the main TA. The expression may refer to the target explicitly using the variable name "$target", or to any cotarget using its name as variable name ($[name]). |
Predicate: |
[markup: testAssertion/predicate] required element] A logical expression that evaluates whether this target is fulfilling the profile requirement addressed by this test Assertion. By default: - A result of true means the requirement is fulfilled (reported as a "passed" in the test report).- A result of false means the requirement is violated (reported as a "failed" in the test report). However, in some cases and for testability reasons, the predicate may be designed as a partial indicator e.g. only indicates some cases of fulfillment, or some cases of violation. As a result, when "true" indicates fulfillment it may be that "false" is unconclusive, or conversely "false" will indicate violation, but "true" is unconclusive. In such cases, the "Reporting" element specifies the meaning of the predicate result w/r to the profile requirement. The predicate expression implicitly refers to the target (whic is its "XPath context") although it may explicitly refer to it using the variable name "$target". It may refer to any cotarget using its name as variable name ($[name]). |
Prescription: |
[markup: testAssertion/prescription/@level ] (required) Conveys the level of prescription associated with the profile requirement. At least three values may be used:
|
Reporting: |
[markup: testAssertion/reporting ] (optional) For each possible outcome of the predicate (true or false), specifies how it must be interpreted w/r to the profile feature. Two attributes are used that both must be present, when this element is present:
NOTES: the predicate of the TA may be worded in a negative way so that @false='passed' although that is not recommended. The result of a test should not be related to the prescription level, e.g. a "preferred" or "permitted" level should not imply that @false='warning'. Other test results that are automatically generated and not controlled by the "reporting" element are:
|
R0901 Unless otherwise specified (e.g. through some WSDL or WS-Policy designator), the RMS of an Offered Sequence MUST send Sequence Lifecycle Messages destined to the CreateSequence/Offer/Endpoint EPR with the same SOAP version that was used in the CreateSequence message.TESTABLE RSP0901
Test Assertion Analysis: | RSP0901 |
---|---|
General Notes: | The possible lifecycle messages covered by this requirement are: CloseSequence and TerminateSequence. Similar to R0900, its not clear what version of SOAP should be used when sending messages to the CS/Offer/Endpoint EPR. This requirement would require an RMD to save the SOAP version of the CS and use that same version of any Close or Terminate Sequence messages sent to the CS/Offer/Endpoint EPR |
Coverage Assessment: | Good(should be able to cover all cases) |
Target Type: | ENVELOPE |
Test Target: | A CloseSequence or TerminateSequence message |
Test co-Target(s): | |
Test Prerequisite: | |
Predicate: | For any message that contains a CloseSequence or TerminateSequence element in the Body, extract the SeqID value and find (in a previous message) a CreateSequence, or CreateSequenceResponse, that references this SeqID. The namespace of the SOAP Envelope elements of these messages MUST be the same |
Prescription: | mandatory |
Reporting: | true=passed, false=failed |
Test Control: | Run a reliable request/response application message exchange. Create a sequence using a CreateSequence that includes an Offer element. To ensure the CloseSequence message is tested we could make sure there's a gap in the request sequence then have the RMS send a Close. This should cause the service to close the response sequence before it terminates it. Question: is there a RSP requirement that covers the non-Offered case? Seems like there should be but I can't find it |
Test Assertion: | RSP0901 |
---|---|
Description: | This test assertion takes as prerequisite RSP8001, a "base TA" that does match any particular Rxxxx requirement, but matches fundamental requirements from RSP: namely that an Envelope is either under SOAP 1.2 or SOAP 1.1 namespace. |
Target: |
[(*:Header/wsrm:AckRequested/wsrm:Identifier = preceding::*:Envelope/*:Body/wsrm:CreateSequence/wsrm:Offer/wsrm:Identifier) or (*:Body/wsrm:CloseSequence/wsrm:Identifier = preceding::*:Envelope/*:Body/wsrm:CreateSequence/wsrm:Offer/wsrm:Identifier) or (*:Body/wsrm:TerminateSequence/wsrm:Identifier = preceding::*:Envelope/*:Body/wsrm:CreateSequence/wsrm:Offer/wsrm:Identifier) ] |
Prerequisite: | RSP8001 |
Predicate: |
[*:Body/wsrm:CreateSequence/wsrm:Offer/wsrm:Identifier = $target/*:Header/wsrm:AckRequested/wsrm:Identifier or (*:Body/wsrm:CreateSequence/wsrm:Offer/wsrm:Identifier = $target/*:Body/wsrm:*/wsrm:Identifier)] satisfies fn:namespace-uri($target) = fn:namespace-uri($cs) |
Reporting: | true=passed, false=warning |
Prescription: | mandatory |
Error Message: | Some RM Lifecycle message related to an offered sequence (CreateSequence) was sent to the CreateSequence/Offer/Endpoint EPR with a SOAP version different from the version used for the CreateSequence message. |
Diagnostic Data: |
|
Test Assertion Part | What it means: |
---|---|
Test Assertion ID: |
[markup: testAssertion/@id] (required) A unique ID for the current test assertion. |
Description: |
[markup: testAssertion/description ] (optional) A plain text description of the current test assertion. At minimum expressing the TA predicate. |
Comments: |
[markup: testAssertion/comments ] (optional) A plain text comment about the TA script and how well it covers the profile requirement. Explanation material for users, and developers (what could be improved, etc.). |
Target: |
[markup: testAssertion/target ] (required) The artifacts to be tested, defined by an XPath expression that returns a list of XML nodes from the log file in input. For every artifact (node) selected by the Target expression, there will be a report entry for this TA in the test report, with a result of either:
See the "reporting" item for the meaning of these results. |
Cotarget: |
[markup: testAssertion/cotarget ] (optional) Artifact that is related to the target, and that needs be accessed for the testing. Identified by an XPath expression that may refer to the related target node using the variable '$target'. For example, the target can be a SOAP message and the cotarget the WSDL file that describes this SOAP message. A cotarget must have a @name attribute that identifies it. The value of this attribute can be used as a variable (when prepending '$' to it) by subsequently defined cotargets, prerequisite and predicate. |
Prerequisite: |
[markup: testAssertion/@preReq ] (optional) [markup: testAssertion/prerequisite ] (optional) The pre-condition for evaluating this Test Assertion on this target. If the prerequisite evaluates to "false" then the target does not qualify for this Test Assertion (the test report is "notRelevant") The first part (preReq attribute) is an enumeration of Test Assertion IDs. Each one of the prerequisite TAs must either use the same target (e.g. SOAP Envelope, or WSDL binding, etc.) as this TA, or a target that is of a more general type than the main TA target. The target must "pass" each one of these prerequisite TAs in order to qualify for this TA. (e.g. the target of TA t1 can be a WSDL binding while the target of a TA t2 prerequisite of t1, can be the entire WSDL file). The second part ("prerequisite" element) is an XPath (boolean) expression of the same nature as the predicate. If present, it must evaluate to "true" for the target to qualify. If it fails, the result for the current TA in the report will be "notRelevant". Otherwise, the target can be further evaluated by the predicate of the main TA. The expression may refer to the target explicitly using the variable name "$target", or to any cotarget using its name as variable name ($[name]). |
Predicate: |
[markup: testAssertion/predicate] required element] A logical expression that evaluates whether this target is fulfilling the profile requirement addressed by this test Assertion. By default: - A result of true means the requirement is fulfilled (reported as a "passed" in the test report).- A result of false means the requirement is violated (reported as a "failed" in the test report). However, in some cases and for testability reasons, the predicate may be designed as a partial indicator e.g. only indicates some cases of fulfillment, or some cases of violation. As a result, when "true" indicates fulfillment it may be that "false" is unconclusive, or conversely "false" will indicate violation, but "true" is unconclusive. In such cases, the "Reporting" element specifies the meaning of the predicate result w/r to the profile requirement. The predicate expression implicitly refers to the target (whic is its "XPath context") although it may explicitly refer to it using the variable name "$target". It may refer to any cotarget using its name as variable name ($[name]). |
Prescription: |
[markup: testAssertion/prescription/@level ] (required) Conveys the level of prescription associated with the profile requirement. At least three values may be used:
|
Reporting: |
[markup: testAssertion/reporting ] (optional) For each possible outcome of the predicate (true or false), specifies how it must be interpreted w/r to the profile feature. Two attributes are used that both must be present, when this element is present:
NOTES: the predicate of the TA may be worded in a negative way so that @false='passed' although that is not recommended. The result of a test should not be related to the prescription level, e.g. a "preferred" or "permitted" level should not imply that @false='warning'. Other test results that are automatically generated and not controlled by the "reporting" element are:
|
WS-ReliableMessaging is silent on where certain Sequence Lifecycle Messages (such as CreateSequence) should be sent.
The WS-RM specification is silent on exactly where an RMS should send a CreateSequence message to establish a Sequence. This is true for the case of a client-side RMS creating a Sequence to carry request messages as well as the case of a server-side RMS creating a Sequence to carry response messages. This is an interoperability issue because, unless the respective RMS and RMD implementations agree on the expected target for CreateSequence messages, the intended recipient may not configure the necessary infrastructure (WS-RM message handlers, etc.) and the CreateSequence message may either cause a fault or be ignored.
R0800 Baring some out of band agreement, an ENVELOPE carrying a CreateSequence message MUST be addressed to the same destination as one of the Sequence Traffic Message for that Sequence.TESTABLE RSP0800
Test Assertion Analysis: | RSP0800 |
---|---|
General Notes: | |
Coverage Assessment: | Good |
Target Type: | ENVELOPE |
Test Target: | |
Test co-Target(s): | |
Test Prerequisite: | |
Predicate: | |
Prescription: | mandatory |
Reporting: | true=passed, false=failed |
Test Control: |
Test Assertion: | RSP0800 |
---|---|
Description: | |
Target: |
[*:Body/wsrm:CreateSequence][ some $cs in . satisfies some $mycsr in /wsil:testLog/wsil:messageLog/wsil:message/wsil:messageContents/*:Envelope [*:Body/wsrm:CreateSequenceResponse/wsrm:Identifier = /wsil:testLog/wsil:messageLog/wsil:message/wsil:messageContents/*:Envelope/*:Header/wsrm:Sequence/wsrm:Identifier] satisfies ($mycsr/../../@conversation = $cs/../../@conversation) or ($mycsr/*:Header/wsa:RelatesTo[@RelationshipType = 'http://www.w3.org/2005/08/addressing/reply' or not (@RelationshipType)] = $cs/*:Header/wsa:MessageID)] |
Predicate: |
[*:Body/wsrm:CreateSequenceResponse] [(./../../@conversation = $target/../../@conversation) or (*:Header/wsa:RelatesTo[@RelationshipType = 'http://www.w3.org/2005/08/addressing/reply' or not (@RelationshipType)] = $target/*:Header/wsa:MessageID)] satisfies some $env in /wsil:testLog/wsil:messageLog/wsil:message/wsil:messageContents/*:Envelope[*:Header/wsrm:Sequence/wsrm:Identifier = $mycsr/*:Body/wsrm:CreateSequenceResponse/wsrm:Identifier] satisfies ($env/*:Header/wsa:To = $target/*:Header/wsa:To) |
Reporting: | true=passed, false=failed |
Prescription: | mandatory |
Error Message: | None of the messages sent in a reliable sequence, has been sent to the same destination endpoint as the CreateSequence message (at least one should be). |
Diagnostic Data: |
|
Test Assertion Part | What it means: |
---|---|
Test Assertion ID: |
[markup: testAssertion/@id] (required) A unique ID for the current test assertion. |
Description: |
[markup: testAssertion/description ] (optional) A plain text description of the current test assertion. At minimum expressing the TA predicate. |
Comments: |
[markup: testAssertion/comments ] (optional) A plain text comment about the TA script and how well it covers the profile requirement. Explanation material for users, and developers (what could be improved, etc.). |
Target: |
[markup: testAssertion/target ] (required) The artifacts to be tested, defined by an XPath expression that returns a list of XML nodes from the log file in input. For every artifact (node) selected by the Target expression, there will be a report entry for this TA in the test report, with a result of either:
See the "reporting" item for the meaning of these results. |
Cotarget: |
[markup: testAssertion/cotarget ] (optional) Artifact that is related to the target, and that needs be accessed for the testing. Identified by an XPath expression that may refer to the related target node using the variable '$target'. For example, the target can be a SOAP message and the cotarget the WSDL file that describes this SOAP message. A cotarget must have a @name attribute that identifies it. The value of this attribute can be used as a variable (when prepending '$' to it) by subsequently defined cotargets, prerequisite and predicate. |
Prerequisite: |
[markup: testAssertion/@preReq ] (optional) [markup: testAssertion/prerequisite ] (optional) The pre-condition for evaluating this Test Assertion on this target. If the prerequisite evaluates to "false" then the target does not qualify for this Test Assertion (the test report is "notRelevant") The first part (preReq attribute) is an enumeration of Test Assertion IDs. Each one of the prerequisite TAs must either use the same target (e.g. SOAP Envelope, or WSDL binding, etc.) as this TA, or a target that is of a more general type than the main TA target. The target must "pass" each one of these prerequisite TAs in order to qualify for this TA. (e.g. the target of TA t1 can be a WSDL binding while the target of a TA t2 prerequisite of t1, can be the entire WSDL file). The second part ("prerequisite" element) is an XPath (boolean) expression of the same nature as the predicate. If present, it must evaluate to "true" for the target to qualify. If it fails, the result for the current TA in the report will be "notRelevant". Otherwise, the target can be further evaluated by the predicate of the main TA. The expression may refer to the target explicitly using the variable name "$target", or to any cotarget using its name as variable name ($[name]). |
Predicate: |
[markup: testAssertion/predicate] required element] A logical expression that evaluates whether this target is fulfilling the profile requirement addressed by this test Assertion. By default: - A result of true means the requirement is fulfilled (reported as a "passed" in the test report).- A result of false means the requirement is violated (reported as a "failed" in the test report). However, in some cases and for testability reasons, the predicate may be designed as a partial indicator e.g. only indicates some cases of fulfillment, or some cases of violation. As a result, when "true" indicates fulfillment it may be that "false" is unconclusive, or conversely "false" will indicate violation, but "true" is unconclusive. In such cases, the "Reporting" element specifies the meaning of the predicate result w/r to the profile requirement. The predicate expression implicitly refers to the target (whic is its "XPath context") although it may explicitly refer to it using the variable name "$target". It may refer to any cotarget using its name as variable name ($[name]). |
Prescription: |
[markup: testAssertion/prescription/@level ] (required) Conveys the level of prescription associated with the profile requirement. At least three values may be used:
|
Reporting: |
[markup: testAssertion/reporting ] (optional) For each possible outcome of the predicate (true or false), specifies how it must be interpreted w/r to the profile feature. Two attributes are used that both must be present, when this element is present:
NOTES: the predicate of the TA may be worded in a negative way so that @false='passed' although that is not recommended. The result of a test should not be related to the prescription level, e.g. a "preferred" or "permitted" level should not imply that @false='warning'. Other test results that are automatically generated and not controlled by the "reporting" element are:
|
This requirement applies equally to cases in which the first Sequence Traffic Message is addressed to a URI (as may happen when the target endpoint is retrieved from a WSDL document) or to an EPR (as may happen when the target endpoint is the wsa:ReplyTo address of the corresponding request message).
The use of the Offer element within a CreateSequence message is an optional feature of WS-ReliableMessaging. Using Offer avoids the exchange of CreateSequence and CreateSequenceResponse messages to establish a new sequence for response messages. However, WS-RM does not define a mechanism by which an RMS can determine if an Offer is desired by the RMD. This creates a potential interoperability issue in cases where an RMS that either doesn't wish to use or cannot support the use of Offer attempts to create a Sequence with an RMD that requires the use of Offer. To ensure interoperability, the Offer feature must be optional for both the initiator of the Sequence (the RMS) as well as the RMD.
Conversely, when an RMS includes an Offer within a CreateSeqence and the RMD rejects that Offer (e.g. if it only has input-only operations and concludes it has no need for the offered Sequence), if the RMD indicates this choice by faulting the CreateSequence the RMS has no programmatic means of determining that the fault was due to the presence of an Offer. To ensure interoperability in these cases, the RMD, rather than faulting the CreateSequence, must instead simply not accept the offered Sequence by not including an Accept element in the CreateSequenceResponse.
R0010 An RMD MUST NOT fault a CreateSequence due to the absence of the Offer element.TESTABLE RSP0010
Test Assertion Analysis: | RSP0010 |
---|---|
General Notes: | |
Coverage Assessment: | partial |
Target Type: | |
Test Target: | |
Test co-Target(s): | |
Test Prerequisite: | |
Predicate: | No fault is sent back by the CS receiver. |
Prescription: | mandatory |
Reporting: | true=warning, false=undetermined |
Test Control: | Warning: apparent failure. Verify if the Fault has not other causes. |
Test Assertion: | RSP0010 |
---|---|
Description: | |
Target: |
*:Body/wsrm:CreateSequence[not(wsrm:Offer)]] |
co-Target: myresponse |
(@type = 'response' and @conversation = $target/../../@conversation) or (.//*:Envelope/*:Header/wsa:RelatesTo[@RelationshipType = 'http://www.w3.org/2005/08/addressing/reply' or not (@RelationshipType)] = $target/*:Header/wsa:MessageID) ] /wsil:messageContents/*:Envelope |
Predicate: |
|
Reporting: | true=passed, false=warning |
Prescription: | mandatory |
Error Message: | Warning: A wsrm:CreateSequence message was faulted. Please verify to make sure it was not faulted because of the absence of an Offer element. |
Diagnostic Data: |
|
Test Assertion Part | What it means: |
---|---|
Test Assertion ID: |
[markup: testAssertion/@id] (required) A unique ID for the current test assertion. |
Description: |
[markup: testAssertion/description ] (optional) A plain text description of the current test assertion. At minimum expressing the TA predicate. |
Comments: |
[markup: testAssertion/comments ] (optional) A plain text comment about the TA script and how well it covers the profile requirement. Explanation material for users, and developers (what could be improved, etc.). |
Target: |
[markup: testAssertion/target ] (required) The artifacts to be tested, defined by an XPath expression that returns a list of XML nodes from the log file in input. For every artifact (node) selected by the Target expression, there will be a report entry for this TA in the test report, with a result of either:
See the "reporting" item for the meaning of these results. |
Cotarget: |
[markup: testAssertion/cotarget ] (optional) Artifact that is related to the target, and that needs be accessed for the testing. Identified by an XPath expression that may refer to the related target node using the variable '$target'. For example, the target can be a SOAP message and the cotarget the WSDL file that describes this SOAP message. A cotarget must have a @name attribute that identifies it. The value of this attribute can be used as a variable (when prepending '$' to it) by subsequently defined cotargets, prerequisite and predicate. |
Prerequisite: |
[markup: testAssertion/@preReq ] (optional) [markup: testAssertion/prerequisite ] (optional) The pre-condition for evaluating this Test Assertion on this target. If the prerequisite evaluates to "false" then the target does not qualify for this Test Assertion (the test report is "notRelevant") The first part (preReq attribute) is an enumeration of Test Assertion IDs. Each one of the prerequisite TAs must either use the same target (e.g. SOAP Envelope, or WSDL binding, etc.) as this TA, or a target that is of a more general type than the main TA target. The target must "pass" each one of these prerequisite TAs in order to qualify for this TA. (e.g. the target of TA t1 can be a WSDL binding while the target of a TA t2 prerequisite of t1, can be the entire WSDL file). The second part ("prerequisite" element) is an XPath (boolean) expression of the same nature as the predicate. If present, it must evaluate to "true" for the target to qualify. If it fails, the result for the current TA in the report will be "notRelevant". Otherwise, the target can be further evaluated by the predicate of the main TA. The expression may refer to the target explicitly using the variable name "$target", or to any cotarget using its name as variable name ($[name]). |
Predicate: |
[markup: testAssertion/predicate] required element] A logical expression that evaluates whether this target is fulfilling the profile requirement addressed by this test Assertion. By default: - A result of true means the requirement is fulfilled (reported as a "passed" in the test report).- A result of false means the requirement is violated (reported as a "failed" in the test report). However, in some cases and for testability reasons, the predicate may be designed as a partial indicator e.g. only indicates some cases of fulfillment, or some cases of violation. As a result, when "true" indicates fulfillment it may be that "false" is unconclusive, or conversely "false" will indicate violation, but "true" is unconclusive. In such cases, the "Reporting" element specifies the meaning of the predicate result w/r to the profile requirement. The predicate expression implicitly refers to the target (whic is its "XPath context") although it may explicitly refer to it using the variable name "$target". It may refer to any cotarget using its name as variable name ($[name]). |
Prescription: |
[markup: testAssertion/prescription/@level ] (required) Conveys the level of prescription associated with the profile requirement. At least three values may be used:
|
Reporting: |
[markup: testAssertion/reporting ] (optional) For each possible outcome of the predicate (true or false), specifies how it must be interpreted w/r to the profile feature. Two attributes are used that both must be present, when this element is present:
NOTES: the predicate of the TA may be worded in a negative way so that @false='passed' although that is not recommended. The result of a test should not be related to the prescription level, e.g. a "preferred" or "permitted" level should not imply that @false='warning'. Other test results that are automatically generated and not controlled by the "reporting" element are:
|
R0011 An RMD MUST NOT fault a CreateSequence due to the presence of the Offer element.TESTABLE RSP0011
Test Assertion Analysis: | RSP0011 |
---|---|
General Notes: | |
Coverage Assessment: | partial |
Target Type: | |
Test Target: | |
Test co-Target(s): | |
Test Prerequisite: | |
Predicate: | No fault is sent back by the CS receiver. |
Prescription: | mandatory |
Reporting: | true=warning, false=undetermined |
Test Control: | Warning: apparent failure. Verify if the Fault has not other causes. |
Test Assertion: | RSP0011 |
---|---|
Description: | |
Target: |
|
co-Target: myresponse |
(@type = 'response' and @conversation = $target/../../@conversation) or (.//*:Envelope/*:Header/wsa:RelatesTo[not (@RelationshipType) or ( @RelationshipType = 'http://www.w3.org/2005/08/addressing/reply' ) ] = $target/*:Header/wsa:MessageID) ]/wsil:messageContents/*:Envelope |
Predicate: |
|
Reporting: | true=passed, false=warning |
Prescription: | mandatory |
Error Message: | Warning: A wsrm:CreateSequence message was faulted. Please verify to make sure it was not faulted because of the presence of an Offer element. |
Diagnostic Data: |
|
Test Assertion Part | What it means: |
---|---|
Test Assertion ID: |
[markup: testAssertion/@id] (required) A unique ID for the current test assertion. |
Description: |
[markup: testAssertion/description ] (optional) A plain text description of the current test assertion. At minimum expressing the TA predicate. |
Comments: |
[markup: testAssertion/comments ] (optional) A plain text comment about the TA script and how well it covers the profile requirement. Explanation material for users, and developers (what could be improved, etc.). |
Target: |
[markup: testAssertion/target ] (required) The artifacts to be tested, defined by an XPath expression that returns a list of XML nodes from the log file in input. For every artifact (node) selected by the Target expression, there will be a report entry for this TA in the test report, with a result of either:
See the "reporting" item for the meaning of these results. |
Cotarget: |
[markup: testAssertion/cotarget ] (optional) Artifact that is related to the target, and that needs be accessed for the testing. Identified by an XPath expression that may refer to the related target node using the variable '$target'. For example, the target can be a SOAP message and the cotarget the WSDL file that describes this SOAP message. A cotarget must have a @name attribute that identifies it. The value of this attribute can be used as a variable (when prepending '$' to it) by subsequently defined cotargets, prerequisite and predicate. |
Prerequisite: |
[markup: testAssertion/@preReq ] (optional) [markup: testAssertion/prerequisite ] (optional) The pre-condition for evaluating this Test Assertion on this target. If the prerequisite evaluates to "false" then the target does not qualify for this Test Assertion (the test report is "notRelevant") The first part (preReq attribute) is an enumeration of Test Assertion IDs. Each one of the prerequisite TAs must either use the same target (e.g. SOAP Envelope, or WSDL binding, etc.) as this TA, or a target that is of a more general type than the main TA target. The target must "pass" each one of these prerequisite TAs in order to qualify for this TA. (e.g. the target of TA t1 can be a WSDL binding while the target of a TA t2 prerequisite of t1, can be the entire WSDL file). The second part ("prerequisite" element) is an XPath (boolean) expression of the same nature as the predicate. If present, it must evaluate to "true" for the target to qualify. If it fails, the result for the current TA in the report will be "notRelevant". Otherwise, the target can be further evaluated by the predicate of the main TA. The expression may refer to the target explicitly using the variable name "$target", or to any cotarget using its name as variable name ($[name]). |
Predicate: |
[markup: testAssertion/predicate] required element] A logical expression that evaluates whether this target is fulfilling the profile requirement addressed by this test Assertion. By default: - A result of true means the requirement is fulfilled (reported as a "passed" in the test report).- A result of false means the requirement is violated (reported as a "failed" in the test report). However, in some cases and for testability reasons, the predicate may be designed as a partial indicator e.g. only indicates some cases of fulfillment, or some cases of violation. As a result, when "true" indicates fulfillment it may be that "false" is unconclusive, or conversely "false" will indicate violation, but "true" is unconclusive. In such cases, the "Reporting" element specifies the meaning of the predicate result w/r to the profile requirement. The predicate expression implicitly refers to the target (whic is its "XPath context") although it may explicitly refer to it using the variable name "$target". It may refer to any cotarget using its name as variable name ($[name]). |
Prescription: |
[markup: testAssertion/prescription/@level ] (required) Conveys the level of prescription associated with the profile requirement. At least three values may be used:
|
Reporting: |
[markup: testAssertion/reporting ] (optional) For each possible outcome of the predicate (true or false), specifies how it must be interpreted w/r to the profile feature. Two attributes are used that both must be present, when this element is present:
NOTES: the predicate of the TA may be worded in a negative way so that @false='passed' although that is not recommended. The result of a test should not be related to the prescription level, e.g. a "preferred" or "permitted" level should not imply that @false='warning'. Other test results that are automatically generated and not controlled by the "reporting" element are:
|
Under certain conditions it is possible for the
CreateSequence
or CreateSequenceResponse
messages to be lost or delayed. Depending upon the timing of the
attempts to resend such messages, it is possible to receive
duplicate CreateSequence
or
CreateSequenceResponse
messages (in fact, it is
possible to receive duplicate messages even without retries). This
creates the potential for CreateSequence
and
CreateSequenceResponse
messages that contain duplicate
Sequence Identifiers. Furthermore there are situations in which one
party (RMS or RMD) may erroneously send a
CreateSequence
or CreateSequenceResponse
message with a duplicate Sequence Identifier. Due to the crucial
role of Sequence Identifiers in the WS-RM protocol, the handling of
duplicate Sequence Identifiers needs to be further refined to
prevent interoperability problems.
Regardless of the causative circumstances, the existence of two, non-terminated Sequences with the same Identifier makes it difficult for the RMS to correctly function, therefore the RMS should take steps to prevent this condition.
R0700 The RMS MUST generate a fault when it
receives a CreateSequenceResponse
that contains a
Sequence Identifier that is the same as the Identifier of a
non-terminated Sequence.NOT_TESTABLE COM0700
Test Assertion Analysis: | COM0700 |
---|---|
General Notes: | not testable since generated faults may not be visible or if testable will never fail |
Coverage Assessment: | |
Target Type: | |
Test Target: | |
Test co-Target(s): | |
Test Prerequisite: | |
Predicate: | |
Prescription: | mandatory |
Reporting: | |
Test Control: |
Test Assertion: | COM0700 |
---|---|
Description: | |
Target: |
|
Predicate: |
|
Reporting: | true=passed, false=failed |
Prescription: | mandatory |
Error Message: | |
Diagnostic Data: |
|
Test Assertion Part | What it means: |
---|---|
Test Assertion ID: |
[markup: testAssertion/@id] (required) A unique ID for the current test assertion. |
Description: |
[markup: testAssertion/description ] (optional) A plain text description of the current test assertion. At minimum expressing the TA predicate. |
Comments: |
[markup: testAssertion/comments ] (optional) A plain text comment about the TA script and how well it covers the profile requirement. Explanation material for users, and developers (what could be improved, etc.). |
Target: |
[markup: testAssertion/target ] (required) The artifacts to be tested, defined by an XPath expression that returns a list of XML nodes from the log file in input. For every artifact (node) selected by the Target expression, there will be a report entry for this TA in the test report, with a result of either:
See the "reporting" item for the meaning of these results. |
Cotarget: |
[markup: testAssertion/cotarget ] (optional) Artifact that is related to the target, and that needs be accessed for the testing. Identified by an XPath expression that may refer to the related target node using the variable '$target'. For example, the target can be a SOAP message and the cotarget the WSDL file that describes this SOAP message. A cotarget must have a @name attribute that identifies it. The value of this attribute can be used as a variable (when prepending '$' to it) by subsequently defined cotargets, prerequisite and predicate. |
Prerequisite: |
[markup: testAssertion/@preReq ] (optional) [markup: testAssertion/prerequisite ] (optional) The pre-condition for evaluating this Test Assertion on this target. If the prerequisite evaluates to "false" then the target does not qualify for this Test Assertion (the test report is "notRelevant") The first part (preReq attribute) is an enumeration of Test Assertion IDs. Each one of the prerequisite TAs must either use the same target (e.g. SOAP Envelope, or WSDL binding, etc.) as this TA, or a target that is of a more general type than the main TA target. The target must "pass" each one of these prerequisite TAs in order to qualify for this TA. (e.g. the target of TA t1 can be a WSDL binding while the target of a TA t2 prerequisite of t1, can be the entire WSDL file). The second part ("prerequisite" element) is an XPath (boolean) expression of the same nature as the predicate. If present, it must evaluate to "true" for the target to qualify. If it fails, the result for the current TA in the report will be "notRelevant". Otherwise, the target can be further evaluated by the predicate of the main TA. The expression may refer to the target explicitly using the variable name "$target", or to any cotarget using its name as variable name ($[name]). |
Predicate: |
[markup: testAssertion/predicate] required element] A logical expression that evaluates whether this target is fulfilling the profile requirement addressed by this test Assertion. By default: - A result of true means the requirement is fulfilled (reported as a "passed" in the test report).- A result of false means the requirement is violated (reported as a "failed" in the test report). However, in some cases and for testability reasons, the predicate may be designed as a partial indicator e.g. only indicates some cases of fulfillment, or some cases of violation. As a result, when "true" indicates fulfillment it may be that "false" is unconclusive, or conversely "false" will indicate violation, but "true" is unconclusive. In such cases, the "Reporting" element specifies the meaning of the predicate result w/r to the profile requirement. The predicate expression implicitly refers to the target (whic is its "XPath context") although it may explicitly refer to it using the variable name "$target". It may refer to any cotarget using its name as variable name ($[name]). |
Prescription: |
[markup: testAssertion/prescription/@level ] (required) Conveys the level of prescription associated with the profile requirement. At least three values may be used:
|
Reporting: |
[markup: testAssertion/reporting ] (optional) For each possible outcome of the predicate (true or false), specifies how it must be interpreted w/r to the profile feature. Two attributes are used that both must be present, when this element is present:
NOTES: the predicate of the TA may be worded in a negative way so that @false='passed' although that is not recommended. The result of a test should not be related to the prescription level, e.g. a "preferred" or "permitted" level should not imply that @false='warning'. Other test results that are automatically generated and not controlled by the "reporting" element are:
|
Note that this requirement does not differentiate between duplicate Identifiers created by "the same" RMD or "different" RMDs; the simple fact that the RMS already has an active Sequence with the same Identifier is enough to trigger this requirement.
Termination of sequences must be done in a way to ensure that both the RMS and RMD share a common understanding of the final status of the sequence. The Profile places the following requirements on termination procedures:
An RMS may need to get a final sequence acknowledgment, for supporting a particular delivery assurance. This is only possible after the sequence is closed and before it is terminated. When the termination is decided by the RMD, the RMS must also be made aware of this closure so that it can request a final acknowledgement.
R0200 In the case where an RMD decides to discontinue a sequence, it MUST close the Sequence and MUST attempt to send a wsrm:CloseSequence message to the AcksTo EPR.NOT_TESTABLE COM0200
Test Assertion Analysis: | COM0200 |
---|---|
General Notes: | untestable without ESP, hard to simulate an rmd autonomous decision to discontinue a sequence hard to impossible. |
Coverage Assessment: | |
Target Type: | |
Test Target: | |
Test co-Target(s): | |
Test Prerequisite: | |
Predicate: | |
Prescription: | mandatory |
Reporting: | |
Test Control: |
Test Assertion: | COM0200 |
---|---|
Description: | |
Target: |
|
Predicate: |
|
Reporting: | true=passed, false=failed |
Prescription: | mandatory |
Error Message: | |
Diagnostic Data: |
|
Test Assertion Part | What it means: |
---|---|
Test Assertion ID: |
[markup: testAssertion/@id] (required) A unique ID for the current test assertion. |
Description: |
[markup: testAssertion/description ] (optional) A plain text description of the current test assertion. At minimum expressing the TA predicate. |
Comments: |
[markup: testAssertion/comments ] (optional) A plain text comment about the TA script and how well it covers the profile requirement. Explanation material for users, and developers (what could be improved, etc.). |
Target: |
[markup: testAssertion/target ] (required) The artifacts to be tested, defined by an XPath expression that returns a list of XML nodes from the log file in input. For every artifact (node) selected by the Target expression, there will be a report entry for this TA in the test report, with a result of either:
See the "reporting" item for the meaning of these results. |
Cotarget: |
[markup: testAssertion/cotarget ] (optional) Artifact that is related to the target, and that needs be accessed for the testing. Identified by an XPath expression that may refer to the related target node using the variable '$target'. For example, the target can be a SOAP message and the cotarget the WSDL file that describes this SOAP message. A cotarget must have a @name attribute that identifies it. The value of this attribute can be used as a variable (when prepending '$' to it) by subsequently defined cotargets, prerequisite and predicate. |
Prerequisite: |
[markup: testAssertion/@preReq ] (optional) [markup: testAssertion/prerequisite ] (optional) The pre-condition for evaluating this Test Assertion on this target. If the prerequisite evaluates to "false" then the target does not qualify for this Test Assertion (the test report is "notRelevant") The first part (preReq attribute) is an enumeration of Test Assertion IDs. Each one of the prerequisite TAs must either use the same target (e.g. SOAP Envelope, or WSDL binding, etc.) as this TA, or a target that is of a more general type than the main TA target. The target must "pass" each one of these prerequisite TAs in order to qualify for this TA. (e.g. the target of TA t1 can be a WSDL binding while the target of a TA t2 prerequisite of t1, can be the entire WSDL file). The second part ("prerequisite" element) is an XPath (boolean) expression of the same nature as the predicate. If present, it must evaluate to "true" for the target to qualify. If it fails, the result for the current TA in the report will be "notRelevant". Otherwise, the target can be further evaluated by the predicate of the main TA. The expression may refer to the target explicitly using the variable name "$target", or to any cotarget using its name as variable name ($[name]). |
Predicate: |
[markup: testAssertion/predicate] required element] A logical expression that evaluates whether this target is fulfilling the profile requirement addressed by this test Assertion. By default: - A result of true means the requirement is fulfilled (reported as a "passed" in the test report).- A result of false means the requirement is violated (reported as a "failed" in the test report). However, in some cases and for testability reasons, the predicate may be designed as a partial indicator e.g. only indicates some cases of fulfillment, or some cases of violation. As a result, when "true" indicates fulfillment it may be that "false" is unconclusive, or conversely "false" will indicate violation, but "true" is unconclusive. In such cases, the "Reporting" element specifies the meaning of the predicate result w/r to the profile requirement. The predicate expression implicitly refers to the target (whic is its "XPath context") although it may explicitly refer to it using the variable name "$target". It may refer to any cotarget using its name as variable name ($[name]). |
Prescription: |
[markup: testAssertion/prescription/@level ] (required) Conveys the level of prescription associated with the profile requirement. At least three values may be used:
|
Reporting: |
[markup: testAssertion/reporting ] (optional) For each possible outcome of the predicate (true or false), specifies how it must be interpreted w/r to the profile feature. Two attributes are used that both must be present, when this element is present:
NOTES: the predicate of the TA may be worded in a negative way so that @false='passed' although that is not recommended. The result of a test should not be related to the prescription level, e.g. a "preferred" or "permitted" level should not imply that @false='warning'. Other test results that are automatically generated and not controlled by the "reporting" element are:
|
Among other benefits, the use of Sequence Message Numbers makes an RMD aware of gaps - messages it has not received - in a sequence. For this awareness to apply to messages missing from the end of a sequence the RMD must be aware of the highest message number sent.
R0210 Any ENVELOPE from an RMS containing either a wsrm:CloseSequence or a wsrm:TerminateSequence element MUST also contain a wsrm:LastMsgNumber element if the Sequence in question contains at least one Sequence Traffic Message.TESTABLE RSP0210
Test Assertion Analysis: | RSP0210 |
---|---|
General Notes: | |
Coverage Assessment: | Good |
Target Type: | ENVELOPE (either CS or TS) |
Test Target: | For a soap:Envelope with either a wsrm:CloseSequence or a wsrm:TerminateSequence element in the soap:Body |
Test co-Target(s): | |
Test Prerequisite: | |
Predicate: | the Envelope also contains wsrm:LastMsgNumber: proposed XPath= se:Body/wsrm:*/wsrm:LastMsgNumber |
Prescription: | mandatory |
Reporting: | true=pass, false=fail |
Test Control: | Generate either a wsrm:CloseSequence message, or a wsrm:TerminateSequence |
Test Assertion: | RSP0210 |
---|---|
Description: | The soap:envelope in the message also contains a wsrm:LastMsgNumber element if it has a wsrm:CloseSequence or a wsrm:TerminateSequence element. |
Target: |
|
Predicate: |
|
Reporting: | true=passed, false=warning |
Prescription: | mandatory |
Error Message: | Warning: The soap:envelope in a wsrm:CloseSequence or a wsrm:TerminateSequence message for a non-empty RM sequence does not contain a wsrm:LastMsgNumber element. Please verify that the message was sent by the sequence destination (RMD) as the LastMsgNumber element must be present otherwise |
Diagnostic Data: |
|
Test Assertion Part | What it means: |
---|---|
Test Assertion ID: |
[markup: testAssertion/@id] (required) A unique ID for the current test assertion. |
Description: |
[markup: testAssertion/description ] (optional) A plain text description of the current test assertion. At minimum expressing the TA predicate. |
Comments: |
[markup: testAssertion/comments ] (optional) A plain text comment about the TA script and how well it covers the profile requirement. Explanation material for users, and developers (what could be improved, etc.). |
Target: |
[markup: testAssertion/target ] (required) The artifacts to be tested, defined by an XPath expression that returns a list of XML nodes from the log file in input. For every artifact (node) selected by the Target expression, there will be a report entry for this TA in the test report, with a result of either:
See the "reporting" item for the meaning of these results. |
Cotarget: |
[markup: testAssertion/cotarget ] (optional) Artifact that is related to the target, and that needs be accessed for the testing. Identified by an XPath expression that may refer to the related target node using the variable '$target'. For example, the target can be a SOAP message and the cotarget the WSDL file that describes this SOAP message. A cotarget must have a @name attribute that identifies it. The value of this attribute can be used as a variable (when prepending '$' to it) by subsequently defined cotargets, prerequisite and predicate. |
Prerequisite: |
[markup: testAssertion/@preReq ] (optional) [markup: testAssertion/prerequisite ] (optional) The pre-condition for evaluating this Test Assertion on this target. If the prerequisite evaluates to "false" then the target does not qualify for this Test Assertion (the test report is "notRelevant") The first part (preReq attribute) is an enumeration of Test Assertion IDs. Each one of the prerequisite TAs must either use the same target (e.g. SOAP Envelope, or WSDL binding, etc.) as this TA, or a target that is of a more general type than the main TA target. The target must "pass" each one of these prerequisite TAs in order to qualify for this TA. (e.g. the target of TA t1 can be a WSDL binding while the target of a TA t2 prerequisite of t1, can be the entire WSDL file). The second part ("prerequisite" element) is an XPath (boolean) expression of the same nature as the predicate. If present, it must evaluate to "true" for the target to qualify. If it fails, the result for the current TA in the report will be "notRelevant". Otherwise, the target can be further evaluated by the predicate of the main TA. The expression may refer to the target explicitly using the variable name "$target", or to any cotarget using its name as variable name ($[name]). |
Predicate: |
[markup: testAssertion/predicate] required element] A logical expression that evaluates whether this target is fulfilling the profile requirement addressed by this test Assertion. By default: - A result of true means the requirement is fulfilled (reported as a "passed" in the test report).- A result of false means the requirement is violated (reported as a "failed" in the test report). However, in some cases and for testability reasons, the predicate may be designed as a partial indicator e.g. only indicates some cases of fulfillment, or some cases of violation. As a result, when "true" indicates fulfillment it may be that "false" is unconclusive, or conversely "false" will indicate violation, but "true" is unconclusive. In such cases, the "Reporting" element specifies the meaning of the predicate result w/r to the profile requirement. The predicate expression implicitly refers to the target (whic is its "XPath context") although it may explicitly refer to it using the variable name "$target". It may refer to any cotarget using its name as variable name ($[name]). |
Prescription: |
[markup: testAssertion/prescription/@level ] (required) Conveys the level of prescription associated with the profile requirement. At least three values may be used:
|
Reporting: |
[markup: testAssertion/reporting ] (optional) For each possible outcome of the predicate (true or false), specifies how it must be interpreted w/r to the profile feature. Two attributes are used that both must be present, when this element is present:
NOTES: the predicate of the TA may be worded in a negative way so that @false='passed' although that is not recommended. The result of a test should not be related to the prescription level, e.g. a "preferred" or "permitted" level should not imply that @false='warning'. Other test results that are automatically generated and not controlled by the "reporting" element are:
|
There is a corner case for sequences in which no messages have been sent (i.e. empty sequences). In these cases it is permissable to omit wsrm:LastMsgNumber since there is no valid value for this element.
WS-ReliableMessaging is unclear about the relationship, if any, between the lifecycles of a Sequence and its corresponding Offered Sequence. Considering that such a relationship is not necessary for the proper functioning of the WS-RM protocol and that the existence of a such a relationship would create unnecessary and undesirable interdependencies between the RMS and the RMD, this profile makes the clarifying requirement that no such relationship exists.
R0220 An RM-NODE (RMD or RMS) MUST NOT assume that the termination (or closure) of a Sequence implicitly terminates (or closes) any other Sequence.NOT_TESTED
This Profile adds the following requirement to the handling of faults that are generated as the result of processing WS-RM Sequence Lifecycle messages.
The use of WS-ReliableMessaging for faults that are themselves related to the WS-RM protocol is undefined and unlikely to be interoperable. Accordingly this profile prohibits the assignment of WS-RM fault messages to a WS-RM Sequence.
R0620 An ENVELOPE that has wsrm:SequenceTerminated, wsrm:UnknownSequence, wsrm:InvalidAcknowledgement, wsrm:MessageNumberRollover, wsrm:CreateSequenceRefused, wsrm:SequenceClosed, or wsrm:WSRMRequired as the value of either the SOAP 1.2 /S:Fault/S:Code/S:Subcode/S:Value element or the /wsrm:SequenceFault/wsrm:FaultCode element MUST NOT contain a wsrm:Sequence header block.TESTABLE RSP0620a RSP0620b
Test Assertion Analysis: | RSP0620a |
---|---|
General Notes: | For SOAP11 |
Coverage Assessment: | Good |
Target Type: | ENVELOPE |
Test Target: | A SOAP Envelope in which any of the following appear: a. wsrm:SequenceTerminated b. wsrm:UnknownSequence c. wsrm:InvalidAcknowledgment d. wsrm:MessageNumberRollover e. wsrm:CreateSequenceRefused f. wsrm:SequenceClosed g. wsrm:WSRMRequired |
Test co-Target(s): | |
Test Prerequisite: | |
Predicate: | The [target] does not contain a wsrm:Sequence header. |
Prescription: | mandatory |
Reporting: | true=passed, false=failed |
Test Control: | TBD – a scenario that causes either a wsrm:SequenceTerminated or wsrm:UnknownSequence fault. |
Test Assertion: | RSP0620a |
---|---|
Description: | |
Target: |
[*:Body/*:Fault] [some $fc in *:Header/*:SequenceFault/*:FaultCode satisfies (fn:namespace-uri-for-prefix(fn:substring-before($fc,':' ) , . ) = 'http://docs.oasis-open.org/ws-rx/wsrm/200702') or ( fn:substring-after($fc,':' ) eq 'SequenceTerminated' or fn:substring-after($fc,':' ) eq 'UnknownSequence' or fn:substring-after($fc,':' ) eq 'InvalidAcknowledgment' or fn:substring-after($fc,':' ) eq 'CreateSequenceRefused' or fn:substring-after($fc,':' ) eq 'MessageNumberRollover' or fn:substring-after($fc,':' ) eq 'SequenceClosed' or fn:substring-after($fc,':' ) eq 'WSRMRequired' )] |
Predicate: |
|
Reporting: | true=passed, false=failed |
Prescription: | mandatory |
Error Message: | A SOAP11 wsrm error message contains a wsrm:Sequence header. |
Diagnostic Data: |
|
Test Assertion Part | What it means: |
---|---|
Test Assertion ID: |
[markup: testAssertion/@id] (required) A unique ID for the current test assertion. |
Description: |
[markup: testAssertion/description ] (optional) A plain text description of the current test assertion. At minimum expressing the TA predicate. |
Comments: |
[markup: testAssertion/comments ] (optional) A plain text comment about the TA script and how well it covers the profile requirement. Explanation material for users, and developers (what could be improved, etc.). |
Target: |
[markup: testAssertion/target ] (required) The artifacts to be tested, defined by an XPath expression that returns a list of XML nodes from the log file in input. For every artifact (node) selected by the Target expression, there will be a report entry for this TA in the test report, with a result of either:
See the "reporting" item for the meaning of these results. |
Cotarget: |
[markup: testAssertion/cotarget ] (optional) Artifact that is related to the target, and that needs be accessed for the testing. Identified by an XPath expression that may refer to the related target node using the variable '$target'. For example, the target can be a SOAP message and the cotarget the WSDL file that describes this SOAP message. A cotarget must have a @name attribute that identifies it. The value of this attribute can be used as a variable (when prepending '$' to it) by subsequently defined cotargets, prerequisite and predicate. |
Prerequisite: |
[markup: testAssertion/@preReq ] (optional) [markup: testAssertion/prerequisite ] (optional) The pre-condition for evaluating this Test Assertion on this target. If the prerequisite evaluates to "false" then the target does not qualify for this Test Assertion (the test report is "notRelevant") The first part (preReq attribute) is an enumeration of Test Assertion IDs. Each one of the prerequisite TAs must either use the same target (e.g. SOAP Envelope, or WSDL binding, etc.) as this TA, or a target that is of a more general type than the main TA target. The target must "pass" each one of these prerequisite TAs in order to qualify for this TA. (e.g. the target of TA t1 can be a WSDL binding while the target of a TA t2 prerequisite of t1, can be the entire WSDL file). The second part ("prerequisite" element) is an XPath (boolean) expression of the same nature as the predicate. If present, it must evaluate to "true" for the target to qualify. If it fails, the result for the current TA in the report will be "notRelevant". Otherwise, the target can be further evaluated by the predicate of the main TA. The expression may refer to the target explicitly using the variable name "$target", or to any cotarget using its name as variable name ($[name]). |
Predicate: |
[markup: testAssertion/predicate] required element] A logical expression that evaluates whether this target is fulfilling the profile requirement addressed by this test Assertion. By default: - A result of true means the requirement is fulfilled (reported as a "passed" in the test report).- A result of false means the requirement is violated (reported as a "failed" in the test report). However, in some cases and for testability reasons, the predicate may be designed as a partial indicator e.g. only indicates some cases of fulfillment, or some cases of violation. As a result, when "true" indicates fulfillment it may be that "false" is unconclusive, or conversely "false" will indicate violation, but "true" is unconclusive. In such cases, the "Reporting" element specifies the meaning of the predicate result w/r to the profile requirement. The predicate expression implicitly refers to the target (whic is its "XPath context") although it may explicitly refer to it using the variable name "$target". It may refer to any cotarget using its name as variable name ($[name]). |
Prescription: |
[markup: testAssertion/prescription/@level ] (required) Conveys the level of prescription associated with the profile requirement. At least three values may be used:
|
Reporting: |
[markup: testAssertion/reporting ] (optional) For each possible outcome of the predicate (true or false), specifies how it must be interpreted w/r to the profile feature. Two attributes are used that both must be present, when this element is present:
NOTES: the predicate of the TA may be worded in a negative way so that @false='passed' although that is not recommended. The result of a test should not be related to the prescription level, e.g. a "preferred" or "permitted" level should not imply that @false='warning'. Other test results that are automatically generated and not controlled by the "reporting" element are:
|
Test Assertion Analysis: | RSP0620b |
---|---|
General Notes: | For SOAP12 |
Coverage Assessment: | Good |
Target Type: | ENVELOPE |
Test Target: | A SOAP Envelope in which any of the following appear: a. wsrm:SequenceTerminated b. wsrm:UnknownSequence c. wsrm:InvalidAcknowledgment d. wsrm:MessageNumberRollover e. wsrm:CreateSequenceRefused f. wsrm:SequenceClosed g. wsrm:WSRMRequired |
Test co-Target(s): | |
Test Prerequisite: | |
Predicate: | The [target] does not contain a wsrm:Sequence header. |
Prescription: | mandatory |
Reporting: | true=passed, false=failed |
Test Control: | TBD – a scenario that causes either a wsrm:SequenceTerminated or wsrm:UnknownSequence fault. |
Test Assertion: | RSP0620b |
---|---|
Description: | |
Target: |
[*:Body/*:Fault] [some $fc in *:Body/*:Fault//*:Value satisfies (fn:namespace-uri-for-prefix(fn:substring-before($fc,':' ) , . ) = 'http://docs.oasis-open.org/ws-rx/wsrm/200702') or ( fn:substring-after($fc,':' ) eq 'SequenceTerminated' or fn:substring-after($fc,':' ) eq 'UnknownSequence' or fn:substring-after($fc,':' ) eq 'InvalidAcknowledgment' or fn:substring-after($fc,':' ) eq 'MessageNumberRollover' or fn:substring-after($fc,':' ) eq 'CreateSequenceRefused' or fn:substring-after($fc,':' ) eq 'SequenceClosed' or fn:substring-after($fc,':' ) eq 'WSRMRequired' )] |
Predicate: |
|
Reporting: | true=passed, false=failed |
Prescription: | mandatory |
Error Message: | A SOAP12 wsrm error message contains a wsrm:Sequence header. |
Diagnostic Data: |
|
Test Assertion Part | What it means: |
---|---|
Test Assertion ID: |
[markup: testAssertion/@id] (required) A unique ID for the current test assertion. |
Description: |
[markup: testAssertion/description ] (optional) A plain text description of the current test assertion. At minimum expressing the TA predicate. |
Comments: |
[markup: testAssertion/comments ] (optional) A plain text comment about the TA script and how well it covers the profile requirement. Explanation material for users, and developers (what could be improved, etc.). |
Target: |
[markup: testAssertion/target ] (required) The artifacts to be tested, defined by an XPath expression that returns a list of XML nodes from the log file in input. For every artifact (node) selected by the Target expression, there will be a report entry for this TA in the test report, with a result of either:
See the "reporting" item for the meaning of these results. |
Cotarget: |
[markup: testAssertion/cotarget ] (optional) Artifact that is related to the target, and that needs be accessed for the testing. Identified by an XPath expression that may refer to the related target node using the variable '$target'. For example, the target can be a SOAP message and the cotarget the WSDL file that describes this SOAP message. A cotarget must have a @name attribute that identifies it. The value of this attribute can be used as a variable (when prepending '$' to it) by subsequently defined cotargets, prerequisite and predicate. |
Prerequisite: |
[markup: testAssertion/@preReq ] (optional) [markup: testAssertion/prerequisite ] (optional) The pre-condition for evaluating this Test Assertion on this target. If the prerequisite evaluates to "false" then the target does not qualify for this Test Assertion (the test report is "notRelevant") The first part (preReq attribute) is an enumeration of Test Assertion IDs. Each one of the prerequisite TAs must either use the same target (e.g. SOAP Envelope, or WSDL binding, etc.) as this TA, or a target that is of a more general type than the main TA target. The target must "pass" each one of these prerequisite TAs in order to qualify for this TA. (e.g. the target of TA t1 can be a WSDL binding while the target of a TA t2 prerequisite of t1, can be the entire WSDL file). The second part ("prerequisite" element) is an XPath (boolean) expression of the same nature as the predicate. If present, it must evaluate to "true" for the target to qualify. If it fails, the result for the current TA in the report will be "notRelevant". Otherwise, the target can be further evaluated by the predicate of the main TA. The expression may refer to the target explicitly using the variable name "$target", or to any cotarget using its name as variable name ($[name]). |
Predicate: |
[markup: testAssertion/predicate] required element] A logical expression that evaluates whether this target is fulfilling the profile requirement addressed by this test Assertion. By default: - A result of true means the requirement is fulfilled (reported as a "passed" in the test report).- A result of false means the requirement is violated (reported as a "failed" in the test report). However, in some cases and for testability reasons, the predicate may be designed as a partial indicator e.g. only indicates some cases of fulfillment, or some cases of violation. As a result, when "true" indicates fulfillment it may be that "false" is unconclusive, or conversely "false" will indicate violation, but "true" is unconclusive. In such cases, the "Reporting" element specifies the meaning of the predicate result w/r to the profile requirement. The predicate expression implicitly refers to the target (whic is its "XPath context") although it may explicitly refer to it using the variable name "$target". It may refer to any cotarget using its name as variable name ($[name]). |
Prescription: |
[markup: testAssertion/prescription/@level ] (required) Conveys the level of prescription associated with the profile requirement. At least three values may be used:
|
Reporting: |
[markup: testAssertion/reporting ] (optional) For each possible outcome of the predicate (true or false), specifies how it must be interpreted w/r to the profile feature. Two attributes are used that both must be present, when this element is present:
NOTES: the predicate of the TA may be worded in a negative way so that @false='passed' although that is not recommended. The result of a test should not be related to the prescription level, e.g. a "preferred" or "permitted" level should not imply that @false='warning'. Other test results that are automatically generated and not controlled by the "reporting" element are:
|
WS-ReliableMessaging is silent on the mechanism for assigning messages (either request messages or response messages) to a particular Sequence. While this flexibility is beneficial from a general web services specification perspective, it creates some interoperability issues.
Given a scenario in which a consumer and a provider engage in a series of reliable request/response exchanges, it is important for the consumer and provider to have a consistent use of reliable messaging for response messages. From a reliable messaging perspective, all responses messages (both faults or non-faulting replies) are to be treated the same - meaning, either reliable messaging is enaged for both types of responses or it is turned off for both types of responses.
R0600 An INSTANCE MUST NOT differentiate between faulting responses and non-faulting responses when determining whether to use WS-ReliableMessaging for a response message.NOT_TESTED
WS-ReliableMessaging does not define the scope of an RM node other that to say that the scope is not restricted. For example, with respect to R0600 above, an Offered Sequence should be used to carry the response to any message sent over the Sequence corresponding to the CreateSequence request that included the Offer. However, it should not be assumed that the Sequence Traffic Messages carried over the Offered Sequence must be addressed to a particular response endpoint.
R0610 The scope of an RM Node is an implementation choice that MUST NOT be constrained by the remote RM-NODE. For example, the RMD MUST NOT constrain the values used by the RMS in the wsa:ReplyTo EPRs used by the RMS to be the same for all request messages (Sequence and Lifecycle messages).TESTABLE RSP0610
Test Assertion Analysis: | RSP0610 |
---|---|
General Notes: | |
Coverage Assessment: | Good |
Target Type: | ENVELOPE |
Test Target: | |
Test co-Target(s): | |
Test Prerequisite: | |
Predicate: | |
Prescription: | mandatory |
Reporting: | true=passed, false=failed |
Test Control: |
Test Assertion: | RSP0610 |
---|---|
Description: | |
Target: |
[@type = 'request' and .//*:Header/wsrm:Sequence] [some $req1 in . satisfies $req1/preceding::wsil:message[@type = 'request' and (.//*:Header/wsrm:Sequence/wsrm:Identifier = $req1//*:Header/wsrm:Sequence/wsrm:Identifier) and ( ( not(.//*:Header/wsa:ReplyTo) and $req1//*:Header/wsa:ReplyTo and not(fn:contains(xsd:string($req1//*:Header/wsa:ReplyTo[1]/wsa:Address), 'anonymous'))) or ( not($req1//*:Header/wsa:ReplyTo) and .//*:Header/wsa:ReplyTo and not(fn:contains(xsd:string(.//*:Header/wsa:ReplyTo[1]/wsa:Address), 'anonymous'))) or ( $req1//*:Header/wsa:ReplyTo and .//*:Header/wsa:ReplyTo and ( not(.//*:Header/wsa:ReplyTo/wsa:Address = $req1//*:Header/wsa:ReplyTo/wsa:Address) or not(.//*:Header/wsa:ReplyTo/wsa:ReferenceParameters = $req1//*:Header/wsa:ReplyTo/wsa:ReferenceParameters) )) ) ] ] |
co-Target: myresponse |
(@type = 'response' and @conversation = $target/@conversation) or (.//*:Envelope/*:Header/wsa:RelatesTo[@RelationshipType = 'http://www.w3.org/2005/08/addressing/reply' or not (@RelationshipType)] = $target//*:Header/wsa:MessageID) ] /wsil:messageContents/*:Envelope |
Predicate: |
|
Reporting: | true=passed, false=warning |
Prescription: | mandatory |
Error Message: | Warning: A request message sent reliably (RM) with a ReplyTo value different from a ReplyTo in preceding request message sent reliably (RM) over the same sequence, was faulted. Please verify this is not because there were two different ReplyTo values for the same sequence, as this is allowed. |
Diagnostic Data: |
|
Test Assertion Part | What it means: |
---|---|
Test Assertion ID: |
[markup: testAssertion/@id] (required) A unique ID for the current test assertion. |
Description: |
[markup: testAssertion/description ] (optional) A plain text description of the current test assertion. At minimum expressing the TA predicate. |
Comments: |
[markup: testAssertion/comments ] (optional) A plain text comment about the TA script and how well it covers the profile requirement. Explanation material for users, and developers (what could be improved, etc.). |
Target: |
[markup: testAssertion/target ] (required) The artifacts to be tested, defined by an XPath expression that returns a list of XML nodes from the log file in input. For every artifact (node) selected by the Target expression, there will be a report entry for this TA in the test report, with a result of either:
See the "reporting" item for the meaning of these results. |
Cotarget: |
[markup: testAssertion/cotarget ] (optional) Artifact that is related to the target, and that needs be accessed for the testing. Identified by an XPath expression that may refer to the related target node using the variable '$target'. For example, the target can be a SOAP message and the cotarget the WSDL file that describes this SOAP message. A cotarget must have a @name attribute that identifies it. The value of this attribute can be used as a variable (when prepending '$' to it) by subsequently defined cotargets, prerequisite and predicate. |
Prerequisite: |
[markup: testAssertion/@preReq ] (optional) [markup: testAssertion/prerequisite ] (optional) The pre-condition for evaluating this Test Assertion on this target. If the prerequisite evaluates to "false" then the target does not qualify for this Test Assertion (the test report is "notRelevant") The first part (preReq attribute) is an enumeration of Test Assertion IDs. Each one of the prerequisite TAs must either use the same target (e.g. SOAP Envelope, or WSDL binding, etc.) as this TA, or a target that is of a more general type than the main TA target. The target must "pass" each one of these prerequisite TAs in order to qualify for this TA. (e.g. the target of TA t1 can be a WSDL binding while the target of a TA t2 prerequisite of t1, can be the entire WSDL file). The second part ("prerequisite" element) is an XPath (boolean) expression of the same nature as the predicate. If present, it must evaluate to "true" for the target to qualify. If it fails, the result for the current TA in the report will be "notRelevant". Otherwise, the target can be further evaluated by the predicate of the main TA. The expression may refer to the target explicitly using the variable name "$target", or to any cotarget using its name as variable name ($[name]). |
Predicate: |
[markup: testAssertion/predicate] required element] A logical expression that evaluates whether this target is fulfilling the profile requirement addressed by this test Assertion. By default: - A result of true means the requirement is fulfilled (reported as a "passed" in the test report).- A result of false means the requirement is violated (reported as a "failed" in the test report). However, in some cases and for testability reasons, the predicate may be designed as a partial indicator e.g. only indicates some cases of fulfillment, or some cases of violation. As a result, when "true" indicates fulfillment it may be that "false" is unconclusive, or conversely "false" will indicate violation, but "true" is unconclusive. In such cases, the "Reporting" element specifies the meaning of the predicate result w/r to the profile requirement. The predicate expression implicitly refers to the target (whic is its "XPath context") although it may explicitly refer to it using the variable name "$target". It may refer to any cotarget using its name as variable name ($[name]). |
Prescription: |
[markup: testAssertion/prescription/@level ] (required) Conveys the level of prescription associated with the profile requirement. At least three values may be used:
|
Reporting: |
[markup: testAssertion/reporting ] (optional) For each possible outcome of the predicate (true or false), specifies how it must be interpreted w/r to the profile feature. Two attributes are used that both must be present, when this element is present:
NOTES: the predicate of the TA may be worded in a negative way so that @false='passed' although that is not recommended. The result of a test should not be related to the prescription level, e.g. a "preferred" or "permitted" level should not imply that @false='warning'. Other test results that are automatically generated and not controlled by the "reporting" element are:
|
Within this context the phrase "scope of an RM node" is defined as "the set of all EPRs that address a given RM node".
WS-ReliableMessaging protocol requires retransmission of messages. The Profile places the following restrictions and refinements on such retransmissions:
To ensure reliable delivery of messages within a Sequence, it is necessary for the RMS to retransmit unacknowledged messages and for the RMD to accept them.
R0101 An RMS MUST continue to retransmit unacknowledged messages until the Sequence is closed or terminated.TESTABLE RSP0101
Test Assertion Analysis: | RSP0101 |
---|---|
General Notes: | NOTE1:The TA should only apply when there is evidence of message resending. NOTE2: "continuation of resending" is hard to evaluate. |
Coverage Assessment: | Partial |
Target Type: | ENVELOPE(CS or CSR) |
Test Target: | For either a CloseSequence message or a CloseSequenceResponse message sent by RMS, and if there is evidence of resending for a message sent before this CloseSequence[Response], over this sequence. |
Test co-Target(s): | |
Test Prerequisite: | |
Predicate: | The same message is NOT resent after the CloseSequence[Response] was sent. |
Prescription: | mandatory |
Reporting: | true=passed, false=failed |
Test Control: | The RM resending parameters are set in a way that a message capture log can reflect the actual resending over time. Sequence must be closed by RMD or RMD, before the resending schedule expires. |
Test Assertion: | RSP0101 |
---|---|
Description: | |
Target: |
[*:Body/wsrm:CloseSequence or *:Body/wsrm:TerminateSequence] [some $seqid in *:Body//wsrm:Identifier satisfies some $env1 in ./preceding::*:Envelope[*:Header/wsrm:Sequence/wsrm:Identifier = $seqid] satisfies
$env1/preceding::*:Envelope[*:Header/wsrm:Sequence/wsrm:Identifier
= $seqid and *:Header/wsrm:Sequence/wsrm:MessageNumber =
$env1/*:Header/wsrm:Sequence/wsrm:MessageNumber ]
] |
Predicate: |
some $seqid in ./*:Body//wsrm:Identifier satisfies (some $env1 in ./preceding::*:Envelope[*:Header/wsrm:Sequence/wsrm:Identifier = $seqid ] satisfies
(./following::*:Envelope[*:Header/wsrm:Sequence/wsrm:Identifier =
$seqid and
)*:Header/wsrm:Sequence/wsrm:MessageNumber = $env1/*:Header/wsrm:Sequence/wsrm:MessageNumber ])) |
Reporting: | true=passed, false=failed |
Prescription: | mandatory |
Error Message: | A CloseSequence message or a TerminateSequence message was sent by RMS for a sequence that contains messages that have been resent. But the resending has not stopped after these terminating messages have been logged. |
Diagnostic Data: |
|
Test Assertion Part | What it means: |
---|---|
Test Assertion ID: |
[markup: testAssertion/@id] (required) A unique ID for the current test assertion. |
Description: |
[markup: testAssertion/description ] (optional) A plain text description of the current test assertion. At minimum expressing the TA predicate. |
Comments: |
[markup: testAssertion/comments ] (optional) A plain text comment about the TA script and how well it covers the profile requirement. Explanation material for users, and developers (what could be improved, etc.). |
Target: |
[markup: testAssertion/target ] (required) The artifacts to be tested, defined by an XPath expression that returns a list of XML nodes from the log file in input. For every artifact (node) selected by the Target expression, there will be a report entry for this TA in the test report, with a result of either:
See the "reporting" item for the meaning of these results. |
Cotarget: |
[markup: testAssertion/cotarget ] (optional) Artifact that is related to the target, and that needs be accessed for the testing. Identified by an XPath expression that may refer to the related target node using the variable '$target'. For example, the target can be a SOAP message and the cotarget the WSDL file that describes this SOAP message. A cotarget must have a @name attribute that identifies it. The value of this attribute can be used as a variable (when prepending '$' to it) by subsequently defined cotargets, prerequisite and predicate. |
Prerequisite: |
[markup: testAssertion/@preReq ] (optional) [markup: testAssertion/prerequisite ] (optional) The pre-condition for evaluating this Test Assertion on this target. If the prerequisite evaluates to "false" then the target does not qualify for this Test Assertion (the test report is "notRelevant") The first part (preReq attribute) is an enumeration of Test Assertion IDs. Each one of the prerequisite TAs must either use the same target (e.g. SOAP Envelope, or WSDL binding, etc.) as this TA, or a target that is of a more general type than the main TA target. The target must "pass" each one of these prerequisite TAs in order to qualify for this TA. (e.g. the target of TA t1 can be a WSDL binding while the target of a TA t2 prerequisite of t1, can be the entire WSDL file). The second part ("prerequisite" element) is an XPath (boolean) expression of the same nature as the predicate. If present, it must evaluate to "true" for the target to qualify. If it fails, the result for the current TA in the report will be "notRelevant". Otherwise, the target can be further evaluated by the predicate of the main TA. The expression may refer to the target explicitly using the variable name "$target", or to any cotarget using its name as variable name ($[name]). |
Predicate: |
[markup: testAssertion/predicate] required element] A logical expression that evaluates whether this target is fulfilling the profile requirement addressed by this test Assertion. By default: - A result of true means the requirement is fulfilled (reported as a "passed" in the test report).- A result of false means the requirement is violated (reported as a "failed" in the test report). However, in some cases and for testability reasons, the predicate may be designed as a partial indicator e.g. only indicates some cases of fulfillment, or some cases of violation. As a result, when "true" indicates fulfillment it may be that "false" is unconclusive, or conversely "false" will indicate violation, but "true" is unconclusive. In such cases, the "Reporting" element specifies the meaning of the predicate result w/r to the profile requirement. The predicate expression implicitly refers to the target (whic is its "XPath context") although it may explicitly refer to it using the variable name "$target". It may refer to any cotarget using its name as variable name ($[name]). |
Prescription: |
[markup: testAssertion/prescription/@level ] (required) Conveys the level of prescription associated with the profile requirement. At least three values may be used:
|
Reporting: |
[markup: testAssertion/reporting ] (optional) For each possible outcome of the predicate (true or false), specifies how it must be interpreted w/r to the profile feature. Two attributes are used that both must be present, when this element is present:
NOTES: the predicate of the TA may be worded in a negative way so that @false='passed' although that is not recommended. The result of a test should not be related to the prescription level, e.g. a "preferred" or "permitted" level should not imply that @false='warning'. Other test results that are automatically generated and not controlled by the "reporting" element are:
|
R0102 An RMD MUST accept unacknowledged messages until the Sequence is closed or terminated.TESTABLE RSP0102
Test Assertion Analysis: | RSP0102 |
---|---|
General Notes: | NOTE1: a message should be intercepted, causing a gap in the Ack ranges. Regardless of how long the delay before resending , the message must finally be acknowledged if sequence not closed. |
Coverage Assessment: | Good |
Target Type: | ENVELOPE(with RM header) |
Test Target: | For a message that is a resend, in a RM sequence that is not closed or terminated yet. |
Test co-Target(s): | |
Test Prerequisite: | |
Predicate: | The message is not faulted by the RMD, AND the next acknowledgement shows it has been acknowledged. |
Prescription: | mandatory |
Reporting: | (default) |
Test Control: | MIM to block messages, to cause significant delay in resending. |
Test Assertion: | RSP0102 |
---|---|
Description: | |
Target: |
[*:Header/wsrm:Sequence = preceding::*:Envelope/*:Header/wsrm:Sequence] [some $tgenv in . satisfies not( some $clseq in
$tgenv/preceding::*:Envelope[*:Body/wsrm:CloseSequence or
*:Body/wsrm:TerminateSequence ] satisfies
]$clseq/*:Body//wsrm:Identifier = $tgenv/*:Header/wsrm:Sequence/wsrm:Identifier ) |
Predicate: |
some $ackrange in $env/*:Header/wsrm:SequenceAcknowledgement/wsrm:AcknowledgementRange satisfies ($ackrange/@Lower le
$target/*:Header/wsrm:Sequence/wsrm:MessageNumber and
$ackrange/@Upper ge $target/*:Header/wsrm:Sequence/wsrm:MessageNumber) ) and not (/wsil:testLog/wsil:messageLog/wsil:message[ (@type = 'response' and @conversation = $target/../../@conversation) or (.//*:Envelope/*:Header/wsa:RelatesTo[not (@RelationshipType) or ( @RelationshipType = 'http://www.w3.org/2005/08/addressing/reply' ) ] = $target/*:Header/wsa:MessageID)] /wsil:messageContents/*:Envelope/*:Body/*:Fault ) |
Reporting: | true=passed, false=warning |
Prescription: | mandatory |
Error Message: | Warning: One of these two conditions occurred: (a) A resent message (reliable messaging) was not acknowledged before the closing/termination of the RM sequence, or (b) the resent message was faulted. In both cases, this could be a sign that the receiving RMD did not accept the resent message: to investigate further. |
Diagnostic Data: |
|
Test Assertion Part | What it means: |
---|---|
Test Assertion ID: |
[markup: testAssertion/@id] (required) A unique ID for the current test assertion. |
Description: |
[markup: testAssertion/description ] (optional) A plain text description of the current test assertion. At minimum expressing the TA predicate. |
Comments: |
[markup: testAssertion/comments ] (optional) A plain text comment about the TA script and how well it covers the profile requirement. Explanation material for users, and developers (what could be improved, etc.). |
Target: |
[markup: testAssertion/target ] (required) The artifacts to be tested, defined by an XPath expression that returns a list of XML nodes from the log file in input. For every artifact (node) selected by the Target expression, there will be a report entry for this TA in the test report, with a result of either:
See the "reporting" item for the meaning of these results. |
Cotarget: |
[markup: testAssertion/cotarget ] (optional) Artifact that is related to the target, and that needs be accessed for the testing. Identified by an XPath expression that may refer to the related target node using the variable '$target'. For example, the target can be a SOAP message and the cotarget the WSDL file that describes this SOAP message. A cotarget must have a @name attribute that identifies it. The value of this attribute can be used as a variable (when prepending '$' to it) by subsequently defined cotargets, prerequisite and predicate. |
Prerequisite: |
[markup: testAssertion/@preReq ] (optional) [markup: testAssertion/prerequisite ] (optional) The pre-condition for evaluating this Test Assertion on this target. If the prerequisite evaluates to "false" then the target does not qualify for this Test Assertion (the test report is "notRelevant") The first part (preReq attribute) is an enumeration of Test Assertion IDs. Each one of the prerequisite TAs must either use the same target (e.g. SOAP Envelope, or WSDL binding, etc.) as this TA, or a target that is of a more general type than the main TA target. The target must "pass" each one of these prerequisite TAs in order to qualify for this TA. (e.g. the target of TA t1 can be a WSDL binding while the target of a TA t2 prerequisite of t1, can be the entire WSDL file). The second part ("prerequisite" element) is an XPath (boolean) expression of the same nature as the predicate. If present, it must evaluate to "true" for the target to qualify. If it fails, the result for the current TA in the report will be "notRelevant". Otherwise, the target can be further evaluated by the predicate of the main TA. The expression may refer to the target explicitly using the variable name "$target", or to any cotarget using its name as variable name ($[name]). |
Predicate: |
[markup: testAssertion/predicate] required element] A logical expression that evaluates whether this target is fulfilling the profile requirement addressed by this test Assertion. By default: - A result of true means the requirement is fulfilled (reported as a "passed" in the test report).- A result of false means the requirement is violated (reported as a "failed" in the test report). However, in some cases and for testability reasons, the predicate may be designed as a partial indicator e.g. only indicates some cases of fulfillment, or some cases of violation. As a result, when "true" indicates fulfillment it may be that "false" is unconclusive, or conversely "false" will indicate violation, but "true" is unconclusive. In such cases, the "Reporting" element specifies the meaning of the predicate result w/r to the profile requirement. The predicate expression implicitly refers to the target (whic is its "XPath context") although it may explicitly refer to it using the variable name "$target". It may refer to any cotarget using its name as variable name ($[name]). |
Prescription: |
[markup: testAssertion/prescription/@level ] (required) Conveys the level of prescription associated with the profile requirement. At least three values may be used:
|
Reporting: |
[markup: testAssertion/reporting ] (optional) For each possible outcome of the predicate (true or false), specifies how it must be interpreted w/r to the profile feature. Two attributes are used that both must be present, when this element is present:
NOTES: the predicate of the TA may be worded in a negative way so that @false='passed' although that is not recommended. The result of a test should not be related to the prescription level, e.g. a "preferred" or "permitted" level should not imply that @false='warning'. Other test results that are automatically generated and not controlled by the "reporting" element are:
|
Note: there are cases where it may be obvious that retransmitting a message is unlikey to result in an outcome that is any different from the previous, failed transmission(s). For example, in the case of HTTP, a 401 status code may indicate that access to an endpoint has been refused for the credentials that accompanied the request. Unless some action is taken to grant access to those credentials, retransmitting the request is likely to result in the same error and may cause negative side-effects such as the locking of an account due to "excessive failed login attempts".
WS-ReliableMessaging Section 2.1 defines the messages that affect the created/closing/closed/terminating state of a Sequence as "Sequence Lifecycle Messages". WS-RM is silent on what a SENDER (RMS or RMD) is expected to do when it either fails to send one of the messages or does not receive the corresponding response message (e.g. an RMS sends a CreateSequence message but does not receive a CreateSequenceResponse message).
R0110 When a SENDER fails to successfully send a Sequence Lifecycle Message or it does not receive the corresponding response message (if one exists), it is RECOMMENDED that the SENDER attempt to resend the message. The frequency and number of these retries are implementation dependent.NOT_TESTED
In cases where wsa:MessageID
is being used,
retransmission must not alter its value, because other headers
(possibly occuring in other messages - such as
wsa:RelatesTo
) may rely on it for message
correlation.
R0120 For any two ENVELOPES that contain WS-RM Sequence headers in which the value of their wsrm:Identifier and wsrm:MessageNumber elements are equal, it MUST be true that neither of the envelopes contains a wsa:MessageID or that both messages contain a wsa:MessageID and the value of the wsa:MessageID elements are equal.TESTABLE RSP0120
Test Assertion Analysis: | RSP0120 |
---|---|
General Notes: | |
Coverage Assessment: | Good |
Target Type: | ENVELOPE (with RM header) |
Test Target: | For any envelope with RM header, for which there exists at least one preceeding envelope in the log with RM header featuring same wsrm:Identifier and wsrm:MessageNumber elements, |
Test co-Target(s): | |
Test Prerequisite: | |
Predicate: | either the target envelope has no wsa:MessageID and every sibling envelope does not have one, or the target envelope has wsa:MessageID and every sibling envelope has the same. |
Prescription: | mandatory |
Reporting: | (default: true=pass, false=fail) |
Test Control: | MIM config: Generate message resending - e.g. by blocking Acks, or blocking the regular messages. |
Test Assertion: | RSP0120 |
---|---|
Description: | |
Target: |
*:Header/wsrm:Sequence = preceding::*:Envelope/*:Header/wsrm:Sequence] |
Predicate: |
every $prevenv in preceding::*:Envelope[*:Header/wsrm:Sequence = $curenv/*:Header/wsrm:Sequence] satisfies ((not($prevenv/*:Header/wsa:MessageID) and not($curenv/*:Header/wsa:MessageID)) or $prevenv/*:Header/wsa:MessageID = $curenv/*:Header/wsa:MessageID ) |
Reporting: | true=passed, false=failed |
Prescription: | mandatory |
Error Message: | A message has been resent (by an RMS), yet it had an wsa:MessageId different from the previous sending, or the wsa:MessageId header was present in one but not in the other. |
Diagnostic Data: |
|
Test Assertion Part | What it means: |
---|---|
Test Assertion ID: |
[markup: testAssertion/@id] (required) A unique ID for the current test assertion. |
Description: |
[markup: testAssertion/description ] (optional) A plain text description of the current test assertion. At minimum expressing the TA predicate. |
Comments: |
[markup: testAssertion/comments ] (optional) A plain text comment about the TA script and how well it covers the profile requirement. Explanation material for users, and developers (what could be improved, etc.). |
Target: |
[markup: testAssertion/target ] (required) The artifacts to be tested, defined by an XPath expression that returns a list of XML nodes from the log file in input. For every artifact (node) selected by the Target expression, there will be a report entry for this TA in the test report, with a result of either:
See the "reporting" item for the meaning of these results. |
Cotarget: |
[markup: testAssertion/cotarget ] (optional) Artifact that is related to the target, and that needs be accessed for the testing. Identified by an XPath expression that may refer to the related target node using the variable '$target'. For example, the target can be a SOAP message and the cotarget the WSDL file that describes this SOAP message. A cotarget must have a @name attribute that identifies it. The value of this attribute can be used as a variable (when prepending '$' to it) by subsequently defined cotargets, prerequisite and predicate. |
Prerequisite: |
[markup: testAssertion/@preReq ] (optional) [markup: testAssertion/prerequisite ] (optional) The pre-condition for evaluating this Test Assertion on this target. If the prerequisite evaluates to "false" then the target does not qualify for this Test Assertion (the test report is "notRelevant") The first part (preReq attribute) is an enumeration of Test Assertion IDs. Each one of the prerequisite TAs must either use the same target (e.g. SOAP Envelope, or WSDL binding, etc.) as this TA, or a target that is of a more general type than the main TA target. The target must "pass" each one of these prerequisite TAs in order to qualify for this TA. (e.g. the target of TA t1 can be a WSDL binding while the target of a TA t2 prerequisite of t1, can be the entire WSDL file). The second part ("prerequisite" element) is an XPath (boolean) expression of the same nature as the predicate. If present, it must evaluate to "true" for the target to qualify. If it fails, the result for the current TA in the report will be "notRelevant". Otherwise, the target can be further evaluated by the predicate of the main TA. The expression may refer to the target explicitly using the variable name "$target", or to any cotarget using its name as variable name ($[name]). |
Predicate: |
[markup: testAssertion/predicate] required element] A logical expression that evaluates whether this target is fulfilling the profile requirement addressed by this test Assertion. By default: - A result of true means the requirement is fulfilled (reported as a "passed" in the test report).- A result of false means the requirement is violated (reported as a "failed" in the test report). However, in some cases and for testability reasons, the predicate may be designed as a partial indicator e.g. only indicates some cases of fulfillment, or some cases of violation. As a result, when "true" indicates fulfillment it may be that "false" is unconclusive, or conversely "false" will indicate violation, but "true" is unconclusive. In such cases, the "Reporting" element specifies the meaning of the predicate result w/r to the profile requirement. The predicate expression implicitly refers to the target (whic is its "XPath context") although it may explicitly refer to it using the variable name "$target". It may refer to any cotarget using its name as variable name ($[name]). |
Prescription: |
[markup: testAssertion/prescription/@level ] (required) Conveys the level of prescription associated with the profile requirement. At least three values may be used:
|
Reporting: |
[markup: testAssertion/reporting ] (optional) For each possible outcome of the predicate (true or false), specifies how it must be interpreted w/r to the profile feature. Two attributes are used that both must be present, when this element is present:
NOTES: the predicate of the TA may be worded in a negative way so that @false='passed' although that is not recommended. The result of a test should not be related to the prescription level, e.g. a "preferred" or "permitted" level should not imply that @false='warning'. Other test results that are automatically generated and not controlled by the "reporting" element are:
|
WS-ReliableMessaging allows for the addition of some WS-RM-defined headers to messages that are targeted to the same endpoint to which those headers are to be sent; a concept it refers to as "piggybacking". There are a number of interoperability issues with the practice of piggybacking.
Because there is no standard mechanism for comparing EPRs, it is possible for different implementations to have dissimilar assumptions about which messages are and are not valid carriers for piggybacked SequenceAcknowledgement headers. For example, an implementation of the RMS may assume that the ReferenceParameters (if any) of the EPRs will be compared as part of the determination of whether a message is targeted to "the same" endpoint as the AcksTo endpoint. Meanwhile an implementation of the RMD may assume that a simple comparison of the Address IRIs is sufficient for making this determination. This creates the possibility for misdirected, dropped, and otherwise lost acknowledgements to the detriment and possible malfunctioning of the WS-RM protocol.
R0500 An RMD MUST NOT piggyback a wsrm:SequenceAcknowledgement Header onto another message in cases where the destination property of the carrier message contains a wsa:Address IRI that differs (based on a simple string comparison) from the wsa:Address IRI of the wsm:AcksTo EPR corresponding to the wsrm:SequenceAcknowledgement.TESTABLE RSP0500
Test Assertion Analysis: | RSP0500 |
---|---|
General Notes: | |
Coverage Assessment: | Good |
Target Type: | ENVELOPE |
Test Target: | |
Test co-Target(s): | |
Test Prerequisite: | |
Predicate: | |
Prescription: | mandatory |
Reporting: | true=pass, false=fail |
Test Control: |
Test Assertion: | RSP0500 |
---|---|
Description: | Case non-encrypted CS/CSR. Ack is sent back over a message with non-empty Body, and with wsa:To header. Then the AcksTo address value for this sequence must be same as the wsa:To address. |
Target: |
[ *:Header[wsrm:SequenceAcknowledgement and not(*:Header/wsse:Security//xenc:ReferenceList) and wsa:To] and *:Body[node() and not(*:Fault) and not(wsrm:*)]] [ some $tgt in . satisfies some $csr in /wsil:testLog/wsil:messageLog/wsil:message//*:Envelope[*:Body/wsrm:CreateSequenceResponse][$tgt/*:Header/wsrm:SequenceAcknowledgement/wsrm:Identifier = *:Body/wsrm:CreateSequenceResponse/wsrm:Identifier] satisfies some $cs in /wsil:testLog/wsil:messageLog/wsil:message/wsil:messageContents/*:Envelope[*:Body/wsrm:CreateSequence] satisfies ($csr/../../@conversation = $cs/../../@conversation or $csr/*:Header/wsa:RelatesTo[@RelationshipType = 'http://www.w3.org/2005/08/addressing/reply' or not (@RelationshipType)] = $cs/*:Header/wsa:MessageID)] |
co-Target: mycreateseq |
|
Predicate: |
|
Reporting: | true=passed, false=failed |
Prescription: | mandatory |
Error Message: | A wsrm:SequenceAcknowledgement piggybacked on a message (with non-empty body) was sent to a destination (wsa:To) that has an address different from the wsrm:AcksTo value associated with this RM sequence. |
Diagnostic Data: |
|
Test Assertion Part | What it means: |
---|---|
Test Assertion ID: |
[markup: testAssertion/@id] (required) A unique ID for the current test assertion. |
Description: |
[markup: testAssertion/description ] (optional) A plain text description of the current test assertion. At minimum expressing the TA predicate. |
Comments: |
[markup: testAssertion/comments ] (optional) A plain text comment about the TA script and how well it covers the profile requirement. Explanation material for users, and developers (what could be improved, etc.). |
Target: |
[markup: testAssertion/target ] (required) The artifacts to be tested, defined by an XPath expression that returns a list of XML nodes from the log file in input. For every artifact (node) selected by the Target expression, there will be a report entry for this TA in the test report, with a result of either:
See the "reporting" item for the meaning of these results. |
Cotarget: |
[markup: testAssertion/cotarget ] (optional) Artifact that is related to the target, and that needs be accessed for the testing. Identified by an XPath expression that may refer to the related target node using the variable '$target'. For example, the target can be a SOAP message and the cotarget the WSDL file that describes this SOAP message. A cotarget must have a @name attribute that identifies it. The value of this attribute can be used as a variable (when prepending '$' to it) by subsequently defined cotargets, prerequisite and predicate. |
Prerequisite: |
[markup: testAssertion/@preReq ] (optional) [markup: testAssertion/prerequisite ] (optional) The pre-condition for evaluating this Test Assertion on this target. If the prerequisite evaluates to "false" then the target does not qualify for this Test Assertion (the test report is "notRelevant") The first part (preReq attribute) is an enumeration of Test Assertion IDs. Each one of the prerequisite TAs must either use the same target (e.g. SOAP Envelope, or WSDL binding, etc.) as this TA, or a target that is of a more general type than the main TA target. The target must "pass" each one of these prerequisite TAs in order to qualify for this TA. (e.g. the target of TA t1 can be a WSDL binding while the target of a TA t2 prerequisite of t1, can be the entire WSDL file). The second part ("prerequisite" element) is an XPath (boolean) expression of the same nature as the predicate. If present, it must evaluate to "true" for the target to qualify. If it fails, the result for the current TA in the report will be "notRelevant". Otherwise, the target can be further evaluated by the predicate of the main TA. The expression may refer to the target explicitly using the variable name "$target", or to any cotarget using its name as variable name ($[name]). |
Predicate: |
[markup: testAssertion/predicate] required element] A logical expression that evaluates whether this target is fulfilling the profile requirement addressed by this test Assertion. By default: - A result of true means the requirement is fulfilled (reported as a "passed" in the test report).- A result of false means the requirement is violated (reported as a "failed" in the test report). However, in some cases and for testability reasons, the predicate may be designed as a partial indicator e.g. only indicates some cases of fulfillment, or some cases of violation. As a result, when "true" indicates fulfillment it may be that "false" is unconclusive, or conversely "false" will indicate violation, but "true" is unconclusive. In such cases, the "Reporting" element specifies the meaning of the predicate result w/r to the profile requirement. The predicate expression implicitly refers to the target (whic is its "XPath context") although it may explicitly refer to it using the variable name "$target". It may refer to any cotarget using its name as variable name ($[name]). |
Prescription: |
[markup: testAssertion/prescription/@level ] (required) Conveys the level of prescription associated with the profile requirement. At least three values may be used:
|
Reporting: |
[markup: testAssertion/reporting ] (optional) For each possible outcome of the predicate (true or false), specifies how it must be interpreted w/r to the profile feature. Two attributes are used that both must be present, when this element is present:
NOTES: the predicate of the TA may be worded in a negative way so that @false='passed' although that is not recommended. The result of a test should not be related to the prescription level, e.g. a "preferred" or "permitted" level should not imply that @false='warning'. Other test results that are automatically generated and not controlled by the "reporting" element are:
|
R0501 In cases where the AcksTo EPR of a Sequence has an Address value equal to the WS-Addressing 1.0 Anonymous URI, the RMD MUST also limit piggybacking as described in section 3.9 of the WS-ReliableMessaging specification.TESTABLE RSP0501
Test Assertion Analysis: | RSP0501 |
---|---|
General Notes: | Section 3.9 of WS-RM says that, when AcksTo is anonymous, the only way to transmit acknowledgments is over the back-channel created by an STM that is within the sequence to which the ack applies. The text in WS-RM applies to all acknowledgements. This requirement highlights piggybacked acknowledgments as a special case of this general rule. Crafting an assertion that checks for violation of this requirement should be fairly straightforward. However, to have any meaningful coverage, we need test scenarios that create an environment capable of stimulating the incorrect behavior. Essentially we need scenarios in which a single client/RMS creates two or more sequences with a single server/RMS using anonymous AcksTos in all the sequences and sends a either a series of one-way message or a series of request-response messages. To keep things simple, this later variation should not include reliability for the response messages |
Coverage Assessment: | Partial (piggybacking difficult to stimulate). |
Target Type: | ENVELOPE |
Test Target: | A SOAP Envelope in which: a. One or more SequenceAcknowledgment headers appear. b. The Body is not empty. c. The value of wsa:To is http://www.w3.org/2005/08/addressing/anonymous or in which wsa:To is absent. d. Transmitted in the body of an HTTP Response. |
Test co-Target(s): | |
Test Prerequisite: | |
Predicate: | The value of each /wsrm:SequenceAcknowledgment/wsrm:Identifier element in the [target] matches the value of the /wsrm:Sequence/wsrm:Identifier in the message contained in the corresponding HTTP Request. |
Prescription: | mandatory |
Reporting: | |
Test Control: | Scenario: x.x.x Reliable_One_Way_Requests_Anon_AcksTo_Multiple_Sequences The client creates two sequences to the service in the identical way; the CreateSequence message contains an anonymous AcksTo and there is no Offer. The service supports a one-way message. The client reliably sends a number of messages to the service, alternating the sequence for each message. Scenario: x.x.x Reliable_Requests_Unreliable_Response_Anon_AcksTo_Multiple_Sequences The client creates two sequences to the service in the identical way; the CreateSequence message contains an anonymous AcksTo and there is no Offer. The service is configured to support reliable-request/non-reliable response. The client reliably sends a number of messages to the service, alternating the sequence for each message. |
Test Assertion: | RSP0501 |
---|---|
Description: | |
Target: |
[*:Header/wsrm:SequenceAcknowledgement and (some $tgt in . satisfies some $cs in /wsil:testLog/wsil:messageLog/wsil:message/wsil:messageContents/*:Envelope[*:Body/wsrm:CreateSequence/wsrm:AcksTo/wsa:Address = 'http://www.w3.org/2005/08/addressing/anonymous'] satisfies (some $csr in /wsil:testLog/wsil:messageLog/wsil:message/wsil:messageContents/*:Envelope[*:Body/wsrm:CreateSequenceResponse] satisfies ($tgt/*:Header/wsrm:SequenceAcknowledgement/wsrm:Identifier = $csr/*:Body/wsrm:CreateSequenceResponse/wsrm:Identifier and ($csr/../../@conversation = $cs/../../@conversation or $csr/*:Header/wsa:RelatesTo[@RelationshipType = 'http://www.w3.org/2005/08/addressing/reply' or not (@RelationshipType)] = $cs/*:Header/wsa:MessageID)))) ] |
co-Target: myRequestMsg |
[@type = 'request' and (@conversation = $target/../../@conversation or .//*:Header/wsa:MessageID = $target//wsa:RelatesTo[@RelationshipType = 'http://www.w3.org/2005/08/addressing/reply' or not (@RelationshipType)]) ] |
Prerequisite: |
|
Predicate: |
($seqack/wsrm:Identifier = $myRequestMsg//*:Envelope/*:Header/wsrm:Sequence/wsrm:Identifier)) or ($target/*:Body/wsrm:TerminateSequenceResponse/wsrm:Identifier = $myRequestMsg//*:Envelope/*:Body/wsrm:TerminateSequence/wsrm:Identifier) or ($target/*:Body/wsrm:CloseSequenceResponse/wsrm:Identifier = $myRequestMsg//*:Envelope/*:Body/wsrm:CloseSequence/wsrm:Identifier)) and ($target/*:Header/wsa:To = 'http://www.w3.org/2005/08/addressing/anonymous' or not($target/*:Header/wsa:To) ) |
Reporting: | true=passed, false=failed |
Prescription: | mandatory |
Error Message: | A sequence acknowledgement message related to an RM Sequence defined with an AcksTo element set to wsa:AnonymousURI, was either sent back over an HTTP request, or was sent as a response to an HTTP request that did not carry a message sent reliably over the same RM Sequence. |
Diagnostic Data: |
|
Test Assertion Part | What it means: |
---|---|
Test Assertion ID: |
[markup: testAssertion/@id] (required) A unique ID for the current test assertion. |
Description: |
[markup: testAssertion/description ] (optional) A plain text description of the current test assertion. At minimum expressing the TA predicate. |
Comments: |
[markup: testAssertion/comments ] (optional) A plain text comment about the TA script and how well it covers the profile requirement. Explanation material for users, and developers (what could be improved, etc.). |
Target: |
[markup: testAssertion/target ] (required) The artifacts to be tested, defined by an XPath expression that returns a list of XML nodes from the log file in input. For every artifact (node) selected by the Target expression, there will be a report entry for this TA in the test report, with a result of either:
See the "reporting" item for the meaning of these results. |
Cotarget: |
[markup: testAssertion/cotarget ] (optional) Artifact that is related to the target, and that needs be accessed for the testing. Identified by an XPath expression that may refer to the related target node using the variable '$target'. For example, the target can be a SOAP message and the cotarget the WSDL file that describes this SOAP message. A cotarget must have a @name attribute that identifies it. The value of this attribute can be used as a variable (when prepending '$' to it) by subsequently defined cotargets, prerequisite and predicate. |
Prerequisite: |
[markup: testAssertion/@preReq ] (optional) [markup: testAssertion/prerequisite ] (optional) The pre-condition for evaluating this Test Assertion on this target. If the prerequisite evaluates to "false" then the target does not qualify for this Test Assertion (the test report is "notRelevant") The first part (preReq attribute) is an enumeration of Test Assertion IDs. Each one of the prerequisite TAs must either use the same target (e.g. SOAP Envelope, or WSDL binding, etc.) as this TA, or a target that is of a more general type than the main TA target. The target must "pass" each one of these prerequisite TAs in order to qualify for this TA. (e.g. the target of TA t1 can be a WSDL binding while the target of a TA t2 prerequisite of t1, can be the entire WSDL file). The second part ("prerequisite" element) is an XPath (boolean) expression of the same nature as the predicate. If present, it must evaluate to "true" for the target to qualify. If it fails, the result for the current TA in the report will be "notRelevant". Otherwise, the target can be further evaluated by the predicate of the main TA. The expression may refer to the target explicitly using the variable name "$target", or to any cotarget using its name as variable name ($[name]). |
Predicate: |
[markup: testAssertion/predicate] required element] A logical expression that evaluates whether this target is fulfilling the profile requirement addressed by this test Assertion. By default: - A result of true means the requirement is fulfilled (reported as a "passed" in the test report).- A result of false means the requirement is violated (reported as a "failed" in the test report). However, in some cases and for testability reasons, the predicate may be designed as a partial indicator e.g. only indicates some cases of fulfillment, or some cases of violation. As a result, when "true" indicates fulfillment it may be that "false" is unconclusive, or conversely "false" will indicate violation, but "true" is unconclusive. In such cases, the "Reporting" element specifies the meaning of the predicate result w/r to the profile requirement. The predicate expression implicitly refers to the target (whic is its "XPath context") although it may explicitly refer to it using the variable name "$target". It may refer to any cotarget using its name as variable name ($[name]). |
Prescription: |
[markup: testAssertion/prescription/@level ] (required) Conveys the level of prescription associated with the profile requirement. At least three values may be used:
|
Reporting: |
[markup: testAssertion/reporting ] (optional) For each possible outcome of the predicate (true or false), specifies how it must be interpreted w/r to the profile feature. Two attributes are used that both must be present, when this element is present:
NOTES: the predicate of the TA may be worded in a negative way so that @false='passed' although that is not recommended. The result of a test should not be related to the prescription level, e.g. a "preferred" or "permitted" level should not imply that @false='warning'. Other test results that are automatically generated and not controlled by the "reporting" element are:
|
These requirements establish a minimum baseline for an RMD to correctly piggyback SequenceAcknowledgement headers. Both endpoints should expect that at minimum, an RMD can compare address IRIs based on a simple string comparison algorithm, as indicated in the RFC 3987 section 5.3.1, in order to make the decision to piggyback or not. Individual RMD implementations may choose to consider and/or compare additional elements of the EndpointReference (e.g. the value of any ReferenceParameters elements).
There exists an interoperability problem for Sequences in which the AcksTo EPR contains ReferenceParameters. According to the processing rules defined by Web Services Addressing 1.0 - SOAP Binding , the RMS should expect that any acknowledgements for the Sequence will be accompanied by the contents of the wsrm:AcksTo/wsa:ReferenceParameters promoted as headers in the message carrying that acknowledgement. However, in the case of piggybacked acknowledgments, the carrier message's [destination] EPR may contain Reference Parameters that conflict in some way with the wsrm:AcksTo/ReferenceParameters.
R0510 If the algorithm used by the RMD to determine if a SequenceAcknowledgment can be piggybacked onto another message does not include a comparison of the value of the ReferenceParameters element (when present), then the RMD MUST NOT piggyback SequenceAcknowledgement headers for Sequences in which the AcksTo EPR contains ReferenceParameters.TESTABLE RSP0510
Test Assertion Analysis: | RSP0510 |
---|---|
General Notes: | As the explanatory text describes, this requirement is about enforcing the following invariant: for Sequences in which the AcksTo EPR contains ReferenceParameters, any message containing SequenceAcknowledgement header(s) for such Sequences will also contain the AcksTo/wsa:ReferenceParameters in its SOAP headers. It is possible to create a test assertion for this requirement by correlating SequenceAcknowlement headers against the CreateSequence message for the Sequence to which they apply and checking for the presence of reflected reference parameter elements. As with the test for R0501, the problem lies in the test coverage. Without specific knowledge of an implementation, it is difficult to guess what might trigger it to piggyback acknowledgements. The best that can be done is to run test scenarios that create Sequences in which the AcksTo EPR contains reference parameters and see if there are any cases in which the SequenceAcknowledgment is not accompanied by the reflected reference parameter headers. |
Coverage Assessment: | Partial (piggybacking difficult to stimulate). |
Target Type: | ENVELOPE |
Test Target: | A SOAP Envelope in which: a. One or more SequenceAcknowledgment headers appear. b. The Body is a not empty. c. The Sequence identified by /wsrm:SequenceAcknowledgment/wsrm:Identifier was created by a CreateSequence message in which /wsrm:CreateSequence/wsrm:AcksTo/wsa:ReferenceParameters was not empty. |
Test co-Target(s): | |
Test Prerequisite: | |
Predicate: | The value of each child element of /wsrm:CreateSequence/wsrm:AcksTo/wsa:ReferenceParameters must appear as a SOAP Header in the [target] and must be annotated with the wsa:IsReferenceParameter attribute. No other SOAP Headers besides these should be so annotated. |
Prescription: | mandatory |
Reporting: | |
Test Control: | (additional scenarios) Scenario: x.x.x Reliable_Request_Response_AcksTo_RefParm The client creates a sequence to the service with a CreateSequence message that contains a non-anonymous AcksTo with ReferenceParameters. The CreateSequence may or may not contain an Offer. The service supports reliable requests and either reliable or non-reliable responses. The client reliably sends a number of messages to the service. The /wsa:ReplyTo/wsa:Address for all these request should be identical to the /wsrm:CreateSequence/wsrm:AcksTo/wsa:Address but the /wsa:ReplyTo/wsa:ReferenceParameters should alternate between a set that is identical to /wsrm:CreateSequence/wsrm:AcksTo/wsa:ReferenceParameters and a set that is different. |
Test Assertion: | RSP0510 |
---|---|
Description: | |
Target: |
[ *:Header[wsrm:SequenceAcknowledgement and not(*:Header/wsse:Security//xenc:ReferenceList)] and *:Body[node() and not(*:Fault) and not(wsrm:*)]] [ some $tgt in . satisfies some $csr in /wsil:testLog/wsil:messageLog/wsil:message//*:Envelope[*:Body/wsrm:CreateSequenceResponse][$tgt/*:Header/wsrm:SequenceAcknowledgement/wsrm:Identifier = *:Body/wsrm:CreateSequenceResponse/wsrm:Identifier] satisfies some $cs in /wsil:testLog/wsil:messageLog/wsil:message/wsil:messageContents/*:Envelope[*:Body/wsrm:CreateSequence] satisfies ($csr/../../@conversation = $cs/../../@conversation or $csr/*:Header/wsa:RelatesTo[@RelationshipType = 'http://www.w3.org/2005/08/addressing/reply' or not (@RelationshipType)] = $cs/*:Header/wsa:MessageID)] |
co-Target: mycreateseq |
|
Predicate: |
|
Reporting: | true=passed, false=warning |
Prescription: | mandatory |
Error Message: | Warning: a SequenceAcknowledgement message is piggybacked, while relating to a sequence with wsrm:CreateSequence/wsrm:AcksTo value containing reference parameters. This is only allowed if the RMD is able to compare the value of the ReferenceParameters elements in order to determine if the piggybacking is appropriate. |
Diagnostic Data: |
|
Test Assertion Part | What it means: |
---|---|
Test Assertion ID: |
[markup: testAssertion/@id] (required) A unique ID for the current test assertion. |
Description: |
[markup: testAssertion/description ] (optional) A plain text description of the current test assertion. At minimum expressing the TA predicate. |
Comments: |
[markup: testAssertion/comments ] (optional) A plain text comment about the TA script and how well it covers the profile requirement. Explanation material for users, and developers (what could be improved, etc.). |
Target: |
[markup: testAssertion/target ] (required) The artifacts to be tested, defined by an XPath expression that returns a list of XML nodes from the log file in input. For every artifact (node) selected by the Target expression, there will be a report entry for this TA in the test report, with a result of either:
See the "reporting" item for the meaning of these results. |
Cotarget: |
[markup: testAssertion/cotarget ] (optional) Artifact that is related to the target, and that needs be accessed for the testing. Identified by an XPath expression that may refer to the related target node using the variable '$target'. For example, the target can be a SOAP message and the cotarget the WSDL file that describes this SOAP message. A cotarget must have a @name attribute that identifies it. The value of this attribute can be used as a variable (when prepending '$' to it) by subsequently defined cotargets, prerequisite and predicate. |
Prerequisite: |
[markup: testAssertion/@preReq ] (optional) [markup: testAssertion/prerequisite ] (optional) The pre-condition for evaluating this Test Assertion on this target. If the prerequisite evaluates to "false" then the target does not qualify for this Test Assertion (the test report is "notRelevant") The first part (preReq attribute) is an enumeration of Test Assertion IDs. Each one of the prerequisite TAs must either use the same target (e.g. SOAP Envelope, or WSDL binding, etc.) as this TA, or a target that is of a more general type than the main TA target. The target must "pass" each one of these prerequisite TAs in order to qualify for this TA. (e.g. the target of TA t1 can be a WSDL binding while the target of a TA t2 prerequisite of t1, can be the entire WSDL file). The second part ("prerequisite" element) is an XPath (boolean) expression of the same nature as the predicate. If present, it must evaluate to "true" for the target to qualify. If it fails, the result for the current TA in the report will be "notRelevant". Otherwise, the target can be further evaluated by the predicate of the main TA. The expression may refer to the target explicitly using the variable name "$target", or to any cotarget using its name as variable name ($[name]). |
Predicate: |
[markup: testAssertion/predicate] required element] A logical expression that evaluates whether this target is fulfilling the profile requirement addressed by this test Assertion. By default: - A result of true means the requirement is fulfilled (reported as a "passed" in the test report).- A result of false means the requirement is violated (reported as a "failed" in the test report). However, in some cases and for testability reasons, the predicate may be designed as a partial indicator e.g. only indicates some cases of fulfillment, or some cases of violation. As a result, when "true" indicates fulfillment it may be that "false" is unconclusive, or conversely "false" will indicate violation, but "true" is unconclusive. In such cases, the "Reporting" element specifies the meaning of the predicate result w/r to the profile requirement. The predicate expression implicitly refers to the target (whic is its "XPath context") although it may explicitly refer to it using the variable name "$target". It may refer to any cotarget using its name as variable name ($[name]). |
Prescription: |
[markup: testAssertion/prescription/@level ] (required) Conveys the level of prescription associated with the profile requirement. At least three values may be used:
|
Reporting: |
[markup: testAssertion/reporting ] (optional) For each possible outcome of the predicate (true or false), specifies how it must be interpreted w/r to the profile feature. Two attributes are used that both must be present, when this element is present:
NOTES: the predicate of the TA may be worded in a negative way so that @false='passed' although that is not recommended. The result of a test should not be related to the prescription level, e.g. a "preferred" or "permitted" level should not imply that @false='warning'. Other test results that are automatically generated and not controlled by the "reporting" element are:
|
This requirement ensures any RMS implementation that includes ReferenceParameters in its AckTo EPRs of the following invariant: regardless of whether or not the acknowledgments for such Sequences are piggybacked, any message containing the SequenceAcknowledgement header(s) for such Sequences will also contain the AcksTo/wsa:ReferenceParameters in its SOAP headers. Note, this requirement applies equally to Sequences for which AcksTo/wsa:Address is anonymous and Sequences for which AcksTo/wsa:Address is not anonymous.
In situations where an RMD exercises the opportunity to piggyback most or all of the wsrm:SequenceAcknowledgement headers for a particular Sequence to an RMS which does not support the processing of piggybacked acknowledgments, it is likely that the operation of the WS-RM protocol will be severely impacted. This situation can be avoided if the RMS takes steps to ensure that the AcksTo EPRs for any Sequence's it creates are sufficiently unique as to cause the RMD to rule out the possibility of piggybacking acknowledgments for these Sequences.
R0520 An RMS that does not support the processing of piggybacked SequenceAcknowledgement headers MUST differentiate the AcksTo EPRs for any Sequence's it creates from other EPRs.NOT_TESTABLE
The term "differentiate" in the above requirement refers to the process of altering the information in the EPR in such a way as to cause the RMD to rule out the possibility of piggybacking acknowledgments for these Sequences while preserving the RMDs ability to connect to the proper transport endpoint. For example, suppose a particular instance of a web services stack maintains a generic, asynchronous callback facility at http://b2b.foo.com/async/AsyncResponseService. In general, all the EPRs minted by this instance for the purpose of servicing callbacks will have this URI as the value of their wsa:Address element. However, if this web services stack does not support the processing piggybacked acknowledgements, the use of this value in the AcksTo EPR creates the potential for the problem described above. The RMS implementation of this web services stack could fulfill this requirement by specifying http://b2b.foo.com/async/AsyncResponseService?p={unique value } as the address of the AcksTo EPR for any sequences it creates. Since each sequence has a "different" AcksTo EPR (as defined by R0500) from all the other services listening for callbacks, no RSP 1.0 compliant RMD will piggyback acknowledgements for these sequences, though each RMD (in the case of SOAP/HTTP) will correctly connect to http://b2b.foo.com and POST to /async/AsyncResponseService.
Points (2) and (3) of Section 3.3 of the WS-ReliableMessaging state that:
R0530 In cases where the SequenceAcknowledgement or AckRequested header is piggybacked, then the wsa:Action value of the ENVELOPE MUST be as defined by Section 3.3 of the WS-ReliableMessaging specification if, and only if, the wsa:Action value has not been agreed upon by some other mechanism (e.g. WSDL).TESTABLE RSP0530a RSP0530b RSP0530c RSP0530d
Test Assertion Analysis: | RSP0530a |
---|---|
General Notes: | The trick to testing this requirement is to define an response operation with an empty body and a non-empty wsa:Action header and create a situation in which this response is likely to carry a piggybacked acknowledgement. Case 1: a wsa:Action is defined in the WSDL for an empty response. Case 2: not so -- default in 3.3 apples. |
Coverage Assessment: | Good |
Target Type: | ENVELOPE |
Test Target: | A SOAP Envelope which: a. Corresponds to the wsdl:output message of our test scenario (i.e. is the response to the wsdl:input message in the test scenario). b. Has one or more SequenceAcknowledgment headers. |
Test co-Target(s): | |
Test Prerequisite: | |
Predicate: | The value of the wsa:Action header is as defined by wsam:Action attribute of the wsdl:output message in the test scenario |
Prescription: | mandatory |
Reporting: | true=pass, false=fail |
Test Control: | (additional scenarios) Scenario: x.x.x Reliable_Request_Empty_Response Create a WSDL with a portType that defines a single request-response operation. The wsdl:output of this operation should have an empty message and a non-empty wsam:Action attribute. A client implementation of this WSDL reliably sends the request messages and either reliably or non-reliably receives the response messages. So two cases are looked at: considering an empty out message with SeqAck piggybacked: (1) if non-empty wsam:Action in WSDL for the out message, then a wsa:Action with same value should be in header, (2) if no wsam:Action in WSDL for the out message, then a wsa:Action with default 'SeqAck' value should be in. |
Test Assertion: | RSP0530a |
---|---|
Description: | Case (a): Ack is sent back over a response message that RelatesTo a request message in a 2-way WSDL operation. |
Target: |
[ *:Header[wsrm:SequenceAcknowledgement and not(//xenc:ReferenceList)] and *:Body[ not(*:Fault) and not(wsrm:*)]/* and ( *:Header/wsa:RelatesTo[@RelationshipType = 'http://www.w3.org/2005/08/addressing/reply' or not (@RelationshipType)] = /wsil:testLog/wsil:messageLog/wsil:message/wsil:messageContents/*:Envelope/*:Header/wsa:MessageID) ] |
co-Target: myOpBind |
[ some $opb in . satisfies some $req in /wsil:testLog/wsil:messageLog/wsil:message/wsil:messageContents/*:Envelope[ *:Header/wsa:ReplyTo or ./../../@type = 'request' ] satisfies ($target/*:Header/wsa:RelatesTo[@RelationshipType = 'http://www.w3.org/2005/08/addressing/reply' or not (@RelationshipType)] = $req/*:Header/wsa:MessageID) and ( $opb/@name = local-name-from-QName(node-name($req/*:Body/*[1])) or (some $pop in //wsil:descriptionFile/wsdl:definitions/wsdl:portType/wsdl:operation[@name = $opb/@name] satisfies some $dmsg in $pop/../../wsdl:message[fn:resolve-QName(xsd:string(wsdl:part[1]/@element), .) = fn:node-name($req/*:Body/*[1])] satisfies fn:ends-with($pop/wsdl:input/@message, $dmsg/@name) ) ) ][1] |
Predicate: |
|
Reporting: | true=passed, false=failed |
Prescription: | mandatory |
Error Message: | A wsrm:SequenceAcknowledgement sent as response to a request message mapping to a WSDL two-way operation, does not conform to Section 3.3 of the WS-ReliableMessaging specification: it does not have the wsa:Action conforming to the output/@name attribute (if any) of the port definition or does not have the default value of operation name concatenated with 'Response'. |
Diagnostic Data: |
|
Test Assertion Part | What it means: |
---|---|
Test Assertion ID: |
[markup: testAssertion/@id] (required) A unique ID for the current test assertion. |
Description: |
[markup: testAssertion/description ] (optional) A plain text description of the current test assertion. At minimum expressing the TA predicate. |
Comments: |
[markup: testAssertion/comments ] (optional) A plain text comment about the TA script and how well it covers the profile requirement. Explanation material for users, and developers (what could be improved, etc.). |
Target: |
[markup: testAssertion/target ] (required) The artifacts to be tested, defined by an XPath expression that returns a list of XML nodes from the log file in input. For every artifact (node) selected by the Target expression, there will be a report entry for this TA in the test report, with a result of either:
See the "reporting" item for the meaning of these results. |
Cotarget: |
[markup: testAssertion/cotarget ] (optional) Artifact that is related to the target, and that needs be accessed for the testing. Identified by an XPath expression that may refer to the related target node using the variable '$target'. For example, the target can be a SOAP message and the cotarget the WSDL file that describes this SOAP message. A cotarget must have a @name attribute that identifies it. The value of this attribute can be used as a variable (when prepending '$' to it) by subsequently defined cotargets, prerequisite and predicate. |
Prerequisite: |
[markup: testAssertion/@preReq ] (optional) [markup: testAssertion/prerequisite ] (optional) The pre-condition for evaluating this Test Assertion on this target. If the prerequisite evaluates to "false" then the target does not qualify for this Test Assertion (the test report is "notRelevant") The first part (preReq attribute) is an enumeration of Test Assertion IDs. Each one of the prerequisite TAs must either use the same target (e.g. SOAP Envelope, or WSDL binding, etc.) as this TA, or a target that is of a more general type than the main TA target. The target must "pass" each one of these prerequisite TAs in order to qualify for this TA. (e.g. the target of TA t1 can be a WSDL binding while the target of a TA t2 prerequisite of t1, can be the entire WSDL file). The second part ("prerequisite" element) is an XPath (boolean) expression of the same nature as the predicate. If present, it must evaluate to "true" for the target to qualify. If it fails, the result for the current TA in the report will be "notRelevant". Otherwise, the target can be further evaluated by the predicate of the main TA. The expression may refer to the target explicitly using the variable name "$target", or to any cotarget using its name as variable name ($[name]). |
Predicate: |
[markup: testAssertion/predicate] required element] A logical expression that evaluates whether this target is fulfilling the profile requirement addressed by this test Assertion. By default: - A result of true means the requirement is fulfilled (reported as a "passed" in the test report).- A result of false means the requirement is violated (reported as a "failed" in the test report). However, in some cases and for testability reasons, the predicate may be designed as a partial indicator e.g. only indicates some cases of fulfillment, or some cases of violation. As a result, when "true" indicates fulfillment it may be that "false" is unconclusive, or conversely "false" will indicate violation, but "true" is unconclusive. In such cases, the "Reporting" element specifies the meaning of the predicate result w/r to the profile requirement. The predicate expression implicitly refers to the target (whic is its "XPath context") although it may explicitly refer to it using the variable name "$target". It may refer to any cotarget using its name as variable name ($[name]). |
Prescription: |
[markup: testAssertion/prescription/@level ] (required) Conveys the level of prescription associated with the profile requirement. At least three values may be used:
|
Reporting: |
[markup: testAssertion/reporting ] (optional) For each possible outcome of the predicate (true or false), specifies how it must be interpreted w/r to the profile feature. Two attributes are used that both must be present, when this element is present:
NOTES: the predicate of the TA may be worded in a negative way so that @false='passed' although that is not recommended. The result of a test should not be related to the prescription level, e.g. a "preferred" or "permitted" level should not imply that @false='warning'. Other test results that are automatically generated and not controlled by the "reporting" element are:
|
Test Assertion Analysis: | RSP0530b |
---|---|
General Notes: | The trick to testing this requirement is to define an response operation with an empty body and a non-empty wsa:Action header and create a situation in which this response is likely to carry a piggybacked acknowledgement. Case 1: a wsa:Action is defined in the WSDL for an empty response. Case 2: not so -- default in 3.3 apples. |
Coverage Assessment: | Good |
Target Type: | ENVELOPE |
Test Target: | A SOAP Envelope which: a. Corresponds to the wsdl:output message of our test scenario (i.e. is the response to the wsdl:input message in the test scenario). b. Has one or more SequenceAcknowledgment headers. |
Test co-Target(s): | |
Test Prerequisite: | |
Predicate: | The value of the wsa:Action header is as defined by wsam:Action attribute of the wsdl:output message in the test scenario |
Prescription: | mandatory |
Reporting: | true=passed, false=failed |
Test Control: | (additional scenarios) Scenario: x.x.x Reliable_Request_Empty_Response Create a WSDL with a portType that defines a single request-response operation. The wsdl:output of this operation should have an empty message and a non-empty wsam:Action attribute. A client implementation of this WSDL reliably sends the request messages and either reliably or non-reliably receives the response messages. So two cases are looked at: considering an empty out message with SeqAck piggybacked: (1) if non-empty wsam:Action in WSDL for the out message, then a wsa:Action with same value should be in header, (2) if no wsam:Action in WSDL for the out message, then a wsa:Action with default 'SeqAck' value should be in. |
Test Assertion: | RSP0530b |
---|---|
Description: | Case (b): Ack is piggybacked over a (non-empty) request message, i.e. no RelatesTo element. |
Target: |
[ *:Header[wsrm:SequenceAcknowledgement and not(//xenc:ReferenceList)] and *:Body[element() and not(wsmc:MakeConnection) and not(*:Fault) and not(wsrm:*)] and not(*:Header/wsa:RelatesTo[@RelationshipType = 'http://www.w3.org/2005/08/addressing/reply' or not (@RelationshipType)]) ] |
co-Target: myOpBind |
[ some $opb in . satisfies ( $opb/@name = local-name-from-QName(node-name($target/*:Body/*[1])) or (some $pop in //wsil:descriptionFile/wsdl:definitions/wsdl:portType/wsdl:operation[@name = $opb/@name] satisfies some $dmsg in $pop/../../wsdl:message[fn:resolve-QName(xsd:string(wsdl:part[1]/@element), .) = fn:node-name($target/*:Body/*[1])] satisfies fn:ends-with($pop/wsdl:input/@message, $dmsg/@name)) ) ][1] |
Predicate: |
|
Reporting: | true=passed, false=failed |
Prescription: | mandatory |
Error Message: | A wsrm:SequenceAcknowledgement piggybacked over a request message does not conform to Section 3.3 of the WS-ReliableMessaging specification: it does not have the wsa:Action conforming to the inpput/@name attribute (if any) of the port definition or does not have the default value of operation name. |
Diagnostic Data: |
|
Test Assertion Part | What it means: |
---|---|
Test Assertion ID: |
[markup: testAssertion/@id] (required) A unique ID for the current test assertion. |
Description: |
[markup: testAssertion/description ] (optional) A plain text description of the current test assertion. At minimum expressing the TA predicate. |
Comments: |
[markup: testAssertion/comments ] (optional) A plain text comment about the TA script and how well it covers the profile requirement. Explanation material for users, and developers (what could be improved, etc.). |
Target: |
[markup: testAssertion/target ] (required) The artifacts to be tested, defined by an XPath expression that returns a list of XML nodes from the log file in input. For every artifact (node) selected by the Target expression, there will be a report entry for this TA in the test report, with a result of either:
See the "reporting" item for the meaning of these results. |
Cotarget: |
[markup: testAssertion/cotarget ] (optional) Artifact that is related to the target, and that needs be accessed for the testing. Identified by an XPath expression that may refer to the related target node using the variable '$target'. For example, the target can be a SOAP message and the cotarget the WSDL file that describes this SOAP message. A cotarget must have a @name attribute that identifies it. The value of this attribute can be used as a variable (when prepending '$' to it) by subsequently defined cotargets, prerequisite and predicate. |
Prerequisite: |
[markup: testAssertion/@preReq ] (optional) [markup: testAssertion/prerequisite ] (optional) The pre-condition for evaluating this Test Assertion on this target. If the prerequisite evaluates to "false" then the target does not qualify for this Test Assertion (the test report is "notRelevant") The first part (preReq attribute) is an enumeration of Test Assertion IDs. Each one of the prerequisite TAs must either use the same target (e.g. SOAP Envelope, or WSDL binding, etc.) as this TA, or a target that is of a more general type than the main TA target. The target must "pass" each one of these prerequisite TAs in order to qualify for this TA. (e.g. the target of TA t1 can be a WSDL binding while the target of a TA t2 prerequisite of t1, can be the entire WSDL file). The second part ("prerequisite" element) is an XPath (boolean) expression of the same nature as the predicate. If present, it must evaluate to "true" for the target to qualify. If it fails, the result for the current TA in the report will be "notRelevant". Otherwise, the target can be further evaluated by the predicate of the main TA. The expression may refer to the target explicitly using the variable name "$target", or to any cotarget using its name as variable name ($[name]). |
Predicate: |
[markup: testAssertion/predicate] required element] A logical expression that evaluates whether this target is fulfilling the profile requirement addressed by this test Assertion. By default: - A result of true means the requirement is fulfilled (reported as a "passed" in the test report).- A result of false means the requirement is violated (reported as a "failed" in the test report). However, in some cases and for testability reasons, the predicate may be designed as a partial indicator e.g. only indicates some cases of fulfillment, or some cases of violation. As a result, when "true" indicates fulfillment it may be that "false" is unconclusive, or conversely "false" will indicate violation, but "true" is unconclusive. In such cases, the "Reporting" element specifies the meaning of the predicate result w/r to the profile requirement. The predicate expression implicitly refers to the target (whic is its "XPath context") although it may explicitly refer to it using the variable name "$target". It may refer to any cotarget using its name as variable name ($[name]). |
Prescription: |
[markup: testAssertion/prescription/@level ] (required) Conveys the level of prescription associated with the profile requirement. At least three values may be used:
|
Reporting: |
[markup: testAssertion/reporting ] (optional) For each possible outcome of the predicate (true or false), specifies how it must be interpreted w/r to the profile feature. Two attributes are used that both must be present, when this element is present:
NOTES: the predicate of the TA may be worded in a negative way so that @false='passed' although that is not recommended. The result of a test should not be related to the prescription level, e.g. a "preferred" or "permitted" level should not imply that @false='warning'. Other test results that are automatically generated and not controlled by the "reporting" element are:
|
Test Assertion Analysis: | RSP0530c |
---|---|
General Notes: | The trick to testing this requirement is to define an response operation with an empty body and a non-empty wsa:Action header and create a situation in which this response is likely to carry a piggybacked acknowledgement. Case 1: a wsa:Action is defined in the WSDL for an empty response. Case 2: not so -- default in 3.3 apples. |
Coverage Assessment: | Good |
Target Type: | ENVELOPE |
Test Target: | A SOAP Envelope which: a. Corresponds to the wsdl:output message of our test scenario (i.e. is the response to the wsdl:input message in the test scenario). b. Has one or more SequenceAcknowledgment headers. |
Test co-Target(s): | |
Test Prerequisite: | |
Predicate: | The value of the wsa:Action header is as defined by wsam:Action attribute of the wsdl:output message in the test scenario |
Prescription: | mandatory |
Reporting: | true=passed, false=failed |
Test Control: | (additional scenarios) Scenario: x.x.x Reliable_Request_Empty_Response Create a WSDL with a portType that defines a single request-response operation. The wsdl:output of this operation should have an empty message and a non-empty wsam:Action attribute. A client implementation of this WSDL reliably sends the request messages and either reliably or non-reliably receives the response messages. So two cases are looked at: considering an empty out message with SeqAck piggybacked: (1) if non-empty wsam:Action in WSDL for the out message, then a wsa:Action with same value should be in header, (2) if no wsam:Action in WSDL for the out message, then a wsa:Action with default 'SeqAck' value should be in. |
Test Assertion: | RSP0530c |
---|---|
Description: | Case (c): Ack is over an empty request message that is not a Response, i.e. "not piggybacked": no RelatesTo element. |
Target: |
[ *:Header/wsrm:SequenceAcknowledgement and not(*:Body/* ) and not(*:Header/wsa:RelatesTo[@RelationshipType = 'http://www.w3.org/2005/08/addressing/reply' or not (@RelationshipType)]) ] |
Predicate: |
|
Reporting: | true=passed, false=failed |
Prescription: | mandatory |
Error Message: | A wsrm:SequenceAcknowledgement sent over a message with an empty s:Body and that is not a response message, does not have its wsa:Action URI value set to the predefined: "http://docs.oasis-open.org/ws-rx/wsrm/200702/SequenceAcknowledgement" |
Diagnostic Data: |
|
Test Assertion Part | What it means: |
---|---|
Test Assertion ID: |
[markup: testAssertion/@id] (required) A unique ID for the current test assertion. |
Description: |
[markup: testAssertion/description ] (optional) A plain text description of the current test assertion. At minimum expressing the TA predicate. |
Comments: |
[markup: testAssertion/comments ] (optional) A plain text comment about the TA script and how well it covers the profile requirement. Explanation material for users, and developers (what could be improved, etc.). |
Target: |
[markup: testAssertion/target ] (required) The artifacts to be tested, defined by an XPath expression that returns a list of XML nodes from the log file in input. For every artifact (node) selected by the Target expression, there will be a report entry for this TA in the test report, with a result of either:
See the "reporting" item for the meaning of these results. |
Cotarget: |
[markup: testAssertion/cotarget ] (optional) Artifact that is related to the target, and that needs be accessed for the testing. Identified by an XPath expression that may refer to the related target node using the variable '$target'. For example, the target can be a SOAP message and the cotarget the WSDL file that describes this SOAP message. A cotarget must have a @name attribute that identifies it. The value of this attribute can be used as a variable (when prepending '$' to it) by subsequently defined cotargets, prerequisite and predicate. |
Prerequisite: |
[markup: testAssertion/@preReq ] (optional) [markup: testAssertion/prerequisite ] (optional) The pre-condition for evaluating this Test Assertion on this target. If the prerequisite evaluates to "false" then the target does not qualify for this Test Assertion (the test report is "notRelevant") The first part (preReq attribute) is an enumeration of Test Assertion IDs. Each one of the prerequisite TAs must either use the same target (e.g. SOAP Envelope, or WSDL binding, etc.) as this TA, or a target that is of a more general type than the main TA target. The target must "pass" each one of these prerequisite TAs in order to qualify for this TA. (e.g. the target of TA t1 can be a WSDL binding while the target of a TA t2 prerequisite of t1, can be the entire WSDL file). The second part ("prerequisite" element) is an XPath (boolean) expression of the same nature as the predicate. If present, it must evaluate to "true" for the target to qualify. If it fails, the result for the current TA in the report will be "notRelevant". Otherwise, the target can be further evaluated by the predicate of the main TA. The expression may refer to the target explicitly using the variable name "$target", or to any cotarget using its name as variable name ($[name]). |
Predicate: |
[markup: testAssertion/predicate] required element] A logical expression that evaluates whether this target is fulfilling the profile requirement addressed by this test Assertion. By default: - A result of true means the requirement is fulfilled (reported as a "passed" in the test report).- A result of false means the requirement is violated (reported as a "failed" in the test report). However, in some cases and for testability reasons, the predicate may be designed as a partial indicator e.g. only indicates some cases of fulfillment, or some cases of violation. As a result, when "true" indicates fulfillment it may be that "false" is unconclusive, or conversely "false" will indicate violation, but "true" is unconclusive. In such cases, the "Reporting" element specifies the meaning of the predicate result w/r to the profile requirement. The predicate expression implicitly refers to the target (whic is its "XPath context") although it may explicitly refer to it using the variable name "$target". It may refer to any cotarget using its name as variable name ($[name]). |
Prescription: |
[markup: testAssertion/prescription/@level ] (required) Conveys the level of prescription associated with the profile requirement. At least three values may be used:
|
Reporting: |
[markup: testAssertion/reporting ] (optional) For each possible outcome of the predicate (true or false), specifies how it must be interpreted w/r to the profile feature. Two attributes are used that both must be present, when this element is present:
NOTES: the predicate of the TA may be worded in a negative way so that @false='passed' although that is not recommended. The result of a test should not be related to the prescription level, e.g. a "preferred" or "permitted" level should not imply that @false='warning'. Other test results that are automatically generated and not controlled by the "reporting" element are:
|
Test Assertion Analysis: | RSP0530d |
---|---|
General Notes: | |
Coverage Assessment: | Good |
Target Type: | ENVELOPE |
Test Target: | A SOAP Envelope with: a. MakeConnection: b. Has one or more SequenceAcknowledgment headers. |
Test co-Target(s): | |
Test Prerequisite: | |
Predicate: | The value of the wsa:Action header is the MC URI. |
Prescription: | mandatory |
Reporting: | true=passed, false=failed |
Test Control: |
Test Assertion: | RSP0530d |
---|---|
Description: | Case (b): Ack is piggybacked over a (non-empty) request message, i.e. no RelatesTo element. |
Target: |
[ *:Header/wsrm:SequenceAcknowledgement and *:Body/wsmc:MakeConnection ] |
Predicate: |
|
Reporting: | true=passed, false=failed |
Prescription: | mandatory |
Error Message: | A wsrm:SequenceAcknowledgement piggybacked over an MakeConnection message does not have the wsa:Action set to http://docs.oasis-open.org/ws-rx/wsmc/200702/MakeConnection. |
Diagnostic Data: |
|
Test Assertion Part | What it means: |
---|---|
Test Assertion ID: |
[markup: testAssertion/@id] (required) A unique ID for the current test assertion. |
Description: |
[markup: testAssertion/description ] (optional) A plain text description of the current test assertion. At minimum expressing the TA predicate. |
Comments: |
[markup: testAssertion/comments ] (optional) A plain text comment about the TA script and how well it covers the profile requirement. Explanation material for users, and developers (what could be improved, etc.). |
Target: |
[markup: testAssertion/target ] (required) The artifacts to be tested, defined by an XPath expression that returns a list of XML nodes from the log file in input. For every artifact (node) selected by the Target expression, there will be a report entry for this TA in the test report, with a result of either:
See the "reporting" item for the meaning of these results. |
Cotarget: |
[markup: testAssertion/cotarget ] (optional) Artifact that is related to the target, and that needs be accessed for the testing. Identified by an XPath expression that may refer to the related target node using the variable '$target'. For example, the target can be a SOAP message and the cotarget the WSDL file that describes this SOAP message. A cotarget must have a @name attribute that identifies it. The value of this attribute can be used as a variable (when prepending '$' to it) by subsequently defined cotargets, prerequisite and predicate. |
Prerequisite: |
[markup: testAssertion/@preReq ] (optional) [markup: testAssertion/prerequisite ] (optional) The pre-condition for evaluating this Test Assertion on this target. If the prerequisite evaluates to "false" then the target does not qualify for this Test Assertion (the test report is "notRelevant") The first part (preReq attribute) is an enumeration of Test Assertion IDs. Each one of the prerequisite TAs must either use the same target (e.g. SOAP Envelope, or WSDL binding, etc.) as this TA, or a target that is of a more general type than the main TA target. The target must "pass" each one of these prerequisite TAs in order to qualify for this TA. (e.g. the target of TA t1 can be a WSDL binding while the target of a TA t2 prerequisite of t1, can be the entire WSDL file). The second part ("prerequisite" element) is an XPath (boolean) expression of the same nature as the predicate. If present, it must evaluate to "true" for the target to qualify. If it fails, the result for the current TA in the report will be "notRelevant". Otherwise, the target can be further evaluated by the predicate of the main TA. The expression may refer to the target explicitly using the variable name "$target", or to any cotarget using its name as variable name ($[name]). |
Predicate: |
[markup: testAssertion/predicate] required element] A logical expression that evaluates whether this target is fulfilling the profile requirement addressed by this test Assertion. By default: - A result of true means the requirement is fulfilled (reported as a "passed" in the test report).- A result of false means the requirement is violated (reported as a "failed" in the test report). However, in some cases and for testability reasons, the predicate may be designed as a partial indicator e.g. only indicates some cases of fulfillment, or some cases of violation. As a result, when "true" indicates fulfillment it may be that "false" is unconclusive, or conversely "false" will indicate violation, but "true" is unconclusive. In such cases, the "Reporting" element specifies the meaning of the predicate result w/r to the profile requirement. The predicate expression implicitly refers to the target (whic is its "XPath context") although it may explicitly refer to it using the variable name "$target". It may refer to any cotarget using its name as variable name ($[name]). |
Prescription: |
[markup: testAssertion/prescription/@level ] (required) Conveys the level of prescription associated with the profile requirement. At least three values may be used:
|
Reporting: |
[markup: testAssertion/reporting ] (optional) For each possible outcome of the predicate (true or false), specifies how it must be interpreted w/r to the profile feature. Two attributes are used that both must be present, when this element is present:
NOTES: the predicate of the TA may be worded in a negative way so that @false='passed' although that is not recommended. The result of a test should not be related to the prescription level, e.g. a "preferred" or "permitted" level should not imply that @false='warning'. Other test results that are automatically generated and not controlled by the "reporting" element are:
|
Since they are not allowed to interfere with the processing of messages, piggybacked SequenceAcknowledgement and AckRequested SOAP header blocks must not have the mustUnderstand attribute set to a value of true. However, when the SequenceAcknowledgement and AckRequested SOAP header blocks are sent on messages with an empty SOAP body element and a wsa:Action SOAP header block with a corresponding value of http://docs.oasis-open.org/ws-rx/wsrm/200702/SequenceAcknowledgement or http://docs.oasis-open.org/ws-rx/wsrm/200702/AckRequested (i.e. not piggybacked), implementations are advised to set the mustUnderstand attribute on the SequenceAcknowledgement and AckRequested SOAP header blocks to a value of true. This ensures that these headers are not ignored and avoids the resulting unnecessary retransmissions.
R0540 SENDERs MUST NOT set the value of mustUnderstand attribute on AckRequested and SequenceAcknowledgement SOAP header blocks to true ("1") when those headers are piggy-backed on outgoing MESSAGEs.TESTABLE RSP0540
Test Assertion Analysis: | RSP0540 |
---|---|
General Notes: | |
Coverage Assessment: | Good(should be able to cover all cases) |
Target Type: | ENVELOPE |
Test Target: | An ENVELOPE containing AckRequested or SequenceAcknowledgement |
Test co-Target(s): | |
Test Prerequisite: | |
Predicate: | For any ENVELOPE containing AckRequested or SequenceAcknowledgement, and that is piggybacked (Body not empty), then such headers not have mustUnderstand attribute set to true ('1'). |
Prescription: | mandatory |
Reporting: | true=passed, false=failed |
Test Control: |
Test Assertion: | RSP0540 |
---|---|
Description: | |
Target: |
|
Predicate: |
|
Reporting: | true=passed, false=failed |
Prescription: | mandatory |
Error Message: | Some message containing AckRequested or SequenceAcknowledgement has mustUnderstand attribute set to true ('1'), while these headers were piggybacked on another message. |
Diagnostic Data: |
|
Test Assertion Part | What it means: |
---|---|
Test Assertion ID: |
[markup: testAssertion/@id] (required) A unique ID for the current test assertion. |
Description: |
[markup: testAssertion/description ] (optional) A plain text description of the current test assertion. At minimum expressing the TA predicate. |
Comments: |
[markup: testAssertion/comments ] (optional) A plain text comment about the TA script and how well it covers the profile requirement. Explanation material for users, and developers (what could be improved, etc.). |
Target: |
[markup: testAssertion/target ] (required) The artifacts to be tested, defined by an XPath expression that returns a list of XML nodes from the log file in input. For every artifact (node) selected by the Target expression, there will be a report entry for this TA in the test report, with a result of either:
See the "reporting" item for the meaning of these results. |
Cotarget: |
[markup: testAssertion/cotarget ] (optional) Artifact that is related to the target, and that needs be accessed for the testing. Identified by an XPath expression that may refer to the related target node using the variable '$target'. For example, the target can be a SOAP message and the cotarget the WSDL file that describes this SOAP message. A cotarget must have a @name attribute that identifies it. The value of this attribute can be used as a variable (when prepending '$' to it) by subsequently defined cotargets, prerequisite and predicate. |
Prerequisite: |
[markup: testAssertion/@preReq ] (optional) [markup: testAssertion/prerequisite ] (optional) The pre-condition for evaluating this Test Assertion on this target. If the prerequisite evaluates to "false" then the target does not qualify for this Test Assertion (the test report is "notRelevant") The first part (preReq attribute) is an enumeration of Test Assertion IDs. Each one of the prerequisite TAs must either use the same target (e.g. SOAP Envelope, or WSDL binding, etc.) as this TA, or a target that is of a more general type than the main TA target. The target must "pass" each one of these prerequisite TAs in order to qualify for this TA. (e.g. the target of TA t1 can be a WSDL binding while the target of a TA t2 prerequisite of t1, can be the entire WSDL file). The second part ("prerequisite" element) is an XPath (boolean) expression of the same nature as the predicate. If present, it must evaluate to "true" for the target to qualify. If it fails, the result for the current TA in the report will be "notRelevant". Otherwise, the target can be further evaluated by the predicate of the main TA. The expression may refer to the target explicitly using the variable name "$target", or to any cotarget using its name as variable name ($[name]). |
Predicate: |
[markup: testAssertion/predicate] required element] A logical expression that evaluates whether this target is fulfilling the profile requirement addressed by this test Assertion. By default: - A result of true means the requirement is fulfilled (reported as a "passed" in the test report).- A result of false means the requirement is violated (reported as a "failed" in the test report). However, in some cases and for testability reasons, the predicate may be designed as a partial indicator e.g. only indicates some cases of fulfillment, or some cases of violation. As a result, when "true" indicates fulfillment it may be that "false" is unconclusive, or conversely "false" will indicate violation, but "true" is unconclusive. In such cases, the "Reporting" element specifies the meaning of the predicate result w/r to the profile requirement. The predicate expression implicitly refers to the target (whic is its "XPath context") although it may explicitly refer to it using the variable name "$target". It may refer to any cotarget using its name as variable name ($[name]). |
Prescription: |
[markup: testAssertion/prescription/@level ] (required) Conveys the level of prescription associated with the profile requirement. At least three values may be used:
|
Reporting: |
[markup: testAssertion/reporting ] (optional) For each possible outcome of the predicate (true or false), specifies how it must be interpreted w/r to the profile feature. Two attributes are used that both must be present, when this element is present:
NOTES: the predicate of the TA may be worded in a negative way so that @false='passed' although that is not recommended. The result of a test should not be related to the prescription level, e.g. a "preferred" or "permitted" level should not imply that @false='warning'. Other test results that are automatically generated and not controlled by the "reporting" element are:
|
The Profile includes the use of WS-SecureConversation to request and issue security tokens and to broker trust relationships.
This section of the Profile incorporates the following specifications by reference, and defines extensibility points within them:
These extensibility points are listed, along with any extensibility points from other sections of this Profile, in Appendix B
All requirements in Section 4 apply only when WS-Security is used to secure a message. All requirements in Sections 4.1 through 4.5 apply only when WS-SecureConversation is used to secure a message.
As noted in Section 2 , support for WS-SecureConversation by a specific service is optional. However, a service may require the use of WS-SecureConversation, in which case, for successful interaction with that service, a client will need to support it.
R1002 If an endpoint requires the use of WS-SecureConversation, any ENVELOPE sent to that endpoint MUST conform to Section 4 of this Profile. TESTABLE RSP1002a RSP1002b
Test Assertion Analysis: | RSP1002a |
---|---|
General Notes: | |
Coverage Assessment: | partial: |
Target Type: | ENVELOPE |
Test Target: | |
Test co-Target(s): | |
Test Prerequisite: | |
Predicate: | |
Prescription: | mandatory |
Reporting: | true=passed, false=failed |
Test Control: |
Test Assertion: | RSP1002a |
---|---|
Description: | |
Target: |
|
co-Target: myOpBinding |
|
Predicate: |
|
Reporting: | true=passed, false=failed |
Prescription: | mandatory |
Error Message: | A SOAP Envelope with an WSDL rpc-lit binding, and for which the use of a SecurityContextToken was required, did not contain a wssc:SecurityContextToken header. |
Diagnostic Data: |
|
Test Assertion Part | What it means: |
---|---|
Test Assertion ID: |
[markup: testAssertion/@id] (required) A unique ID for the current test assertion. |
Description: |
[markup: testAssertion/description ] (optional) A plain text description of the current test assertion. At minimum expressing the TA predicate. |
Comments: |
[markup: testAssertion/comments ] (optional) A plain text comment about the TA script and how well it covers the profile requirement. Explanation material for users, and developers (what could be improved, etc.). |
Target: |
[markup: testAssertion/target ] (required) The artifacts to be tested, defined by an XPath expression that returns a list of XML nodes from the log file in input. For every artifact (node) selected by the Target expression, there will be a report entry for this TA in the test report, with a result of either:
See the "reporting" item for the meaning of these results. |
Cotarget: |
[markup: testAssertion/cotarget ] (optional) Artifact that is related to the target, and that needs be accessed for the testing. Identified by an XPath expression that may refer to the related target node using the variable '$target'. For example, the target can be a SOAP message and the cotarget the WSDL file that describes this SOAP message. A cotarget must have a @name attribute that identifies it. The value of this attribute can be used as a variable (when prepending '$' to it) by subsequently defined cotargets, prerequisite and predicate. |
Prerequisite: |
[markup: testAssertion/@preReq ] (optional) [markup: testAssertion/prerequisite ] (optional) The pre-condition for evaluating this Test Assertion on this target. If the prerequisite evaluates to "false" then the target does not qualify for this Test Assertion (the test report is "notRelevant") The first part (preReq attribute) is an enumeration of Test Assertion IDs. Each one of the prerequisite TAs must either use the same target (e.g. SOAP Envelope, or WSDL binding, etc.) as this TA, or a target that is of a more general type than the main TA target. The target must "pass" each one of these prerequisite TAs in order to qualify for this TA. (e.g. the target of TA t1 can be a WSDL binding while the target of a TA t2 prerequisite of t1, can be the entire WSDL file). The second part ("prerequisite" element) is an XPath (boolean) expression of the same nature as the predicate. If present, it must evaluate to "true" for the target to qualify. If it fails, the result for the current TA in the report will be "notRelevant". Otherwise, the target can be further evaluated by the predicate of the main TA. The expression may refer to the target explicitly using the variable name "$target", or to any cotarget using its name as variable name ($[name]). |
Predicate: |
[markup: testAssertion/predicate] required element] A logical expression that evaluates whether this target is fulfilling the profile requirement addressed by this test Assertion. By default: - A result of true means the requirement is fulfilled (reported as a "passed" in the test report).- A result of false means the requirement is violated (reported as a "failed" in the test report). However, in some cases and for testability reasons, the predicate may be designed as a partial indicator e.g. only indicates some cases of fulfillment, or some cases of violation. As a result, when "true" indicates fulfillment it may be that "false" is unconclusive, or conversely "false" will indicate violation, but "true" is unconclusive. In such cases, the "Reporting" element specifies the meaning of the predicate result w/r to the profile requirement. The predicate expression implicitly refers to the target (whic is its "XPath context") although it may explicitly refer to it using the variable name "$target". It may refer to any cotarget using its name as variable name ($[name]). |
Prescription: |
[markup: testAssertion/prescription/@level ] (required) Conveys the level of prescription associated with the profile requirement. At least three values may be used:
|
Reporting: |
[markup: testAssertion/reporting ] (optional) For each possible outcome of the predicate (true or false), specifies how it must be interpreted w/r to the profile feature. Two attributes are used that both must be present, when this element is present:
NOTES: the predicate of the TA may be worded in a negative way so that @false='passed' although that is not recommended. The result of a test should not be related to the prescription level, e.g. a "preferred" or "permitted" level should not imply that @false='warning'. Other test results that are automatically generated and not controlled by the "reporting" element are:
|
Test Assertion Analysis: | RSP1002b |
---|---|
General Notes: | |
Coverage Assessment: | partial: |
Target Type: | ENVELOPE |
Test Target: | |
Test co-Target(s): | |
Test Prerequisite: | |
Predicate: | |
Prescription: | mandatory |
Reporting: | true=passed, false=failed |
Test Control: |
Test Assertion: | RSP1002b |
---|---|
Description: | |
Target: |
|
co-Target: myOpBinding |
|
Predicate: |
|
Reporting: | true=passed, false=failed |
Prescription: | mandatory |
Error Message: | A SOAP Envelope with an WSDL doc-lit binding, and for which the use of a SecurityContextToken was required, did not contain a wssc:SecurityContextToken header. |
Diagnostic Data: |
|
Test Assertion Part | What it means: |
---|---|
Test Assertion ID: |
[markup: testAssertion/@id] (required) A unique ID for the current test assertion. |
Description: |
[markup: testAssertion/description ] (optional) A plain text description of the current test assertion. At minimum expressing the TA predicate. |
Comments: |
[markup: testAssertion/comments ] (optional) A plain text comment about the TA script and how well it covers the profile requirement. Explanation material for users, and developers (what could be improved, etc.). |
Target: |
[markup: testAssertion/target ] (required) The artifacts to be tested, defined by an XPath expression that returns a list of XML nodes from the log file in input. For every artifact (node) selected by the Target expression, there will be a report entry for this TA in the test report, with a result of either:
See the "reporting" item for the meaning of these results. |
Cotarget: |
[markup: testAssertion/cotarget ] (optional) Artifact that is related to the target, and that needs be accessed for the testing. Identified by an XPath expression that may refer to the related target node using the variable '$target'. For example, the target can be a SOAP message and the cotarget the WSDL file that describes this SOAP message. A cotarget must have a @name attribute that identifies it. The value of this attribute can be used as a variable (when prepending '$' to it) by subsequently defined cotargets, prerequisite and predicate. |
Prerequisite: |
[markup: testAssertion/@preReq ] (optional) [markup: testAssertion/prerequisite ] (optional) The pre-condition for evaluating this Test Assertion on this target. If the prerequisite evaluates to "false" then the target does not qualify for this Test Assertion (the test report is "notRelevant") The first part (preReq attribute) is an enumeration of Test Assertion IDs. Each one of the prerequisite TAs must either use the same target (e.g. SOAP Envelope, or WSDL binding, etc.) as this TA, or a target that is of a more general type than the main TA target. The target must "pass" each one of these prerequisite TAs in order to qualify for this TA. (e.g. the target of TA t1 can be a WSDL binding while the target of a TA t2 prerequisite of t1, can be the entire WSDL file). The second part ("prerequisite" element) is an XPath (boolean) expression of the same nature as the predicate. If present, it must evaluate to "true" for the target to qualify. If it fails, the result for the current TA in the report will be "notRelevant". Otherwise, the target can be further evaluated by the predicate of the main TA. The expression may refer to the target explicitly using the variable name "$target", or to any cotarget using its name as variable name ($[name]). |
Predicate: |
[markup: testAssertion/predicate] required element] A logical expression that evaluates whether this target is fulfilling the profile requirement addressed by this test Assertion. By default: - A result of true means the requirement is fulfilled (reported as a "passed" in the test report).- A result of false means the requirement is violated (reported as a "failed" in the test report). However, in some cases and for testability reasons, the predicate may be designed as a partial indicator e.g. only indicates some cases of fulfillment, or some cases of violation. As a result, when "true" indicates fulfillment it may be that "false" is unconclusive, or conversely "false" will indicate violation, but "true" is unconclusive. In such cases, the "Reporting" element specifies the meaning of the predicate result w/r to the profile requirement. The predicate expression implicitly refers to the target (whic is its "XPath context") although it may explicitly refer to it using the variable name "$target". It may refer to any cotarget using its name as variable name ($[name]). |
Prescription: |
[markup: testAssertion/prescription/@level ] (required) Conveys the level of prescription associated with the profile requirement. At least three values may be used:
|
Reporting: |
[markup: testAssertion/reporting ] (optional) For each possible outcome of the predicate (true or false), specifies how it must be interpreted w/r to the profile feature. Two attributes are used that both must be present, when this element is present:
NOTES: the predicate of the TA may be worded in a negative way so that @false='passed' although that is not recommended. The result of a test should not be related to the prescription level, e.g. a "preferred" or "permitted" level should not imply that @false='warning'. Other test results that are automatically generated and not controlled by the "reporting" element are:
|
R1003 If an endpoint requires or supports the use of WS-SecureConversation, the corresponding INSTANCE MUST behave in accordance with Section 4 of this Profile. NOT_TESTABLE
Note that two RSP compliant web services implementations might both support the use of WS-SecureConversation yet fail to agree on a common set of features necessary to interact with one another. For example, a service might require the use of a particular cipher suite that a client is not equipped to support.
WS-SecureConversation (WS-SC) describes a set of bindings of WS-Trust for amending, renewing, and canceling security contexts. WS-SC does not define whether support for these bindings is mandatory or optional, for either clients or services. This creates the potential for interoperability problems due to differing expectations about such support. The following requirements clarify the optionality of the SCT Amend, Renew, and Cancel bindings.
As of the date of this Profile, there are no known implementations of WS-SC that support the SCT Amend binding. CONSUMERS are advised to avoid its use unless they are certain that the target INSTANCE supports it.
R1004 A CONSUMER SHOULD NOT send an ENVELOPE
containing a wst:RequestSecurityToken
in the SOAP Body
and an action URI of
http://docs.oasis-open.org/ws-sx/ws-trust/200512/RST/SCT/Amend
.
TESTABLE RSP1004
Test Assertion: | RSP1004 |
---|---|
Description: | This assertion checks for the use of the WS-SC Amend binding and logs a warning. |
Target: |
|
Predicate: |
|
Reporting: | true=passed, false=warning |
Prescription: | preferred |
Error Message: | The request uses the SCT Amend binding. Verify that the service supports this binding. |
Diagnostic Data: |
|
Test Assertion Part | What it means: |
---|---|
Test Assertion ID: |
[markup: testAssertion/@id] (required) A unique ID for the current test assertion. |
Description: |
[markup: testAssertion/description ] (optional) A plain text description of the current test assertion. At minimum expressing the TA predicate. |
Comments: |
[markup: testAssertion/comments ] (optional) A plain text comment about the TA script and how well it covers the profile requirement. Explanation material for users, and developers (what could be improved, etc.). |
Target: |
[markup: testAssertion/target ] (required) The artifacts to be tested, defined by an XPath expression that returns a list of XML nodes from the log file in input. For every artifact (node) selected by the Target expression, there will be a report entry for this TA in the test report, with a result of either:
See the "reporting" item for the meaning of these results. |
Cotarget: |
[markup: testAssertion/cotarget ] (optional) Artifact that is related to the target, and that needs be accessed for the testing. Identified by an XPath expression that may refer to the related target node using the variable '$target'. For example, the target can be a SOAP message and the cotarget the WSDL file that describes this SOAP message. A cotarget must have a @name attribute that identifies it. The value of this attribute can be used as a variable (when prepending '$' to it) by subsequently defined cotargets, prerequisite and predicate. |
Prerequisite: |
[markup: testAssertion/@preReq ] (optional) [markup: testAssertion/prerequisite ] (optional) The pre-condition for evaluating this Test Assertion on this target. If the prerequisite evaluates to "false" then the target does not qualify for this Test Assertion (the test report is "notRelevant") The first part (preReq attribute) is an enumeration of Test Assertion IDs. Each one of the prerequisite TAs must either use the same target (e.g. SOAP Envelope, or WSDL binding, etc.) as this TA, or a target that is of a more general type than the main TA target. The target must "pass" each one of these prerequisite TAs in order to qualify for this TA. (e.g. the target of TA t1 can be a WSDL binding while the target of a TA t2 prerequisite of t1, can be the entire WSDL file). The second part ("prerequisite" element) is an XPath (boolean) expression of the same nature as the predicate. If present, it must evaluate to "true" for the target to qualify. If it fails, the result for the current TA in the report will be "notRelevant". Otherwise, the target can be further evaluated by the predicate of the main TA. The expression may refer to the target explicitly using the variable name "$target", or to any cotarget using its name as variable name ($[name]). |
Predicate: |
[markup: testAssertion/predicate] required element] A logical expression that evaluates whether this target is fulfilling the profile requirement addressed by this test Assertion. By default: - A result of true means the requirement is fulfilled (reported as a "passed" in the test report).- A result of false means the requirement is violated (reported as a "failed" in the test report). However, in some cases and for testability reasons, the predicate may be designed as a partial indicator e.g. only indicates some cases of fulfillment, or some cases of violation. As a result, when "true" indicates fulfillment it may be that "false" is unconclusive, or conversely "false" will indicate violation, but "true" is unconclusive. In such cases, the "Reporting" element specifies the meaning of the predicate result w/r to the profile requirement. The predicate expression implicitly refers to the target (whic is its "XPath context") although it may explicitly refer to it using the variable name "$target". It may refer to any cotarget using its name as variable name ($[name]). |
Prescription: |
[markup: testAssertion/prescription/@level ] (required) Conveys the level of prescription associated with the profile requirement. At least three values may be used:
|
Reporting: |
[markup: testAssertion/reporting ] (optional) For each possible outcome of the predicate (true or false), specifies how it must be interpreted w/r to the profile feature. Two attributes are used that both must be present, when this element is present:
NOTES: the predicate of the TA may be worded in a negative way so that @false='passed' although that is not recommended. The result of a test should not be related to the prescription level, e.g. a "preferred" or "permitted" level should not imply that @false='warning'. Other test results that are automatically generated and not controlled by the "reporting" element are:
|
Support for the SCT Renew binding is elective for both CONSUMERs and INSTANCEs.
R1005 An INSTANCE that acts as a WS-SC security
token service MAY process ENVELOPEs containing a
wst:RequestSecurityToken
in the SOAP Body and an
action URI of
http://docs.oasis-open.org/ws-sx/ws-trust/200512/RST/SCT/Renew
as per Section 5 of WS-SecureConversation.
NOT_TESTABLE
R1006 An INSTANCE that acts as a WS-SC security
token service but does not process ENVELOPEs containing a
wst:RequestSecurityToken
in the SOAP Body and an
action URI of
http://docs.oasis-open.org/ws-sx/ws-trust/200512/RST/SCT/Renew
as per Section 5 of WS-SecureConversation MUST
generate a fault with a [Subcode] value of
"wsa:ActionNotSupported
" (as per Section 6.4.4 of WS-Addressing 1.0 SOAP
Binding) upon receiving a MESSAGE containing such an ENVELOPE.
TESTABLE RSP1006a RSP1006b
Test Assertion: | RSP1006a |
---|---|
Description: | This assertion examines the response to an SCT/Renew request and, if that response is not a fault, makes sure that it meets the basic criteria of a "proper" response (as defined by WS-SC). |
Target: |
|
co-Target: myresponse |
(@type = 'response' and @conversation = $target/../../@conversation) or (.//*:Envelope/*:Header/wsa:RelatesTo[@RelationshipType = 'http://www.w3.org/2005/08/addressing/reply' or not (@RelationshipType)] = $target/*:Header/wsa:MessageID) ] /wsil:messageContents/*:Envelope |
Prerequisite: |
|
Predicate: |
|
Reporting: | true=passed, false=failed |
Prescription: | mandatory |
Error Message: | The service responded to a request to renew a security context with something other than the correct response. |
Diagnostic Data: |
|
Test Assertion Part | What it means: |
---|---|
Test Assertion ID: |
[markup: testAssertion/@id] (required) A unique ID for the current test assertion. |
Description: |
[markup: testAssertion/description ] (optional) A plain text description of the current test assertion. At minimum expressing the TA predicate. |
Comments: |
[markup: testAssertion/comments ] (optional) A plain text comment about the TA script and how well it covers the profile requirement. Explanation material for users, and developers (what could be improved, etc.). |
Target: |
[markup: testAssertion/target ] (required) The artifacts to be tested, defined by an XPath expression that returns a list of XML nodes from the log file in input. For every artifact (node) selected by the Target expression, there will be a report entry for this TA in the test report, with a result of either:
See the "reporting" item for the meaning of these results. |
Cotarget: |
[markup: testAssertion/cotarget ] (optional) Artifact that is related to the target, and that needs be accessed for the testing. Identified by an XPath expression that may refer to the related target node using the variable '$target'. For example, the target can be a SOAP message and the cotarget the WSDL file that describes this SOAP message. A cotarget must have a @name attribute that identifies it. The value of this attribute can be used as a variable (when prepending '$' to it) by subsequently defined cotargets, prerequisite and predicate. |
Prerequisite: |
[markup: testAssertion/@preReq ] (optional) [markup: testAssertion/prerequisite ] (optional) The pre-condition for evaluating this Test Assertion on this target. If the prerequisite evaluates to "false" then the target does not qualify for this Test Assertion (the test report is "notRelevant") The first part (preReq attribute) is an enumeration of Test Assertion IDs. Each one of the prerequisite TAs must either use the same target (e.g. SOAP Envelope, or WSDL binding, etc.) as this TA, or a target that is of a more general type than the main TA target. The target must "pass" each one of these prerequisite TAs in order to qualify for this TA. (e.g. the target of TA t1 can be a WSDL binding while the target of a TA t2 prerequisite of t1, can be the entire WSDL file). The second part ("prerequisite" element) is an XPath (boolean) expression of the same nature as the predicate. If present, it must evaluate to "true" for the target to qualify. If it fails, the result for the current TA in the report will be "notRelevant". Otherwise, the target can be further evaluated by the predicate of the main TA. The expression may refer to the target explicitly using the variable name "$target", or to any cotarget using its name as variable name ($[name]). |
Predicate: |
[markup: testAssertion/predicate] required element] A logical expression that evaluates whether this target is fulfilling the profile requirement addressed by this test Assertion. By default: - A result of true means the requirement is fulfilled (reported as a "passed" in the test report).- A result of false means the requirement is violated (reported as a "failed" in the test report). However, in some cases and for testability reasons, the predicate may be designed as a partial indicator e.g. only indicates some cases of fulfillment, or some cases of violation. As a result, when "true" indicates fulfillment it may be that "false" is unconclusive, or conversely "false" will indicate violation, but "true" is unconclusive. In such cases, the "Reporting" element specifies the meaning of the predicate result w/r to the profile requirement. The predicate expression implicitly refers to the target (whic is its "XPath context") although it may explicitly refer to it using the variable name "$target". It may refer to any cotarget using its name as variable name ($[name]). |
Prescription: |
[markup: testAssertion/prescription/@level ] (required) Conveys the level of prescription associated with the profile requirement. At least three values may be used:
|
Reporting: |
[markup: testAssertion/reporting ] (optional) For each possible outcome of the predicate (true or false), specifies how it must be interpreted w/r to the profile feature. Two attributes are used that both must be present, when this element is present:
NOTES: the predicate of the TA may be worded in a negative way so that @false='passed' although that is not recommended. The result of a test should not be related to the prescription level, e.g. a "preferred" or "permitted" level should not imply that @false='warning'. Other test results that are automatically generated and not controlled by the "reporting" element are:
|
Test Assertion: | RSP1006b |
---|---|
Description: | This assertion examines the response to an SCT/Renew request and, if that response is fault, makes sure that it is a wsa:ActionNotSupported fault. Because there are many reasons for a fault to be generated, this assertion only logs a warning in case the fault had some other cause than the services inability to support SCT/Renew. |
Target: |
|
co-Target: myresponse |
(@type = 'response' and @conversation = $target/../../@conversation) or (.//*:Envelope/*:Header/wsa:RelatesTo[@RelationshipType = 'http://www.w3.org/2005/08/addressing/reply' or not (@RelationshipType)] = $target/*:Header/wsa:MessageID) ] /wsil:messageContents/*:Envelope |
Prerequisite: |
|
Predicate: |
then ( fn:ends-with($myresponse/soap11:Body/soap11:Fault/faultcode, 'ActionNotSupported') ) else ( fn:ends-with($myresponse/soap12:Body/soap12:Fault/soap12:Code/soap12:Value, 'Sender') and fn:ends-with($target/soap12:Body/soap12:Fault/soap12:Code/soap12:Subcode/soap12:Value, 'ActionNotSupported') ) ) |
Reporting: | true=passed, false=warning |
Prescription: | mandatory |
Error Message: | A request to renew a security context received a fault response other than "wsa:ActionNotSupported". This could be due to some problem with the request, some problem with the service, or it could be due to incorrect error reporting behavior on the part of the service. If the service is attempting to indicate that it does not support the WS-SC Renew operation via some other fault than the wsa:ActionNotSupported fault, it is non-conformant with R1006 of RSP 1.0. |
Diagnostic Data: |
|
Test Assertion Part | What it means: |
---|---|
Test Assertion ID: |
[markup: testAssertion/@id] (required) A unique ID for the current test assertion. |
Description: |
[markup: testAssertion/description ] (optional) A plain text description of the current test assertion. At minimum expressing the TA predicate. |
Comments: |
[markup: testAssertion/comments ] (optional) A plain text comment about the TA script and how well it covers the profile requirement. Explanation material for users, and developers (what could be improved, etc.). |
Target: |
[markup: testAssertion/target ] (required) The artifacts to be tested, defined by an XPath expression that returns a list of XML nodes from the log file in input. For every artifact (node) selected by the Target expression, there will be a report entry for this TA in the test report, with a result of either:
See the "reporting" item for the meaning of these results. |
Cotarget: |
[markup: testAssertion/cotarget ] (optional) Artifact that is related to the target, and that needs be accessed for the testing. Identified by an XPath expression that may refer to the related target node using the variable '$target'. For example, the target can be a SOAP message and the cotarget the WSDL file that describes this SOAP message. A cotarget must have a @name attribute that identifies it. The value of this attribute can be used as a variable (when prepending '$' to it) by subsequently defined cotargets, prerequisite and predicate. |
Prerequisite: |
[markup: testAssertion/@preReq ] (optional) [markup: testAssertion/prerequisite ] (optional) The pre-condition for evaluating this Test Assertion on this target. If the prerequisite evaluates to "false" then the target does not qualify for this Test Assertion (the test report is "notRelevant") The first part (preReq attribute) is an enumeration of Test Assertion IDs. Each one of the prerequisite TAs must either use the same target (e.g. SOAP Envelope, or WSDL binding, etc.) as this TA, or a target that is of a more general type than the main TA target. The target must "pass" each one of these prerequisite TAs in order to qualify for this TA. (e.g. the target of TA t1 can be a WSDL binding while the target of a TA t2 prerequisite of t1, can be the entire WSDL file). The second part ("prerequisite" element) is an XPath (boolean) expression of the same nature as the predicate. If present, it must evaluate to "true" for the target to qualify. If it fails, the result for the current TA in the report will be "notRelevant". Otherwise, the target can be further evaluated by the predicate of the main TA. The expression may refer to the target explicitly using the variable name "$target", or to any cotarget using its name as variable name ($[name]). |
Predicate: |
[markup: testAssertion/predicate] required element] A logical expression that evaluates whether this target is fulfilling the profile requirement addressed by this test Assertion. By default: - A result of true means the requirement is fulfilled (reported as a "passed" in the test report).- A result of false means the requirement is violated (reported as a "failed" in the test report). However, in some cases and for testability reasons, the predicate may be designed as a partial indicator e.g. only indicates some cases of fulfillment, or some cases of violation. As a result, when "true" indicates fulfillment it may be that "false" is unconclusive, or conversely "false" will indicate violation, but "true" is unconclusive. In such cases, the "Reporting" element specifies the meaning of the predicate result w/r to the profile requirement. The predicate expression implicitly refers to the target (whic is its "XPath context") although it may explicitly refer to it using the variable name "$target". It may refer to any cotarget using its name as variable name ($[name]). |
Prescription: |
[markup: testAssertion/prescription/@level ] (required) Conveys the level of prescription associated with the profile requirement. At least three values may be used:
|
Reporting: |
[markup: testAssertion/reporting ] (optional) For each possible outcome of the predicate (true or false), specifies how it must be interpreted w/r to the profile feature. Two attributes are used that both must be present, when this element is present:
NOTES: the predicate of the TA may be worded in a negative way so that @false='passed' although that is not recommended. The result of a test should not be related to the prescription level, e.g. a "preferred" or "permitted" level should not imply that @false='warning'. Other test results that are automatically generated and not controlled by the "reporting" element are:
|
Support for the SCT Cancel binding is mandatory for INSTANCEs and elective for CONSUMERs.
R1007 An INSTANCE that acts as a WS-SC security
token service MUST process ENVELOPEs containing a
wst:RequestSecurityToken
in the SOAP Body and an
action URI of
http://docs.oasis-open.org/ws-sx/ws-trust/200512/RST/SCT/Cancel
as per Section 6 of WS-SecureConversation.
TESTABLE RSP1007a RSP1007b
Test Assertion: | RSP1007a |
---|---|
Description: | This assertion examines the response to an SCT/Cancel request and checks for the wsa:ActionNotSupported fault response. Such a fault unambiguously indicates that the SCT/Cancel binding is NOT supported by the service, which violates R1007. This assertion assumes that the client is trasmitting the SCT/Cancel request to the appropriate endpoint i.e. that the service is acting as a security token service. |
Target: |
|
co-Target: myresponse |
(@type = 'response' and @conversation = $target/../../@conversation) or (.//*:Envelope/*:Header/wsa:RelatesTo[@RelationshipType = 'http://www.w3.org/2005/08/addressing/reply' or not (@RelationshipType)] = $target/*:Header/wsa:MessageID) ] /wsil:messageContents/*:Envelope |
Predicate: |
then ( fn:ends-with($myresponse/soap11:Body/soap11:Fault/faultcode, 'ActionNotSupported') ) else ( fn:ends-with($myresponse/soap12:Body/soap12:Fault/soap12:Code/soap12:Value, 'Sender') and fn:ends-with($myresponse/soap12:Body/soap12:Fault/soap12:Code/soap12:Subcode/soap12:Value, 'ActionNotSupported') ) ) ) |
Reporting: | true=passed, false=failed |
Prescription: | mandatory |
Error Message: | A request to cancel a security context received a wsa:ActionNotSupported fault response, which indicates that the SCT/Cancel binding is not supported by the service. This indicates that the service does not conform to R1007 of RSP 1.0. |
Diagnostic Data: |
|
Test Assertion Part | What it means: |
---|---|
Test Assertion ID: |
[markup: testAssertion/@id] (required) A unique ID for the current test assertion. |
Description: |
[markup: testAssertion/description ] (optional) A plain text description of the current test assertion. At minimum expressing the TA predicate. |
Comments: |
[markup: testAssertion/comments ] (optional) A plain text comment about the TA script and how well it covers the profile requirement. Explanation material for users, and developers (what could be improved, etc.). |
Target: |
[markup: testAssertion/target ] (required) The artifacts to be tested, defined by an XPath expression that returns a list of XML nodes from the log file in input. For every artifact (node) selected by the Target expression, there will be a report entry for this TA in the test report, with a result of either:
See the "reporting" item for the meaning of these results. |
Cotarget: |
[markup: testAssertion/cotarget ] (optional) Artifact that is related to the target, and that needs be accessed for the testing. Identified by an XPath expression that may refer to the related target node using the variable '$target'. For example, the target can be a SOAP message and the cotarget the WSDL file that describes this SOAP message. A cotarget must have a @name attribute that identifies it. The value of this attribute can be used as a variable (when prepending '$' to it) by subsequently defined cotargets, prerequisite and predicate. |
Prerequisite: |
[markup: testAssertion/@preReq ] (optional) [markup: testAssertion/prerequisite ] (optional) The pre-condition for evaluating this Test Assertion on this target. If the prerequisite evaluates to "false" then the target does not qualify for this Test Assertion (the test report is "notRelevant") The first part (preReq attribute) is an enumeration of Test Assertion IDs. Each one of the prerequisite TAs must either use the same target (e.g. SOAP Envelope, or WSDL binding, etc.) as this TA, or a target that is of a more general type than the main TA target. The target must "pass" each one of these prerequisite TAs in order to qualify for this TA. (e.g. the target of TA t1 can be a WSDL binding while the target of a TA t2 prerequisite of t1, can be the entire WSDL file). The second part ("prerequisite" element) is an XPath (boolean) expression of the same nature as the predicate. If present, it must evaluate to "true" for the target to qualify. If it fails, the result for the current TA in the report will be "notRelevant". Otherwise, the target can be further evaluated by the predicate of the main TA. The expression may refer to the target explicitly using the variable name "$target", or to any cotarget using its name as variable name ($[name]). |
Predicate: |
[markup: testAssertion/predicate] required element] A logical expression that evaluates whether this target is fulfilling the profile requirement addressed by this test Assertion. By default: - A result of true means the requirement is fulfilled (reported as a "passed" in the test report).- A result of false means the requirement is violated (reported as a "failed" in the test report). However, in some cases and for testability reasons, the predicate may be designed as a partial indicator e.g. only indicates some cases of fulfillment, or some cases of violation. As a result, when "true" indicates fulfillment it may be that "false" is unconclusive, or conversely "false" will indicate violation, but "true" is unconclusive. In such cases, the "Reporting" element specifies the meaning of the predicate result w/r to the profile requirement. The predicate expression implicitly refers to the target (whic is its "XPath context") although it may explicitly refer to it using the variable name "$target". It may refer to any cotarget using its name as variable name ($[name]). |
Prescription: |
[markup: testAssertion/prescription/@level ] (required) Conveys the level of prescription associated with the profile requirement. At least three values may be used:
|
Reporting: |
[markup: testAssertion/reporting ] (optional) For each possible outcome of the predicate (true or false), specifies how it must be interpreted w/r to the profile feature. Two attributes are used that both must be present, when this element is present:
NOTES: the predicate of the TA may be worded in a negative way so that @false='passed' although that is not recommended. The result of a test should not be related to the prescription level, e.g. a "preferred" or "permitted" level should not imply that @false='warning'. Other test results that are automatically generated and not controlled by the "reporting" element are:
|
Test Assertion: | RSP1007b |
---|---|
Description: | This assertion examines the response to an SCT/Cancel request and checks for the appropriate, WS-SC-defined response. The lack of such a response might indicate that the service does not support the SCT/Cancel binding, which would violate R1007. This assertion assumes that the client is trasmitting the SCT/Cancel request to the appropriate endpoint i.e. that the service is acting as a security token service. It also relies on RSP1007a as a prerequisite. This avoids double-reporting the behavior that RSP1007a checks for. |
Target: |
|
co-Target: myresponse |
(@type = 'response' and @conversation = $target/../../@conversation) or (.//*:Envelope/*:Header/wsa:RelatesTo[@RelationshipType = 'http://www.w3.org/2005/08/addressing/reply' or not (@RelationshipType)] = $target/*:Header/wsa:MessageID) ] /wsil:messageContents/*:Envelope |
Prerequisite: | RSP1007a |
Predicate: |
|
Reporting: | true=passed, false=warning |
Prescription: | mandatory |
Error Message: | A request to cancel a security context did not receive the appropriate response. This might indicate that the service does not support the SCT/Cancel binding, which would violate R1007 of RSP 1.0. Check the response to determine if it is the result of some problem other than the services inability to support the SCT/Cancel binding. |
Diagnostic Data: |
|
Test Assertion Part | What it means: |
---|---|
Test Assertion ID: |
[markup: testAssertion/@id] (required) A unique ID for the current test assertion. |
Description: |
[markup: testAssertion/description ] (optional) A plain text description of the current test assertion. At minimum expressing the TA predicate. |
Comments: |
[markup: testAssertion/comments ] (optional) A plain text comment about the TA script and how well it covers the profile requirement. Explanation material for users, and developers (what could be improved, etc.). |
Target: |
[markup: testAssertion/target ] (required) The artifacts to be tested, defined by an XPath expression that returns a list of XML nodes from the log file in input. For every artifact (node) selected by the Target expression, there will be a report entry for this TA in the test report, with a result of either:
See the "reporting" item for the meaning of these results. |
Cotarget: |
[markup: testAssertion/cotarget ] (optional) Artifact that is related to the target, and that needs be accessed for the testing. Identified by an XPath expression that may refer to the related target node using the variable '$target'. For example, the target can be a SOAP message and the cotarget the WSDL file that describes this SOAP message. A cotarget must have a @name attribute that identifies it. The value of this attribute can be used as a variable (when prepending '$' to it) by subsequently defined cotargets, prerequisite and predicate. |
Prerequisite: |
[markup: testAssertion/@preReq ] (optional) [markup: testAssertion/prerequisite ] (optional) The pre-condition for evaluating this Test Assertion on this target. If the prerequisite evaluates to "false" then the target does not qualify for this Test Assertion (the test report is "notRelevant") The first part (preReq attribute) is an enumeration of Test Assertion IDs. Each one of the prerequisite TAs must either use the same target (e.g. SOAP Envelope, or WSDL binding, etc.) as this TA, or a target that is of a more general type than the main TA target. The target must "pass" each one of these prerequisite TAs in order to qualify for this TA. (e.g. the target of TA t1 can be a WSDL binding while the target of a TA t2 prerequisite of t1, can be the entire WSDL file). The second part ("prerequisite" element) is an XPath (boolean) expression of the same nature as the predicate. If present, it must evaluate to "true" for the target to qualify. If it fails, the result for the current TA in the report will be "notRelevant". Otherwise, the target can be further evaluated by the predicate of the main TA. The expression may refer to the target explicitly using the variable name "$target", or to any cotarget using its name as variable name ($[name]). |
Predicate: |
[markup: testAssertion/predicate] required element] A logical expression that evaluates whether this target is fulfilling the profile requirement addressed by this test Assertion. By default: - A result of true means the requirement is fulfilled (reported as a "passed" in the test report).- A result of false means the requirement is violated (reported as a "failed" in the test report). However, in some cases and for testability reasons, the predicate may be designed as a partial indicator e.g. only indicates some cases of fulfillment, or some cases of violation. As a result, when "true" indicates fulfillment it may be that "false" is unconclusive, or conversely "false" will indicate violation, but "true" is unconclusive. In such cases, the "Reporting" element specifies the meaning of the predicate result w/r to the profile requirement. The predicate expression implicitly refers to the target (whic is its "XPath context") although it may explicitly refer to it using the variable name "$target". It may refer to any cotarget using its name as variable name ($[name]). |
Prescription: |
[markup: testAssertion/prescription/@level ] (required) Conveys the level of prescription associated with the profile requirement. At least three values may be used:
|
Reporting: |
[markup: testAssertion/reporting ] (optional) For each possible outcome of the predicate (true or false), specifies how it must be interpreted w/r to the profile feature. Two attributes are used that both must be present, when this element is present:
NOTES: the predicate of the TA may be worded in a negative way so that @false='passed' although that is not recommended. The result of a test should not be related to the prescription level, e.g. a "preferred" or "permitted" level should not imply that @false='warning'. Other test results that are automatically generated and not controlled by the "reporting" element are:
|
R1008 When a CONSUMER concludes its use of a security
context it SHOULD transmit an ENVELOPE containing a
wst:RequestSecurityToken
in the SOAP Body and an
action URI of
http://docs.oasis-open.org/ws-sx/ws-trust/200512/RST/SCT/Cancel
to the WS-SC security token service that issued the SCT for that
context. TESTABLE RSP1008
Test Assertion: | RSP1008 |
---|---|
Description: | This assertion checks for the presence of an SCT request and checks for the corresponding SCT/Cancel. The lack of an SCT/Cancel indicates either that the log file did not capture all of the messages in the interaction between the client and server, or that the client simply neglected to send a SCT/Cancel request. The latter indicates a issue with R1008, which states that clients SHOULD cancel their security contexts. |
Target: |
|
Predicate: |
|
Reporting: | true=passed, false=warning |
Prescription: | preferred |
Error Message: | A client requested and obtained a security context that it never subsequently canceled. Verify that the log contains a complete record of the clients interaction with the service and that the cancel request was not missed. If the log is complete and there are no missing messages, the fact that the client did not cancel the security context both increases the risk of that security context being compromised and consumes additional resources on the service. |
Diagnostic Data: |
|
Test Assertion Part | What it means: |
---|---|
Test Assertion ID: |
[markup: testAssertion/@id] (required) A unique ID for the current test assertion. |
Description: |
[markup: testAssertion/description ] (optional) A plain text description of the current test assertion. At minimum expressing the TA predicate. |
Comments: |
[markup: testAssertion/comments ] (optional) A plain text comment about the TA script and how well it covers the profile requirement. Explanation material for users, and developers (what could be improved, etc.). |
Target: |
[markup: testAssertion/target ] (required) The artifacts to be tested, defined by an XPath expression that returns a list of XML nodes from the log file in input. For every artifact (node) selected by the Target expression, there will be a report entry for this TA in the test report, with a result of either:
See the "reporting" item for the meaning of these results. |
Cotarget: |
[markup: testAssertion/cotarget ] (optional) Artifact that is related to the target, and that needs be accessed for the testing. Identified by an XPath expression that may refer to the related target node using the variable '$target'. For example, the target can be a SOAP message and the cotarget the WSDL file that describes this SOAP message. A cotarget must have a @name attribute that identifies it. The value of this attribute can be used as a variable (when prepending '$' to it) by subsequently defined cotargets, prerequisite and predicate. |
Prerequisite: |
[markup: testAssertion/@preReq ] (optional) [markup: testAssertion/prerequisite ] (optional) The pre-condition for evaluating this Test Assertion on this target. If the prerequisite evaluates to "false" then the target does not qualify for this Test Assertion (the test report is "notRelevant") The first part (preReq attribute) is an enumeration of Test Assertion IDs. Each one of the prerequisite TAs must either use the same target (e.g. SOAP Envelope, or WSDL binding, etc.) as this TA, or a target that is of a more general type than the main TA target. The target must "pass" each one of these prerequisite TAs in order to qualify for this TA. (e.g. the target of TA t1 can be a WSDL binding while the target of a TA t2 prerequisite of t1, can be the entire WSDL file). The second part ("prerequisite" element) is an XPath (boolean) expression of the same nature as the predicate. If present, it must evaluate to "true" for the target to qualify. If it fails, the result for the current TA in the report will be "notRelevant". Otherwise, the target can be further evaluated by the predicate of the main TA. The expression may refer to the target explicitly using the variable name "$target", or to any cotarget using its name as variable name ($[name]). |
Predicate: |
[markup: testAssertion/predicate] required element] A logical expression that evaluates whether this target is fulfilling the profile requirement addressed by this test Assertion. By default: - A result of true means the requirement is fulfilled (reported as a "passed" in the test report).- A result of false means the requirement is violated (reported as a "failed" in the test report). However, in some cases and for testability reasons, the predicate may be designed as a partial indicator e.g. only indicates some cases of fulfillment, or some cases of violation. As a result, when "true" indicates fulfillment it may be that "false" is unconclusive, or conversely "false" will indicate violation, but "true" is unconclusive. In such cases, the "Reporting" element specifies the meaning of the predicate result w/r to the profile requirement. The predicate expression implicitly refers to the target (whic is its "XPath context") although it may explicitly refer to it using the variable name "$target". It may refer to any cotarget using its name as variable name ($[name]). |
Prescription: |
[markup: testAssertion/prescription/@level ] (required) Conveys the level of prescription associated with the profile requirement. At least three values may be used:
|
Reporting: |
[markup: testAssertion/reporting ] (optional) For each possible outcome of the predicate (true or false), specifies how it must be interpreted w/r to the profile feature. Two attributes are used that both must be present, when this element is present:
NOTES: the predicate of the TA may be worded in a negative way so that @false='passed' although that is not recommended. The result of a test should not be related to the prescription level, e.g. a "preferred" or "permitted" level should not imply that @false='warning'. Other test results that are automatically generated and not controlled by the "reporting" element are:
|
During the establishment of a security context, it is possible for a participant to obtain an SCT that, for some reason, it chooses not to accept. One such possible reason is the presence of unrecognized extensions which, by definition, may indicate unknown and possibly harmful semantics. If the RECEIVER chooses to accept such an SCT, however, it must preserve this unrecognized content or nodes that understand and depend on this content may break.
R1000 A RECEIVER MAY not accept an SCT due to unrecognized extensions in exception to R0001.NOT_TESTED RSP1000
Test Assertion Analysis: | RSP1000 |
---|---|
General Notes: | NOTE1: We are not sure how to stimulate this fault. we might be able to send a particular token that we do not expect any service to (willingly) support. or we could send all of the type of well known tokens and report those that are not supported by a particular implementation report this specific fault. can test only those tokens we make up or know about (cannot test all potential custom tokens) |
Coverage Assessment: | Partial |
Target Type: | ENVELOPE (Fault) |
Test Target: | fault returned instead of response to unknown RST, (correlation done with wsa) |
Test co-Target(s): | |
Test Prerequisite: | |
Predicate: | Exists a Fault message that correlates, with faultcode=stated in requirement |
Prescription: | mandatory |
Reporting: | true=passed, false=warning |
Test Control: | generate (or MIM intercept and corrupt) RST that can't be supported. |
Test Assertion: | RSP1000 |
---|---|
Description: | |
Target: |
|
Predicate: |
|
Reporting: | true=passed, false=failed |
Prescription: | mandatory |
Error Message: | |
Diagnostic Data: |
|
Test Assertion Part | What it means: |
---|---|
Test Assertion ID: |
[markup: testAssertion/@id] (required) A unique ID for the current test assertion. |
Description: |
[markup: testAssertion/description ] (optional) A plain text description of the current test assertion. At minimum expressing the TA predicate. |
Comments: |
[markup: testAssertion/comments ] (optional) A plain text comment about the TA script and how well it covers the profile requirement. Explanation material for users, and developers (what could be improved, etc.). |
Target: |
[markup: testAssertion/target ] (required) The artifacts to be tested, defined by an XPath expression that returns a list of XML nodes from the log file in input. For every artifact (node) selected by the Target expression, there will be a report entry for this TA in the test report, with a result of either:
See the "reporting" item for the meaning of these results. |
Cotarget: |
[markup: testAssertion/cotarget ] (optional) Artifact that is related to the target, and that needs be accessed for the testing. Identified by an XPath expression that may refer to the related target node using the variable '$target'. For example, the target can be a SOAP message and the cotarget the WSDL file that describes this SOAP message. A cotarget must have a @name attribute that identifies it. The value of this attribute can be used as a variable (when prepending '$' to it) by subsequently defined cotargets, prerequisite and predicate. |
Prerequisite: |
[markup: testAssertion/@preReq ] (optional) [markup: testAssertion/prerequisite ] (optional) The pre-condition for evaluating this Test Assertion on this target. If the prerequisite evaluates to "false" then the target does not qualify for this Test Assertion (the test report is "notRelevant") The first part (preReq attribute) is an enumeration of Test Assertion IDs. Each one of the prerequisite TAs must either use the same target (e.g. SOAP Envelope, or WSDL binding, etc.) as this TA, or a target that is of a more general type than the main TA target. The target must "pass" each one of these prerequisite TAs in order to qualify for this TA. (e.g. the target of TA t1 can be a WSDL binding while the target of a TA t2 prerequisite of t1, can be the entire WSDL file). The second part ("prerequisite" element) is an XPath (boolean) expression of the same nature as the predicate. If present, it must evaluate to "true" for the target to qualify. If it fails, the result for the current TA in the report will be "notRelevant". Otherwise, the target can be further evaluated by the predicate of the main TA. The expression may refer to the target explicitly using the variable name "$target", or to any cotarget using its name as variable name ($[name]). |
Predicate: |
[markup: testAssertion/predicate] required element] A logical expression that evaluates whether this target is fulfilling the profile requirement addressed by this test Assertion. By default: - A result of true means the requirement is fulfilled (reported as a "passed" in the test report).- A result of false means the requirement is violated (reported as a "failed" in the test report). However, in some cases and for testability reasons, the predicate may be designed as a partial indicator e.g. only indicates some cases of fulfillment, or some cases of violation. As a result, when "true" indicates fulfillment it may be that "false" is unconclusive, or conversely "false" will indicate violation, but "true" is unconclusive. In such cases, the "Reporting" element specifies the meaning of the predicate result w/r to the profile requirement. The predicate expression implicitly refers to the target (whic is its "XPath context") although it may explicitly refer to it using the variable name "$target". It may refer to any cotarget using its name as variable name ($[name]). |
Prescription: |
[markup: testAssertion/prescription/@level ] (required) Conveys the level of prescription associated with the profile requirement. At least three values may be used:
|
Reporting: |
[markup: testAssertion/reporting ] (optional) For each possible outcome of the predicate (true or false), specifies how it must be interpreted w/r to the profile feature. Two attributes are used that both must be present, when this element is present:
NOTES: the predicate of the TA may be worded in a negative way so that @false='passed' although that is not recommended. The result of a test should not be related to the prescription level, e.g. a "preferred" or "permitted" level should not imply that @false='warning'. Other test results that are automatically generated and not controlled by the "reporting" element are:
|
R1001 If a RECEIVER obtains an SCT containing content it does not recognize, the RECEIVER MUST preserve this unrecognized content in all subsequent use of the token.TESTABLE_SCENARIO_DEPENDENT RSP1001
Test Assertion Analysis: | RSP1001 |
---|---|
General Notes: | This is a scenario-dependent TA: it only triggers on "non-recognized" content of a certain kind: element with a namespace = http://dummy.example.org/unknown/nmspace |
Coverage Assessment: | Good |
Target Type: | ENVELOPE |
Test Target: | For an Envelope with an SCT that has been obtained from a previous RSTR message, where the SCT did first appear with an unrecognizable content |
Test co-Target(s): | |
Test Prerequisite: | |
Predicate: | The used SCT still has the same unrecognizable content. |
Prescription: | mandatory |
Reporting: | true=pass, false=failed |
Test Control: | scenario to provide context. |
Test Assertion: | RSP1001 |
---|---|
Description: | |
Target: |
[ some $sct in *:Header//wssc:SecurityContextToken satisfies some $sct0 in /wsil:testLog/wsil:messageLog/wsil:message/wsil:messageContents/*:Envelope//wst:RequestSecurityTokenResponse//wssc:SecurityContextToken satisfies $sct0/wssc:Identifier = $sct/wssc:Identifier and (some $elt in $sct0//* satisfies string(fn:namespace-uri($elt)) = 'http://dummy.example.org/unknown/nmspace') ] |
Predicate: |
string(fn:namespace-uri($elt)) = 'http://dummy.example.org/unknown/nmspace' |
Reporting: | true=passed, false=failed |
Prescription: | mandatory |
Error Message: | An Envelope with an SCT that originally contained an unrecognizable content (with unrecognizable namespace: http://dummy.example.org/unknown/nmspace') has been stripped from this unrecognizable content when reused. |
Diagnostic Data: |
|
Test Assertion Part | What it means: |
---|---|
Test Assertion ID: |
[markup: testAssertion/@id] (required) A unique ID for the current test assertion. |
Description: |
[markup: testAssertion/description ] (optional) A plain text description of the current test assertion. At minimum expressing the TA predicate. |
Comments: |
[markup: testAssertion/comments ] (optional) A plain text comment about the TA script and how well it covers the profile requirement. Explanation material for users, and developers (what could be improved, etc.). |
Target: |
[markup: testAssertion/target ] (required) The artifacts to be tested, defined by an XPath expression that returns a list of XML nodes from the log file in input. For every artifact (node) selected by the Target expression, there will be a report entry for this TA in the test report, with a result of either:
See the "reporting" item for the meaning of these results. |
Cotarget: |
[markup: testAssertion/cotarget ] (optional) Artifact that is related to the target, and that needs be accessed for the testing. Identified by an XPath expression that may refer to the related target node using the variable '$target'. For example, the target can be a SOAP message and the cotarget the WSDL file that describes this SOAP message. A cotarget must have a @name attribute that identifies it. The value of this attribute can be used as a variable (when prepending '$' to it) by subsequently defined cotargets, prerequisite and predicate. |
Prerequisite: |
[markup: testAssertion/@preReq ] (optional) [markup: testAssertion/prerequisite ] (optional) The pre-condition for evaluating this Test Assertion on this target. If the prerequisite evaluates to "false" then the target does not qualify for this Test Assertion (the test report is "notRelevant") The first part (preReq attribute) is an enumeration of Test Assertion IDs. Each one of the prerequisite TAs must either use the same target (e.g. SOAP Envelope, or WSDL binding, etc.) as this TA, or a target that is of a more general type than the main TA target. The target must "pass" each one of these prerequisite TAs in order to qualify for this TA. (e.g. the target of TA t1 can be a WSDL binding while the target of a TA t2 prerequisite of t1, can be the entire WSDL file). The second part ("prerequisite" element) is an XPath (boolean) expression of the same nature as the predicate. If present, it must evaluate to "true" for the target to qualify. If it fails, the result for the current TA in the report will be "notRelevant". Otherwise, the target can be further evaluated by the predicate of the main TA. The expression may refer to the target explicitly using the variable name "$target", or to any cotarget using its name as variable name ($[name]). |
Predicate: |
[markup: testAssertion/predicate] required element] A logical expression that evaluates whether this target is fulfilling the profile requirement addressed by this test Assertion. By default: - A result of true means the requirement is fulfilled (reported as a "passed" in the test report).- A result of false means the requirement is violated (reported as a "failed" in the test report). However, in some cases and for testability reasons, the predicate may be designed as a partial indicator e.g. only indicates some cases of fulfillment, or some cases of violation. As a result, when "true" indicates fulfillment it may be that "false" is unconclusive, or conversely "false" will indicate violation, but "true" is unconclusive. In such cases, the "Reporting" element specifies the meaning of the predicate result w/r to the profile requirement. The predicate expression implicitly refers to the target (whic is its "XPath context") although it may explicitly refer to it using the variable name "$target". It may refer to any cotarget using its name as variable name ($[name]). |
Prescription: |
[markup: testAssertion/prescription/@level ] (required) Conveys the level of prescription associated with the profile requirement. At least three values may be used:
|
Reporting: |
[markup: testAssertion/reporting ] (optional) For each possible outcome of the predicate (true or false), specifies how it must be interpreted w/r to the profile feature. Two attributes are used that both must be present, when this element is present:
NOTES: the predicate of the TA may be worded in a negative way so that @false='passed' although that is not recommended. The result of a test should not be related to the prescription level, e.g. a "preferred" or "permitted" level should not imply that @false='warning'. Other test results that are automatically generated and not controlled by the "reporting" element are:
|
R1001 goes beyond R0001 (which does not require preservation of unrecognized content) to bring forward requirements from the WS-SecureConversation specification. R1000 has precedence over R1001 since an INSTANCE which faulted due to unrecognized content would not subsequently use the relevant token.
The following requirements describe how, for ENVELOPEs carrying a wst:RequestSecurityToken, the SOAP Body and crucial headers, specified in Section 4.5 and Section 6, must be signed.
R1100 An ENVELOPE containing a wst:RequestSecurityToken in the SOAP Body and an action URI of http://docs.oasis-open.org/ws-sx/ws-trust/200512/RST/SCT/Amend, MUST also contain a wsse:Security header with a ds:Signature child element that covers the SOAP Body and crucial headers as specified in Sections 4.5 and 6.TESTABLE RSP1100
Test Assertion Analysis: | RSP1100 |
---|---|
General Notes: | NOTE1: the predicate is weaker than the profile req, hence true=undetermined, but false= a sure failure. |
Coverage Assessment: | Partial |
Target Type: | ENVELOPE (with wst:RST) |
Test Target: | For an Envelope with RST and action URI=.... |
Test co-Target(s): | |
Test Prerequisite: | |
Predicate: | It has Security header that references SOAP body. |
Prescription: | mandatory |
Reporting: | true=undetermined, false=fail |
Test Control: | Text env: must implement RMS->scenario to generate the TA context |
Test Assertion: | RSP1100 |
---|---|
Description: | |
Target: |
[*:Body//wst:RequestSecurityToken and *:Header/wsa:Action eq 'http://docs.oasis-open.org/ws-sx/ws-trust/200512/RST/SCT/Amend'] |
Predicate: |
($dsig//ds:Reference[fn:substring-after(@URI, '#') eq $target/@wsu:Id]) or (
($dsig//ds:Reference[fn:substring-after(@URI, '#') eq
$target/*:Header/@wsu:Id] or
and (
(every $cruxp in $target/*:Header/wsrm:* | $target/*:Header/wsa:* satisfies some $ref in $dsig//ds:Reference satisfies fn:substring-after($ref/@URI, '#') = $cruxp/@wsu:Id))
$dsig//ds:Reference[fn:substring-after(@URI, '#') eq
$target/*:Body/@wsu:Id] or
)(every $cruxp in $target/*:Body/* satisfies some $ref in $dsig//ds:Reference satisfies fn:substring-after($ref/@URI, '#') = $cruxp/@wsu:Id )) |
Reporting: | true=passed, false=failed |
Prescription: | mandatory |
Error Message: | An ENVELOPE containing a wst:RequestSecurityToken for amending a Security Context, does not contain a Signature element in a wsse header that references both the SOAP body (using @wsu:Id) and crucial wsrm or wsa headers. |
Diagnostic Data: |
|
Test Assertion Part | What it means: |
---|---|
Test Assertion ID: |
[markup: testAssertion/@id] (required) A unique ID for the current test assertion. |
Description: |
[markup: testAssertion/description ] (optional) A plain text description of the current test assertion. At minimum expressing the TA predicate. |
Comments: |
[markup: testAssertion/comments ] (optional) A plain text comment about the TA script and how well it covers the profile requirement. Explanation material for users, and developers (what could be improved, etc.). |
Target: |
[markup: testAssertion/target ] (required) The artifacts to be tested, defined by an XPath expression that returns a list of XML nodes from the log file in input. For every artifact (node) selected by the Target expression, there will be a report entry for this TA in the test report, with a result of either:
See the "reporting" item for the meaning of these results. |
Cotarget: |
[markup: testAssertion/cotarget ] (optional) Artifact that is related to the target, and that needs be accessed for the testing. Identified by an XPath expression that may refer to the related target node using the variable '$target'. For example, the target can be a SOAP message and the cotarget the WSDL file that describes this SOAP message. A cotarget must have a @name attribute that identifies it. The value of this attribute can be used as a variable (when prepending '$' to it) by subsequently defined cotargets, prerequisite and predicate. |
Prerequisite: |
[markup: testAssertion/@preReq ] (optional) [markup: testAssertion/prerequisite ] (optional) The pre-condition for evaluating this Test Assertion on this target. If the prerequisite evaluates to "false" then the target does not qualify for this Test Assertion (the test report is "notRelevant") The first part (preReq attribute) is an enumeration of Test Assertion IDs. Each one of the prerequisite TAs must either use the same target (e.g. SOAP Envelope, or WSDL binding, etc.) as this TA, or a target that is of a more general type than the main TA target. The target must "pass" each one of these prerequisite TAs in order to qualify for this TA. (e.g. the target of TA t1 can be a WSDL binding while the target of a TA t2 prerequisite of t1, can be the entire WSDL file). The second part ("prerequisite" element) is an XPath (boolean) expression of the same nature as the predicate. If present, it must evaluate to "true" for the target to qualify. If it fails, the result for the current TA in the report will be "notRelevant". Otherwise, the target can be further evaluated by the predicate of the main TA. The expression may refer to the target explicitly using the variable name "$target", or to any cotarget using its name as variable name ($[name]). |
Predicate: |
[markup: testAssertion/predicate] required element] A logical expression that evaluates whether this target is fulfilling the profile requirement addressed by this test Assertion. By default: - A result of true means the requirement is fulfilled (reported as a "passed" in the test report).- A result of false means the requirement is violated (reported as a "failed" in the test report). However, in some cases and for testability reasons, the predicate may be designed as a partial indicator e.g. only indicates some cases of fulfillment, or some cases of violation. As a result, when "true" indicates fulfillment it may be that "false" is unconclusive, or conversely "false" will indicate violation, but "true" is unconclusive. In such cases, the "Reporting" element specifies the meaning of the predicate result w/r to the profile requirement. The predicate expression implicitly refers to the target (whic is its "XPath context") although it may explicitly refer to it using the variable name "$target". It may refer to any cotarget using its name as variable name ($[name]). |
Prescription: |
[markup: testAssertion/prescription/@level ] (required) Conveys the level of prescription associated with the profile requirement. At least three values may be used:
|
Reporting: |
[markup: testAssertion/reporting ] (optional) For each possible outcome of the predicate (true or false), specifies how it must be interpreted w/r to the profile feature. Two attributes are used that both must be present, when this element is present:
NOTES: the predicate of the TA may be worded in a negative way so that @false='passed' although that is not recommended. The result of a test should not be related to the prescription level, e.g. a "preferred" or "permitted" level should not imply that @false='warning'. Other test results that are automatically generated and not controlled by the "reporting" element are:
|
R1101 In an ENVELOPE, the signature referred to in R1100 MUST be created using the key associated with the security context that is being amended.NOT_TESTABLE COM1101
Test Assertion Analysis: | COM1101 |
---|---|
General Notes: | untestable due to key comparison issue. Same for R1111, R1121. |
Coverage Assessment: | |
Target Type: | |
Test Target: | |
Test co-Target(s): | |
Test Prerequisite: | |
Predicate: | |
Prescription: | mandatory |
Reporting: | |
Test Control: |
Test Assertion: | COM1101 |
---|---|
Description: | |
Target: |
|
Predicate: |
|
Reporting: | true=passed, false=failed |
Prescription: | mandatory |
Error Message: | |
Diagnostic Data: |
|
Test Assertion Part | What it means: |
---|---|
Test Assertion ID: |
[markup: testAssertion/@id] (required) A unique ID for the current test assertion. |
Description: |
[markup: testAssertion/description ] (optional) A plain text description of the current test assertion. At minimum expressing the TA predicate. |
Comments: |
[markup: testAssertion/comments ] (optional) A plain text comment about the TA script and how well it covers the profile requirement. Explanation material for users, and developers (what could be improved, etc.). |
Target: |
[markup: testAssertion/target ] (required) The artifacts to be tested, defined by an XPath expression that returns a list of XML nodes from the log file in input. For every artifact (node) selected by the Target expression, there will be a report entry for this TA in the test report, with a result of either:
See the "reporting" item for the meaning of these results. |
Cotarget: |
[markup: testAssertion/cotarget ] (optional) Artifact that is related to the target, and that needs be accessed for the testing. Identified by an XPath expression that may refer to the related target node using the variable '$target'. For example, the target can be a SOAP message and the cotarget the WSDL file that describes this SOAP message. A cotarget must have a @name attribute that identifies it. The value of this attribute can be used as a variable (when prepending '$' to it) by subsequently defined cotargets, prerequisite and predicate. |
Prerequisite: |
[markup: testAssertion/@preReq ] (optional) [markup: testAssertion/prerequisite ] (optional) The pre-condition for evaluating this Test Assertion on this target. If the prerequisite evaluates to "false" then the target does not qualify for this Test Assertion (the test report is "notRelevant") The first part (preReq attribute) is an enumeration of Test Assertion IDs. Each one of the prerequisite TAs must either use the same target (e.g. SOAP Envelope, or WSDL binding, etc.) as this TA, or a target that is of a more general type than the main TA target. The target must "pass" each one of these prerequisite TAs in order to qualify for this TA. (e.g. the target of TA t1 can be a WSDL binding while the target of a TA t2 prerequisite of t1, can be the entire WSDL file). The second part ("prerequisite" element) is an XPath (boolean) expression of the same nature as the predicate. If present, it must evaluate to "true" for the target to qualify. If it fails, the result for the current TA in the report will be "notRelevant". Otherwise, the target can be further evaluated by the predicate of the main TA. The expression may refer to the target explicitly using the variable name "$target", or to any cotarget using its name as variable name ($[name]). |
Predicate: |
[markup: testAssertion/predicate] required element] A logical expression that evaluates whether this target is fulfilling the profile requirement addressed by this test Assertion. By default: - A result of true means the requirement is fulfilled (reported as a "passed" in the test report).- A result of false means the requirement is violated (reported as a "failed" in the test report). However, in some cases and for testability reasons, the predicate may be designed as a partial indicator e.g. only indicates some cases of fulfillment, or some cases of violation. As a result, when "true" indicates fulfillment it may be that "false" is unconclusive, or conversely "false" will indicate violation, but "true" is unconclusive. In such cases, the "Reporting" element specifies the meaning of the predicate result w/r to the profile requirement. The predicate expression implicitly refers to the target (whic is its "XPath context") although it may explicitly refer to it using the variable name "$target". It may refer to any cotarget using its name as variable name ($[name]). |
Prescription: |
[markup: testAssertion/prescription/@level ] (required) Conveys the level of prescription associated with the profile requirement. At least three values may be used:
|
Reporting: |
[markup: testAssertion/reporting ] (optional) For each possible outcome of the predicate (true or false), specifies how it must be interpreted w/r to the profile feature. Two attributes are used that both must be present, when this element is present:
NOTES: the predicate of the TA may be worded in a negative way so that @false='passed' although that is not recommended. The result of a test should not be related to the prescription level, e.g. a "preferred" or "permitted" level should not imply that @false='warning'. Other test results that are automatically generated and not controlled by the "reporting" element are:
|
R1110 An ENVELOPE containing a wst:RequestSecurityToken in the SOAP Body and an action URI of http://docs.oasis-open.org/ws-sx/ws-trust/200512/RST/SCT/Renew, MUST also contain a wsse:Security header with a ds:Signature child element that covers the SOAP Body and crucial headers as specified in Sections 4.5 and 6.TESTABLE RSP1110
Test Assertion Analysis: | RSP1110 |
---|---|
General Notes: | NOTE1: the predicate is weaker than the profile req, hence true=undetermined, but false= a sure failure. |
Coverage Assessment: | Partial |
Target Type: | ENVELOPE |
Test Target: | For an Envelope with RST and action URI=.... |
Test co-Target(s): | |
Test Prerequisite: | |
Predicate: | It has Security header that references SOAP body. |
Prescription: | mandatory |
Reporting: | true=undetermined, false=fail |
Test Control: | Text env: must implement RMS->scenario to generate the TA context |
Test Assertion: | RSP1110 |
---|---|
Description: | |
Target: |
[*:Body//wst:RequestSecurityToken and *:Header/wsa:Action eq 'http://docs.oasis-open.org/ws-sx/ws-trust/200512/RST/SCT/Renew'] |
Predicate: |
($dsig//ds:Reference[fn:substring-after(@URI, '#') eq $target/@wsu:Id]) or (
($dsig//ds:Reference[fn:substring-after(@URI, '#') eq
$target/*:Header/@wsu:Id] or (every $cruxp in
$target/*:Header/wsrm:* | $target/*:Header/wsa:* satisfies
and (
some $ref in $dsig//ds:Reference satisfies fn:substring-after($ref/@URI, '#') = $cruxp/@wsu:Id))
$dsig//ds:Reference[fn:substring-after(@URI, '#') eq
$target/*:Body/@wsu:Id] or
)(every $cruxp in $target/*:Body/* satisfies some $ref in $dsig//ds:Reference satisfies fn:substring-after($ref/@URI, '#') = $cruxp/@wsu:Id )) |
Reporting: | true=warning, false=failed |
Prescription: | mandatory |
Error Message: | An ENVELOPE containing a wst:RequestSecurityToken for renewing a Security Context, does not contain a Signature element in a wsse header that references both the SOAP body (using @wsu:Id) and crucial wsrm or wsa headers. |
Diagnostic Data: |
|
Test Assertion Part | What it means: |
---|---|
Test Assertion ID: |
[markup: testAssertion/@id] (required) A unique ID for the current test assertion. |
Description: |
[markup: testAssertion/description ] (optional) A plain text description of the current test assertion. At minimum expressing the TA predicate. |
Comments: |
[markup: testAssertion/comments ] (optional) A plain text comment about the TA script and how well it covers the profile requirement. Explanation material for users, and developers (what could be improved, etc.). |
Target: |
[markup: testAssertion/target ] (required) The artifacts to be tested, defined by an XPath expression that returns a list of XML nodes from the log file in input. For every artifact (node) selected by the Target expression, there will be a report entry for this TA in the test report, with a result of either:
See the "reporting" item for the meaning of these results. |
Cotarget: |
[markup: testAssertion/cotarget ] (optional) Artifact that is related to the target, and that needs be accessed for the testing. Identified by an XPath expression that may refer to the related target node using the variable '$target'. For example, the target can be a SOAP message and the cotarget the WSDL file that describes this SOAP message. A cotarget must have a @name attribute that identifies it. The value of this attribute can be used as a variable (when prepending '$' to it) by subsequently defined cotargets, prerequisite and predicate. |
Prerequisite: |
[markup: testAssertion/@preReq ] (optional) [markup: testAssertion/prerequisite ] (optional) The pre-condition for evaluating this Test Assertion on this target. If the prerequisite evaluates to "false" then the target does not qualify for this Test Assertion (the test report is "notRelevant") The first part (preReq attribute) is an enumeration of Test Assertion IDs. Each one of the prerequisite TAs must either use the same target (e.g. SOAP Envelope, or WSDL binding, etc.) as this TA, or a target that is of a more general type than the main TA target. The target must "pass" each one of these prerequisite TAs in order to qualify for this TA. (e.g. the target of TA t1 can be a WSDL binding while the target of a TA t2 prerequisite of t1, can be the entire WSDL file). The second part ("prerequisite" element) is an XPath (boolean) expression of the same nature as the predicate. If present, it must evaluate to "true" for the target to qualify. If it fails, the result for the current TA in the report will be "notRelevant". Otherwise, the target can be further evaluated by the predicate of the main TA. The expression may refer to the target explicitly using the variable name "$target", or to any cotarget using its name as variable name ($[name]). |
Predicate: |
[markup: testAssertion/predicate] required element] A logical expression that evaluates whether this target is fulfilling the profile requirement addressed by this test Assertion. By default: - A result of true means the requirement is fulfilled (reported as a "passed" in the test report).- A result of false means the requirement is violated (reported as a "failed" in the test report). However, in some cases and for testability reasons, the predicate may be designed as a partial indicator e.g. only indicates some cases of fulfillment, or some cases of violation. As a result, when "true" indicates fulfillment it may be that "false" is unconclusive, or conversely "false" will indicate violation, but "true" is unconclusive. In such cases, the "Reporting" element specifies the meaning of the predicate result w/r to the profile requirement. The predicate expression implicitly refers to the target (whic is its "XPath context") although it may explicitly refer to it using the variable name "$target". It may refer to any cotarget using its name as variable name ($[name]). |
Prescription: |
[markup: testAssertion/prescription/@level ] (required) Conveys the level of prescription associated with the profile requirement. At least three values may be used:
|
Reporting: |
[markup: testAssertion/reporting ] (optional) For each possible outcome of the predicate (true or false), specifies how it must be interpreted w/r to the profile feature. Two attributes are used that both must be present, when this element is present:
NOTES: the predicate of the TA may be worded in a negative way so that @false='passed' although that is not recommended. The result of a test should not be related to the prescription level, e.g. a "preferred" or "permitted" level should not imply that @false='warning'. Other test results that are automatically generated and not controlled by the "reporting" element are:
|
R1111 In an ENVELOPE, the signature referred to in R1110 MUST be created using the key associated with the security context that is being renewed.NOT_TESTABLE
R1120 An ENVELOPE containing a wst:RequestSecurityToken in the SOAP Body and an action URI of http://docs.oasis-open.org/ws-sx/ws-trust/200512/RST/SCT/Cancel, MUST also contain a wsse:Security header with a ds:Signature child element that covers the SOAP Body and crucial headers as specified in Sections 4.5 and 6.TESTABLE RSP1120
Test Assertion Analysis: | RSP1120 |
---|---|
General Notes: | NOTE1: the predicate is weaker than the profile req, hence true=undetermined, but false= a sure failure. |
Coverage Assessment: | Partial |
Target Type: | ENVELOPE |
Test Target: | For an Envelope with RST and action URI=.... |
Test co-Target(s): | |
Test Prerequisite: | |
Predicate: | It has Security header that references SOAP body. |
Prescription: | mandatory |
Reporting: | true=undetermined, false=fail |
Test Control: | Text env: must implement RMS->scenario to generate the TA context |
Test Assertion: | RSP1120 |
---|---|
Description: | |
Target: |
[*:Body//wst:RequestSecurityToken and *:Header/wsa:Action eq 'http://docs.oasis-open.org/ws-sx/ws-trust/200512/RST/SCT/Cancel'] |
Predicate: |
($dsig//ds:Reference[fn:substring-after(@URI, '#') eq $target/@wsu:Id]) or (
($dsig//ds:Reference[fn:substring-after(@URI, '#') eq
$target/*:Header/@wsu:Id] or
and (
(every $cruxp in $target/*:Header/wsrm:* | $target/*:Header/wsa:* satisfies some $ref in $dsig//ds:Reference satisfies fn:substring-after($ref/@URI, '#') = $cruxp/@wsu:Id))
$dsig//ds:Reference[fn:substring-after(@URI, '#') eq
$target/*:Body/@wsu:Id] or
)(every $cruxp in $target/*:Body/* satisfies some $ref in $dsig//ds:Reference satisfies fn:substring-after($ref/@URI, '#') = $cruxp/@wsu:Id )) |
Reporting: | true=warning, false=failed |
Prescription: | mandatory |
Error Message: | An ENVELOPE containing a wst:RequestSecurityToken for canceling a Security Context, does not contain a Signature element in a wsse header that references both the SOAP body (using @wsu:Id) and crucial wsrm or wsa headers. |
Diagnostic Data: |
|
Test Assertion Part | What it means: |
---|---|
Test Assertion ID: |
[markup: testAssertion/@id] (required) A unique ID for the current test assertion. |
Description: |
[markup: testAssertion/description ] (optional) A plain text description of the current test assertion. At minimum expressing the TA predicate. |
Comments: |
[markup: testAssertion/comments ] (optional) A plain text comment about the TA script and how well it covers the profile requirement. Explanation material for users, and developers (what could be improved, etc.). |
Target: |
[markup: testAssertion/target ] (required) The artifacts to be tested, defined by an XPath expression that returns a list of XML nodes from the log file in input. For every artifact (node) selected by the Target expression, there will be a report entry for this TA in the test report, with a result of either:
See the "reporting" item for the meaning of these results. |
Cotarget: |
[markup: testAssertion/cotarget ] (optional) Artifact that is related to the target, and that needs be accessed for the testing. Identified by an XPath expression that may refer to the related target node using the variable '$target'. For example, the target can be a SOAP message and the cotarget the WSDL file that describes this SOAP message. A cotarget must have a @name attribute that identifies it. The value of this attribute can be used as a variable (when prepending '$' to it) by subsequently defined cotargets, prerequisite and predicate. |
Prerequisite: |
[markup: testAssertion/@preReq ] (optional) [markup: testAssertion/prerequisite ] (optional) The pre-condition for evaluating this Test Assertion on this target. If the prerequisite evaluates to "false" then the target does not qualify for this Test Assertion (the test report is "notRelevant") The first part (preReq attribute) is an enumeration of Test Assertion IDs. Each one of the prerequisite TAs must either use the same target (e.g. SOAP Envelope, or WSDL binding, etc.) as this TA, or a target that is of a more general type than the main TA target. The target must "pass" each one of these prerequisite TAs in order to qualify for this TA. (e.g. the target of TA t1 can be a WSDL binding while the target of a TA t2 prerequisite of t1, can be the entire WSDL file). The second part ("prerequisite" element) is an XPath (boolean) expression of the same nature as the predicate. If present, it must evaluate to "true" for the target to qualify. If it fails, the result for the current TA in the report will be "notRelevant". Otherwise, the target can be further evaluated by the predicate of the main TA. The expression may refer to the target explicitly using the variable name "$target", or to any cotarget using its name as variable name ($[name]). |
Predicate: |
[markup: testAssertion/predicate] required element] A logical expression that evaluates whether this target is fulfilling the profile requirement addressed by this test Assertion. By default: - A result of true means the requirement is fulfilled (reported as a "passed" in the test report).- A result of false means the requirement is violated (reported as a "failed" in the test report). However, in some cases and for testability reasons, the predicate may be designed as a partial indicator e.g. only indicates some cases of fulfillment, or some cases of violation. As a result, when "true" indicates fulfillment it may be that "false" is unconclusive, or conversely "false" will indicate violation, but "true" is unconclusive. In such cases, the "Reporting" element specifies the meaning of the predicate result w/r to the profile requirement. The predicate expression implicitly refers to the target (whic is its "XPath context") although it may explicitly refer to it using the variable name "$target". It may refer to any cotarget using its name as variable name ($[name]). |
Prescription: |
[markup: testAssertion/prescription/@level ] (required) Conveys the level of prescription associated with the profile requirement. At least three values may be used:
|
Reporting: |
[markup: testAssertion/reporting ] (optional) For each possible outcome of the predicate (true or false), specifies how it must be interpreted w/r to the profile feature. Two attributes are used that both must be present, when this element is present:
NOTES: the predicate of the TA may be worded in a negative way so that @false='passed' although that is not recommended. The result of a test should not be related to the prescription level, e.g. a "preferred" or "permitted" level should not imply that @false='warning'. Other test results that are automatically generated and not controlled by the "reporting" element are:
|
R1121 In an ENVELOPE, the signature referred to in R1120 MUST be created using the key associated with the security context that is being canceled.NOT_TESTABLE
As per section 5 of the WS-SecureConversation specification, the request to renew a security context must include the re-authentication of the context's original claims. It is recommended, but not required, that the claims re-authentication be done in the same manner as the original token issuance request. This creates the potential for some implementations of WS-SecureConversation to attempt claims re-authentication in a manner different than the original token issuance request, to the obvious detriment of both interoperability and security.
R1200 When a SENDER makes a request to renew a security context, it MUST re-authenticate the original claims in the same way as in the original token issuance request.TESTABLE RSP1200
Test Assertion Analysis: | RSP1200 |
---|---|
General Notes: | |
Coverage Assessment: | Partial |
Target Type: | ENVELOPE |
Test Target: | For an Envelope with RST/SCT/renew action URI |
Test co-Target(s): | |
Test Prerequisite: | |
Predicate: | It correlates with RSTR/SCT that correlates with original RST and renew that has auth mechanism |
Prescription: | mandatory |
Reporting: | true=warning, false=warning |
Test Control: |
Test Assertion: | RSP1200 |
---|---|
Description: | |
Target: |
|
co-Target: myOriginalRSTR |
|
Predicate: |
|
Reporting: | true=passed, false=failed |
Prescription: | mandatory |
Error Message: | A renew security context message did not correlate with an original RST token issuance request that used the same authentication mechanism - i.e. here a Signature with KeyInfo that refer to same certificate ID. |
Diagnostic Data: |
|
Test Assertion Part | What it means: |
---|---|
Test Assertion ID: |
[markup: testAssertion/@id] (required) A unique ID for the current test assertion. |
Description: |
[markup: testAssertion/description ] (optional) A plain text description of the current test assertion. At minimum expressing the TA predicate. |
Comments: |
[markup: testAssertion/comments ] (optional) A plain text comment about the TA script and how well it covers the profile requirement. Explanation material for users, and developers (what could be improved, etc.). |
Target: |
[markup: testAssertion/target ] (required) The artifacts to be tested, defined by an XPath expression that returns a list of XML nodes from the log file in input. For every artifact (node) selected by the Target expression, there will be a report entry for this TA in the test report, with a result of either:
See the "reporting" item for the meaning of these results. |
Cotarget: |
[markup: testAssertion/cotarget ] (optional) Artifact that is related to the target, and that needs be accessed for the testing. Identified by an XPath expression that may refer to the related target node using the variable '$target'. For example, the target can be a SOAP message and the cotarget the WSDL file that describes this SOAP message. A cotarget must have a @name attribute that identifies it. The value of this attribute can be used as a variable (when prepending '$' to it) by subsequently defined cotargets, prerequisite and predicate. |
Prerequisite: |
[markup: testAssertion/@preReq ] (optional) [markup: testAssertion/prerequisite ] (optional) The pre-condition for evaluating this Test Assertion on this target. If the prerequisite evaluates to "false" then the target does not qualify for this Test Assertion (the test report is "notRelevant") The first part (preReq attribute) is an enumeration of Test Assertion IDs. Each one of the prerequisite TAs must either use the same target (e.g. SOAP Envelope, or WSDL binding, etc.) as this TA, or a target that is of a more general type than the main TA target. The target must "pass" each one of these prerequisite TAs in order to qualify for this TA. (e.g. the target of TA t1 can be a WSDL binding while the target of a TA t2 prerequisite of t1, can be the entire WSDL file). The second part ("prerequisite" element) is an XPath (boolean) expression of the same nature as the predicate. If present, it must evaluate to "true" for the target to qualify. If it fails, the result for the current TA in the report will be "notRelevant". Otherwise, the target can be further evaluated by the predicate of the main TA. The expression may refer to the target explicitly using the variable name "$target", or to any cotarget using its name as variable name ($[name]). |
Predicate: |
[markup: testAssertion/predicate] required element] A logical expression that evaluates whether this target is fulfilling the profile requirement addressed by this test Assertion. By default: - A result of true means the requirement is fulfilled (reported as a "passed" in the test report).- A result of false means the requirement is violated (reported as a "failed" in the test report). However, in some cases and for testability reasons, the predicate may be designed as a partial indicator e.g. only indicates some cases of fulfillment, or some cases of violation. As a result, when "true" indicates fulfillment it may be that "false" is unconclusive, or conversely "false" will indicate violation, but "true" is unconclusive. In such cases, the "Reporting" element specifies the meaning of the predicate result w/r to the profile requirement. The predicate expression implicitly refers to the target (whic is its "XPath context") although it may explicitly refer to it using the variable name "$target". It may refer to any cotarget using its name as variable name ($[name]). |
Prescription: |
[markup: testAssertion/prescription/@level ] (required) Conveys the level of prescription associated with the profile requirement. At least three values may be used:
|
Reporting: |
[markup: testAssertion/reporting ] (optional) For each possible outcome of the predicate (true or false), specifies how it must be interpreted w/r to the profile feature. Two attributes are used that both must be present, when this element is present:
NOTES: the predicate of the TA may be worded in a negative way so that @false='passed' although that is not recommended. The result of a test should not be related to the prescription level, e.g. a "preferred" or "permitted" level should not imply that @false='warning'. Other test results that are automatically generated and not controlled by the "reporting" element are:
|
Section 8 of WS-SecureConversation states that references to an
SCT from within a wsse:Security
header, a
wst:RequestSecurityToken
element, or a
wst:RequestSecurityTokenReponse
element may be either
message dependent or message independent. However, references to
SCTs from outside a wsse:Security
header (or an RST,
or an RSTR) must be message independent. In order to improve
interoperability, this profile includes the following
requirement:
R1300 A RECEIVER MUST support both message dependent and message independent references to a wssc:SecurityContextToken from within a wsse:Security header, a wst:RequestSecurityToken element, or a wst:RequestSecurityTokenReponse element.TESTABLE RSP1300
Test Assertion Analysis: | RSP1300 |
---|---|
General Notes: | NOTE1:Type=Feature Usage. NOTE2: investigate ways at improving the context. NOTE3: coverage is good, but possiblemany false negatives |
Coverage Assessment: | Good |
Target Type: | ENVELOPE |
Test Target: | For an Envelope with wssc:Security or RST or RSTR and with SCT refs |
Test co-Target(s): | |
Test Prerequisite: | |
Predicate: | In the envelope, there exists wssc:STR/ref [@URI does not start with "#"] |
Prescription: | mandatory |
Reporting: | true=pass, false=warning |
Test Control: | scenario to provide context. |
Test Assertion: | RSP1300 |
---|---|
Description: | |
Target: |
|
Predicate: |
|
Reporting: | true=passed, false=warning |
Prescription: | mandatory |
Error Message: | An Envelope with wssc:Security or RST or RSTR and with SecurityContextToken that have either message dependent or independent message references, has been Faulted. User should verify that it is not faulted because of the receiver not supporting some type of message reference (either message dependent or independent message reference) |
Diagnostic Data: |
|
Test Assertion Part | What it means: |
---|---|
Test Assertion ID: |
[markup: testAssertion/@id] (required) A unique ID for the current test assertion. |
Description: |
[markup: testAssertion/description ] (optional) A plain text description of the current test assertion. At minimum expressing the TA predicate. |
Comments: |
[markup: testAssertion/comments ] (optional) A plain text comment about the TA script and how well it covers the profile requirement. Explanation material for users, and developers (what could be improved, etc.). |
Target: |
[markup: testAssertion/target ] (required) The artifacts to be tested, defined by an XPath expression that returns a list of XML nodes from the log file in input. For every artifact (node) selected by the Target expression, there will be a report entry for this TA in the test report, with a result of either:
See the "reporting" item for the meaning of these results. |
Cotarget: |
[markup: testAssertion/cotarget ] (optional) Artifact that is related to the target, and that needs be accessed for the testing. Identified by an XPath expression that may refer to the related target node using the variable '$target'. For example, the target can be a SOAP message and the cotarget the WSDL file that describes this SOAP message. A cotarget must have a @name attribute that identifies it. The value of this attribute can be used as a variable (when prepending '$' to it) by subsequently defined cotargets, prerequisite and predicate. |
Prerequisite: |
[markup: testAssertion/@preReq ] (optional) [markup: testAssertion/prerequisite ] (optional) The pre-condition for evaluating this Test Assertion on this target. If the prerequisite evaluates to "false" then the target does not qualify for this Test Assertion (the test report is "notRelevant") The first part (preReq attribute) is an enumeration of Test Assertion IDs. Each one of the prerequisite TAs must either use the same target (e.g. SOAP Envelope, or WSDL binding, etc.) as this TA, or a target that is of a more general type than the main TA target. The target must "pass" each one of these prerequisite TAs in order to qualify for this TA. (e.g. the target of TA t1 can be a WSDL binding while the target of a TA t2 prerequisite of t1, can be the entire WSDL file). The second part ("prerequisite" element) is an XPath (boolean) expression of the same nature as the predicate. If present, it must evaluate to "true" for the target to qualify. If it fails, the result for the current TA in the report will be "notRelevant". Otherwise, the target can be further evaluated by the predicate of the main TA. The expression may refer to the target explicitly using the variable name "$target", or to any cotarget using its name as variable name ($[name]). |
Predicate: |
[markup: testAssertion/predicate] required element] A logical expression that evaluates whether this target is fulfilling the profile requirement addressed by this test Assertion. By default: - A result of true means the requirement is fulfilled (reported as a "passed" in the test report).- A result of false means the requirement is violated (reported as a "failed" in the test report). However, in some cases and for testability reasons, the predicate may be designed as a partial indicator e.g. only indicates some cases of fulfillment, or some cases of violation. As a result, when "true" indicates fulfillment it may be that "false" is unconclusive, or conversely "false" will indicate violation, but "true" is unconclusive. In such cases, the "Reporting" element specifies the meaning of the predicate result w/r to the profile requirement. The predicate expression implicitly refers to the target (whic is its "XPath context") although it may explicitly refer to it using the variable name "$target". It may refer to any cotarget using its name as variable name ($[name]). |
Prescription: |
[markup: testAssertion/prescription/@level ] (required) Conveys the level of prescription associated with the profile requirement. At least three values may be used:
|
Reporting: |
[markup: testAssertion/reporting ] (optional) For each possible outcome of the predicate (true or false), specifies how it must be interpreted w/r to the profile feature. Two attributes are used that both must be present, when this element is present:
NOTES: the predicate of the TA may be worded in a negative way so that @false='passed' although that is not recommended. The result of a test should not be related to the prescription level, e.g. a "preferred" or "permitted" level should not imply that @false='warning'. Other test results that are automatically generated and not controlled by the "reporting" element are:
|
Section 7 of the WS-SecureConversation specification describes a
mechanism for using keys derived from a shared secret for signing
and encrypting the messages associated with a security context. The
wssc:DerivedKeyToken
element is used to express these
derived keys. WS-SC states that the
/wssc:DerivedKeyToken/wsse:SecurityTokenReference
element SHOULD be used to reference the
wssc:SecurityContextToken
of the security context
who's shared secret was used to derive the key. This creates an
interoperability issue because it leaves open the possibility for a
derived key to either lack any relationship between the shared
secret or for this relationship to be expressed by some mechanism
other than a wsse:SecurityTokenReference.
R1310 When an ENVELOPE contains a wssc:DerivedKeyToken, the wsse:SecurityTokenReference element MUST be used to reference the wssc:SecurityContextToken of the security context from which they key is derived.TESTABLE RSP1310
Test Assertion Analysis: | RSP1310 |
---|---|
General Notes: | |
Coverage Assessment: | Good |
Target Type: | ENVELOPE |
Test Target: | For an Envelope with wsc:DKT |
Test co-Target(s): | |
Test Prerequisite: | |
Predicate: | there exists DKT/STR and there exists a message with (SCT/identifier=STR/Refrence@URI) |
Prescription: | mandatory |
Reporting: | (default) |
Test Control: |
Test Assertion: | RSP1310 |
---|---|
Description: | |
Target: |
|
Predicate: |
|
Reporting: | true=warning, false=failed |
Prescription: | mandatory |
Error Message: | In case of warning: the test is inconclusive as the related RequestSecurityTokenResponse content could not be accessed. In case of failure: an Envelope with wsc:DerivedKeyToken does not refer (with wsse:SecurityTokenReference) to a wssc:SecurityContextToken returned in a RequestSecurityTokenResponse message, or the related RequestSecurityTokenResponse message is missing. |
Diagnostic Data: |
|
Test Assertion Part | What it means: |
---|---|
Test Assertion ID: |
[markup: testAssertion/@id] (required) A unique ID for the current test assertion. |
Description: |
[markup: testAssertion/description ] (optional) A plain text description of the current test assertion. At minimum expressing the TA predicate. |
Comments: |
[markup: testAssertion/comments ] (optional) A plain text comment about the TA script and how well it covers the profile requirement. Explanation material for users, and developers (what could be improved, etc.). |
Target: |
[markup: testAssertion/target ] (required) The artifacts to be tested, defined by an XPath expression that returns a list of XML nodes from the log file in input. For every artifact (node) selected by the Target expression, there will be a report entry for this TA in the test report, with a result of either:
See the "reporting" item for the meaning of these results. |
Cotarget: |
[markup: testAssertion/cotarget ] (optional) Artifact that is related to the target, and that needs be accessed for the testing. Identified by an XPath expression that may refer to the related target node using the variable '$target'. For example, the target can be a SOAP message and the cotarget the WSDL file that describes this SOAP message. A cotarget must have a @name attribute that identifies it. The value of this attribute can be used as a variable (when prepending '$' to it) by subsequently defined cotargets, prerequisite and predicate. |
Prerequisite: |
[markup: testAssertion/@preReq ] (optional) [markup: testAssertion/prerequisite ] (optional) The pre-condition for evaluating this Test Assertion on this target. If the prerequisite evaluates to "false" then the target does not qualify for this Test Assertion (the test report is "notRelevant") The first part (preReq attribute) is an enumeration of Test Assertion IDs. Each one of the prerequisite TAs must either use the same target (e.g. SOAP Envelope, or WSDL binding, etc.) as this TA, or a target that is of a more general type than the main TA target. The target must "pass" each one of these prerequisite TAs in order to qualify for this TA. (e.g. the target of TA t1 can be a WSDL binding while the target of a TA t2 prerequisite of t1, can be the entire WSDL file). The second part ("prerequisite" element) is an XPath (boolean) expression of the same nature as the predicate. If present, it must evaluate to "true" for the target to qualify. If it fails, the result for the current TA in the report will be "notRelevant". Otherwise, the target can be further evaluated by the predicate of the main TA. The expression may refer to the target explicitly using the variable name "$target", or to any cotarget using its name as variable name ($[name]). |
Predicate: |
[markup: testAssertion/predicate] required element] A logical expression that evaluates whether this target is fulfilling the profile requirement addressed by this test Assertion. By default: - A result of true means the requirement is fulfilled (reported as a "passed" in the test report).- A result of false means the requirement is violated (reported as a "failed" in the test report). However, in some cases and for testability reasons, the predicate may be designed as a partial indicator e.g. only indicates some cases of fulfillment, or some cases of violation. As a result, when "true" indicates fulfillment it may be that "false" is unconclusive, or conversely "false" will indicate violation, but "true" is unconclusive. In such cases, the "Reporting" element specifies the meaning of the predicate result w/r to the profile requirement. The predicate expression implicitly refers to the target (whic is its "XPath context") although it may explicitly refer to it using the variable name "$target". It may refer to any cotarget using its name as variable name ($[name]). |
Prescription: |
[markup: testAssertion/prescription/@level ] (required) Conveys the level of prescription associated with the profile requirement. At least three values may be used:
|
Reporting: |
[markup: testAssertion/reporting ] (optional) For each possible outcome of the predicate (true or false), specifies how it must be interpreted w/r to the profile feature. Two attributes are used that both must be present, when this element is present:
NOTES: the predicate of the TA may be worded in a negative way so that @false='passed' although that is not recommended. The result of a test should not be related to the prescription level, e.g. a "preferred" or "permitted" level should not imply that @false='warning'. Other test results that are automatically generated and not controlled by the "reporting" element are:
|
To properly and interoperably process derived keys it is necessary to relate the key to the shared secret from which it is derived. There are no alternatives to using wsse:SecurityTokenReference's that are consistent with WS-Security.
Since the semantics of the WS-SecureConversation protocol are dependent upon the value of various WS-Addressing headers, ensuring the proper functioning of WS-SecureConversation requires protecting the integrity of these headers. These requirements are not specific to the use of WS-SecureConversation. They also apply whenever WS-Security is being used in conjunction with WS-Addressing.
R1400 When present in an ENVELOPE in which the SOAP Body in that
ENVELOPE is signed, each of the following SOAP header blocks MUST
be included in a signature: wsa:To
,
wsa:From
, wsa:ReplyTo
,
wsa:Action
, wsa:FaultTo
,
wsa:MessageId
, wsa:RelatesTo
.TESTABLE RSP1400
Test Assertion Analysis: | RSP1400 |
---|---|
General Notes: | |
Coverage Assessment: | |
Target Type: | ENVELOPE |
Test Target: | Envelope with a signed body and some wsa headers. |
Test co-Target(s): | |
Test Prerequisite: | |
Predicate: | |
Prescription: | mandatory |
Reporting: | (default) |
Test Control: |
Test Assertion: | RSP1400 |
---|---|
Description: | |
Target: |
|
Predicate: |
|
Reporting: | true=passed, false=failed |
Prescription: | mandatory |
Error Message: | The SOAP Body of a message is signed but some ws-addressing header is not. |
Diagnostic Data: |
|
Test Assertion Part | What it means: |
---|---|
Test Assertion ID: |
[markup: testAssertion/@id] (required) A unique ID for the current test assertion. |
Description: |
[markup: testAssertion/description ] (optional) A plain text description of the current test assertion. At minimum expressing the TA predicate. |
Comments: |
[markup: testAssertion/comments ] (optional) A plain text comment about the TA script and how well it covers the profile requirement. Explanation material for users, and developers (what could be improved, etc.). |
Target: |
[markup: testAssertion/target ] (required) The artifacts to be tested, defined by an XPath expression that returns a list of XML nodes from the log file in input. For every artifact (node) selected by the Target expression, there will be a report entry for this TA in the test report, with a result of either:
See the "reporting" item for the meaning of these results. |
Cotarget: |
[markup: testAssertion/cotarget ] (optional) Artifact that is related to the target, and that needs be accessed for the testing. Identified by an XPath expression that may refer to the related target node using the variable '$target'. For example, the target can be a SOAP message and the cotarget the WSDL file that describes this SOAP message. A cotarget must have a @name attribute that identifies it. The value of this attribute can be used as a variable (when prepending '$' to it) by subsequently defined cotargets, prerequisite and predicate. |
Prerequisite: |
[markup: testAssertion/@preReq ] (optional) [markup: testAssertion/prerequisite ] (optional) The pre-condition for evaluating this Test Assertion on this target. If the prerequisite evaluates to "false" then the target does not qualify for this Test Assertion (the test report is "notRelevant") The first part (preReq attribute) is an enumeration of Test Assertion IDs. Each one of the prerequisite TAs must either use the same target (e.g. SOAP Envelope, or WSDL binding, etc.) as this TA, or a target that is of a more general type than the main TA target. The target must "pass" each one of these prerequisite TAs in order to qualify for this TA. (e.g. the target of TA t1 can be a WSDL binding while the target of a TA t2 prerequisite of t1, can be the entire WSDL file). The second part ("prerequisite" element) is an XPath (boolean) expression of the same nature as the predicate. If present, it must evaluate to "true" for the target to qualify. If it fails, the result for the current TA in the report will be "notRelevant". Otherwise, the target can be further evaluated by the predicate of the main TA. The expression may refer to the target explicitly using the variable name "$target", or to any cotarget using its name as variable name ($[name]). |
Predicate: |
[markup: testAssertion/predicate] required element] A logical expression that evaluates whether this target is fulfilling the profile requirement addressed by this test Assertion. By default: - A result of true means the requirement is fulfilled (reported as a "passed" in the test report).- A result of false means the requirement is violated (reported as a "failed" in the test report). However, in some cases and for testability reasons, the predicate may be designed as a partial indicator e.g. only indicates some cases of fulfillment, or some cases of violation. As a result, when "true" indicates fulfillment it may be that "false" is unconclusive, or conversely "false" will indicate violation, but "true" is unconclusive. In such cases, the "Reporting" element specifies the meaning of the predicate result w/r to the profile requirement. The predicate expression implicitly refers to the target (whic is its "XPath context") although it may explicitly refer to it using the variable name "$target". It may refer to any cotarget using its name as variable name ($[name]). |
Prescription: |
[markup: testAssertion/prescription/@level ] (required) Conveys the level of prescription associated with the profile requirement. At least three values may be used:
|
Reporting: |
[markup: testAssertion/reporting ] (optional) For each possible outcome of the predicate (true or false), specifies how it must be interpreted w/r to the profile feature. Two attributes are used that both must be present, when this element is present:
NOTES: the predicate of the TA may be worded in a negative way so that @false='passed' although that is not recommended. The result of a test should not be related to the prescription level, e.g. a "preferred" or "permitted" level should not imply that @false='warning'. Other test results that are automatically generated and not controlled by the "reporting" element are:
|
R1401 In an ENVELOPE, the signature(s) referred to in R1400 MUST be coupled cryptographically (e.g. share a common signature) with the message body.TESTABLE RSP1401
Test Assertion Analysis: | RSP1401 |
---|---|
General Notes: | |
Coverage Assessment: | partial (does not cover UnknownSequence Fault) |
Target Type: | ENVELOPE |
Test Target: | Envelope with Soap11 Fault. a SOAP11 fault that has in its detail element wsrm identifier that refers to a known Secured Seq |
Test co-Target(s): | |
Test Prerequisite: | |
Predicate: | |
Prescription: | mandatory |
Reporting: | (default) |
Test Control: |
Test Assertion: | RSP1401 |
---|---|
Description: | |
Target: |
|
Prerequisite: | RSP1400 |
Predicate: |
|
Reporting: | true=passed, false=failed |
Prescription: | mandatory |
Error Message: | Some ws-addressing header is not signed with the same signature as the Body of the message (based on @wsu:Id references). |
Diagnostic Data: |
|
Test Assertion Part | What it means: |
---|---|
Test Assertion ID: |
[markup: testAssertion/@id] (required) A unique ID for the current test assertion. |
Description: |
[markup: testAssertion/description ] (optional) A plain text description of the current test assertion. At minimum expressing the TA predicate. |
Comments: |
[markup: testAssertion/comments ] (optional) A plain text comment about the TA script and how well it covers the profile requirement. Explanation material for users, and developers (what could be improved, etc.). |
Target: |
[markup: testAssertion/target ] (required) The artifacts to be tested, defined by an XPath expression that returns a list of XML nodes from the log file in input. For every artifact (node) selected by the Target expression, there will be a report entry for this TA in the test report, with a result of either:
See the "reporting" item for the meaning of these results. |
Cotarget: |
[markup: testAssertion/cotarget ] (optional) Artifact that is related to the target, and that needs be accessed for the testing. Identified by an XPath expression that may refer to the related target node using the variable '$target'. For example, the target can be a SOAP message and the cotarget the WSDL file that describes this SOAP message. A cotarget must have a @name attribute that identifies it. The value of this attribute can be used as a variable (when prepending '$' to it) by subsequently defined cotargets, prerequisite and predicate. |
Prerequisite: |
[markup: testAssertion/@preReq ] (optional) [markup: testAssertion/prerequisite ] (optional) The pre-condition for evaluating this Test Assertion on this target. If the prerequisite evaluates to "false" then the target does not qualify for this Test Assertion (the test report is "notRelevant") The first part (preReq attribute) is an enumeration of Test Assertion IDs. Each one of the prerequisite TAs must either use the same target (e.g. SOAP Envelope, or WSDL binding, etc.) as this TA, or a target that is of a more general type than the main TA target. The target must "pass" each one of these prerequisite TAs in order to qualify for this TA. (e.g. the target of TA t1 can be a WSDL binding while the target of a TA t2 prerequisite of t1, can be the entire WSDL file). The second part ("prerequisite" element) is an XPath (boolean) expression of the same nature as the predicate. If present, it must evaluate to "true" for the target to qualify. If it fails, the result for the current TA in the report will be "notRelevant". Otherwise, the target can be further evaluated by the predicate of the main TA. The expression may refer to the target explicitly using the variable name "$target", or to any cotarget using its name as variable name ($[name]). |
Predicate: |
[markup: testAssertion/predicate] required element] A logical expression that evaluates whether this target is fulfilling the profile requirement addressed by this test Assertion. By default: - A result of true means the requirement is fulfilled (reported as a "passed" in the test report).- A result of false means the requirement is violated (reported as a "failed" in the test report). However, in some cases and for testability reasons, the predicate may be designed as a partial indicator e.g. only indicates some cases of fulfillment, or some cases of violation. As a result, when "true" indicates fulfillment it may be that "false" is unconclusive, or conversely "false" will indicate violation, but "true" is unconclusive. In such cases, the "Reporting" element specifies the meaning of the predicate result w/r to the profile requirement. The predicate expression implicitly refers to the target (whic is its "XPath context") although it may explicitly refer to it using the variable name "$target". It may refer to any cotarget using its name as variable name ($[name]). |
Prescription: |
[markup: testAssertion/prescription/@level ] (required) Conveys the level of prescription associated with the profile requirement. At least three values may be used:
|
Reporting: |
[markup: testAssertion/reporting ] (optional) For each possible outcome of the predicate (true or false), specifies how it must be interpreted w/r to the profile feature. Two attributes are used that both must be present, when this element is present:
NOTES: the predicate of the TA may be worded in a negative way so that @false='passed' although that is not recommended. The result of a test should not be related to the prescription level, e.g. a "preferred" or "permitted" level should not imply that @false='warning'. Other test results that are automatically generated and not controlled by the "reporting" element are:
|
R1402 When present in an ENVELOPE in which the SOAP Body in that ENVELOPE is signed, SOAP Header blocks with the wsa:isReferenceParameter attribute MUST be included in a signature for their designated SOAP role.TESTABLE RSP1402
Test Assertion Analysis: | RSP1402 |
---|---|
General Notes: | |
Coverage Assessment: | |
Target Type: | ENVELOPE |
Test Target: | Envelope with a signed body and some wsa headers. |
Test co-Target(s): | |
Test Prerequisite: | |
Predicate: | |
Prescription: | mandatory |
Reporting: | (default) |
Test Control: |
Test Assertion: | RSP1402 |
---|---|
Description: | |
Target: |
|
Predicate: |
|
Reporting: | true=passed, false=failed |
Prescription: | mandatory |
Error Message: | The SOAP Body of a message is signed but some ws-addressing reference parameter header block is not. |
Diagnostic Data: |
|
Test Assertion Part | What it means: |
---|---|
Test Assertion ID: |
[markup: testAssertion/@id] (required) A unique ID for the current test assertion. |
Description: |
[markup: testAssertion/description ] (optional) A plain text description of the current test assertion. At minimum expressing the TA predicate. |
Comments: |
[markup: testAssertion/comments ] (optional) A plain text comment about the TA script and how well it covers the profile requirement. Explanation material for users, and developers (what could be improved, etc.). |
Target: |
[markup: testAssertion/target ] (required) The artifacts to be tested, defined by an XPath expression that returns a list of XML nodes from the log file in input. For every artifact (node) selected by the Target expression, there will be a report entry for this TA in the test report, with a result of either:
See the "reporting" item for the meaning of these results. |
Cotarget: |
[markup: testAssertion/cotarget ] (optional) Artifact that is related to the target, and that needs be accessed for the testing. Identified by an XPath expression that may refer to the related target node using the variable '$target'. For example, the target can be a SOAP message and the cotarget the WSDL file that describes this SOAP message. A cotarget must have a @name attribute that identifies it. The value of this attribute can be used as a variable (when prepending '$' to it) by subsequently defined cotargets, prerequisite and predicate. |
Prerequisite: |
[markup: testAssertion/@preReq ] (optional) [markup: testAssertion/prerequisite ] (optional) The pre-condition for evaluating this Test Assertion on this target. If the prerequisite evaluates to "false" then the target does not qualify for this Test Assertion (the test report is "notRelevant") The first part (preReq attribute) is an enumeration of Test Assertion IDs. Each one of the prerequisite TAs must either use the same target (e.g. SOAP Envelope, or WSDL binding, etc.) as this TA, or a target that is of a more general type than the main TA target. The target must "pass" each one of these prerequisite TAs in order to qualify for this TA. (e.g. the target of TA t1 can be a WSDL binding while the target of a TA t2 prerequisite of t1, can be the entire WSDL file). The second part ("prerequisite" element) is an XPath (boolean) expression of the same nature as the predicate. If present, it must evaluate to "true" for the target to qualify. If it fails, the result for the current TA in the report will be "notRelevant". Otherwise, the target can be further evaluated by the predicate of the main TA. The expression may refer to the target explicitly using the variable name "$target", or to any cotarget using its name as variable name ($[name]). |
Predicate: |
[markup: testAssertion/predicate] required element] A logical expression that evaluates whether this target is fulfilling the profile requirement addressed by this test Assertion. By default: - A result of true means the requirement is fulfilled (reported as a "passed" in the test report).- A result of false means the requirement is violated (reported as a "failed" in the test report). However, in some cases and for testability reasons, the predicate may be designed as a partial indicator e.g. only indicates some cases of fulfillment, or some cases of violation. As a result, when "true" indicates fulfillment it may be that "false" is unconclusive, or conversely "false" will indicate violation, but "true" is unconclusive. In such cases, the "Reporting" element specifies the meaning of the predicate result w/r to the profile requirement. The predicate expression implicitly refers to the target (whic is its "XPath context") although it may explicitly refer to it using the variable name "$target". It may refer to any cotarget using its name as variable name ($[name]). |
Prescription: |
[markup: testAssertion/prescription/@level ] (required) Conveys the level of prescription associated with the profile requirement. At least three values may be used:
|
Reporting: |
[markup: testAssertion/reporting ] (optional) For each possible outcome of the predicate (true or false), specifies how it must be interpreted w/r to the profile feature. Two attributes are used that both must be present, when this element is present:
NOTES: the predicate of the TA may be worded in a negative way so that @false='passed' although that is not recommended. The result of a test should not be related to the prescription level, e.g. a "preferred" or "permitted" level should not imply that @false='warning'. Other test results that are automatically generated and not controlled by the "reporting" element are:
|
R1403 In an ENVELOPE, the signature(s) referred to in R1402 MUST be coupled cryptographically (e.g. share a common signature) with the message body.TESTABLE RSP1403
Test Assertion Analysis: | RSP1403 |
---|---|
General Notes: | |
Coverage Assessment: | partial (does not cover UnknownSequence Fault) |
Target Type: | ENVELOPE |
Test Target: | Envelope with Soap11 Fault. a SOAP11 fault that has in its detail element wsrm identifier that refers to a known Secured Seq |
Test co-Target(s): | |
Test Prerequisite: | |
Predicate: | |
Prescription: | mandatory |
Reporting: | (default) |
Test Control: |
Test Assertion: | RSP1403 |
---|---|
Description: | |
Target: |
|
Prerequisite: | RSP1402 |
Predicate: |
|
Reporting: | true=passed, false=failed |
Prescription: | mandatory |
Error Message: | Some ws-addressing reference parameter header block is not signed with same signature as the SOAP Body of the message (based on @wsu:Id references). |
Diagnostic Data: |
|
Test Assertion Part | What it means: |
---|---|
Test Assertion ID: |
[markup: testAssertion/@id] (required) A unique ID for the current test assertion. |
Description: |
[markup: testAssertion/description ] (optional) A plain text description of the current test assertion. At minimum expressing the TA predicate. |
Comments: |
[markup: testAssertion/comments ] (optional) A plain text comment about the TA script and how well it covers the profile requirement. Explanation material for users, and developers (what could be improved, etc.). |
Target: |
[markup: testAssertion/target ] (required) The artifacts to be tested, defined by an XPath expression that returns a list of XML nodes from the log file in input. For every artifact (node) selected by the Target expression, there will be a report entry for this TA in the test report, with a result of either:
See the "reporting" item for the meaning of these results. |
Cotarget: |
[markup: testAssertion/cotarget ] (optional) Artifact that is related to the target, and that needs be accessed for the testing. Identified by an XPath expression that may refer to the related target node using the variable '$target'. For example, the target can be a SOAP message and the cotarget the WSDL file that describes this SOAP message. A cotarget must have a @name attribute that identifies it. The value of this attribute can be used as a variable (when prepending '$' to it) by subsequently defined cotargets, prerequisite and predicate. |
Prerequisite: |
[markup: testAssertion/@preReq ] (optional) [markup: testAssertion/prerequisite ] (optional) The pre-condition for evaluating this Test Assertion on this target. If the prerequisite evaluates to "false" then the target does not qualify for this Test Assertion (the test report is "notRelevant") The first part (preReq attribute) is an enumeration of Test Assertion IDs. Each one of the prerequisite TAs must either use the same target (e.g. SOAP Envelope, or WSDL binding, etc.) as this TA, or a target that is of a more general type than the main TA target. The target must "pass" each one of these prerequisite TAs in order to qualify for this TA. (e.g. the target of TA t1 can be a WSDL binding while the target of a TA t2 prerequisite of t1, can be the entire WSDL file). The second part ("prerequisite" element) is an XPath (boolean) expression of the same nature as the predicate. If present, it must evaluate to "true" for the target to qualify. If it fails, the result for the current TA in the report will be "notRelevant". Otherwise, the target can be further evaluated by the predicate of the main TA. The expression may refer to the target explicitly using the variable name "$target", or to any cotarget using its name as variable name ($[name]). |
Predicate: |
[markup: testAssertion/predicate] required element] A logical expression that evaluates whether this target is fulfilling the profile requirement addressed by this test Assertion. By default: - A result of true means the requirement is fulfilled (reported as a "passed" in the test report).- A result of false means the requirement is violated (reported as a "failed" in the test report). However, in some cases and for testability reasons, the predicate may be designed as a partial indicator e.g. only indicates some cases of fulfillment, or some cases of violation. As a result, when "true" indicates fulfillment it may be that "false" is unconclusive, or conversely "false" will indicate violation, but "true" is unconclusive. In such cases, the "Reporting" element specifies the meaning of the predicate result w/r to the profile requirement. The predicate expression implicitly refers to the target (whic is its "XPath context") although it may explicitly refer to it using the variable name "$target". It may refer to any cotarget using its name as variable name ($[name]). |
Prescription: |
[markup: testAssertion/prescription/@level ] (required) Conveys the level of prescription associated with the profile requirement. At least three values may be used:
|
Reporting: |
[markup: testAssertion/reporting ] (optional) For each possible outcome of the predicate (true or false), specifies how it must be interpreted w/r to the profile feature. Two attributes are used that both must be present, when this element is present:
NOTES: the predicate of the TA may be worded in a negative way so that @false='passed' although that is not recommended. The result of a test should not be related to the prescription level, e.g. a "preferred" or "permitted" level should not imply that @false='warning'. Other test results that are automatically generated and not controlled by the "reporting" element are:
|
The Profile includes the use of WS-MakeConnection to transfer messages using a transport-specific back-channel.
This section of the Profile incorporates the following specifications by reference, and defines extensibility points within them:
These extensibility points are listed, along with any extensibility points from other sections of this Profile, in Appendix B
The requirements and supporting text in this section make use of the following terms:As noted in Section 2 , support for WS-MakeConnection by a specific service is optional. However, a service may require the use of WS-MakeConnection, in which case, for successful interaction with that service, a client will need to support it.
R2011 If an endpoint requires the use of
WS-MakeConnection, any response EPRs in an ENVELOPE transmitted to this endpoint
MUST use either an instance of the MakeConnection Anonymous URI,
the WS-Addressing anonymous URI
(http://www.w3.org/2005/08/addressing/anonymous
), or
the WS-Addressing none URI
(http://www.w3.org/2005/08/addressing/none
) in their
wsa:Address
element. TESTABLE RSP2011a RSP2011b
Test Assertion Analysis: | RSP2011a |
---|---|
General Notes: | |
Coverage Assessment: | partial: |
Target Type: | ENVELOPE |
Test Target: | |
Test co-Target(s): | |
Test Prerequisite: | |
Predicate: | |
Prescription: | mandatory |
Reporting: | true=passed, false=failed |
Test Control: |
Test Assertion: | RSP2011a |
---|---|
Description: | |
Target: |
|
co-Target: myOpBinding |
|
Predicate: |
|
Reporting: | true=passed, false=failed |
Prescription: | mandatory |
Error Message: | A SOAP Envelope with an WSDL rpc-lit binding, and for which the use of MakeConnection was required, did not contain an appropriate wsa:ReplyTo or wsa:FaultTo value (either anonymous URI or a wsa "none" URI) |
Diagnostic Data: |
|
Test Assertion Part | What it means: |
---|---|
Test Assertion ID: |
[markup: testAssertion/@id] (required) A unique ID for the current test assertion. |
Description: |
[markup: testAssertion/description ] (optional) A plain text description of the current test assertion. At minimum expressing the TA predicate. |
Comments: |
[markup: testAssertion/comments ] (optional) A plain text comment about the TA script and how well it covers the profile requirement. Explanation material for users, and developers (what could be improved, etc.). |
Target: |
[markup: testAssertion/target ] (required) The artifacts to be tested, defined by an XPath expression that returns a list of XML nodes from the log file in input. For every artifact (node) selected by the Target expression, there will be a report entry for this TA in the test report, with a result of either:
See the "reporting" item for the meaning of these results. |
Cotarget: |
[markup: testAssertion/cotarget ] (optional) Artifact that is related to the target, and that needs be accessed for the testing. Identified by an XPath expression that may refer to the related target node using the variable '$target'. For example, the target can be a SOAP message and the cotarget the WSDL file that describes this SOAP message. A cotarget must have a @name attribute that identifies it. The value of this attribute can be used as a variable (when prepending '$' to it) by subsequently defined cotargets, prerequisite and predicate. |
Prerequisite: |
[markup: testAssertion/@preReq ] (optional) [markup: testAssertion/prerequisite ] (optional) The pre-condition for evaluating this Test Assertion on this target. If the prerequisite evaluates to "false" then the target does not qualify for this Test Assertion (the test report is "notRelevant") The first part (preReq attribute) is an enumeration of Test Assertion IDs. Each one of the prerequisite TAs must either use the same target (e.g. SOAP Envelope, or WSDL binding, etc.) as this TA, or a target that is of a more general type than the main TA target. The target must "pass" each one of these prerequisite TAs in order to qualify for this TA. (e.g. the target of TA t1 can be a WSDL binding while the target of a TA t2 prerequisite of t1, can be the entire WSDL file). The second part ("prerequisite" element) is an XPath (boolean) expression of the same nature as the predicate. If present, it must evaluate to "true" for the target to qualify. If it fails, the result for the current TA in the report will be "notRelevant". Otherwise, the target can be further evaluated by the predicate of the main TA. The expression may refer to the target explicitly using the variable name "$target", or to any cotarget using its name as variable name ($[name]). |
Predicate: |
[markup: testAssertion/predicate] required element] A logical expression that evaluates whether this target is fulfilling the profile requirement addressed by this test Assertion. By default: - A result of true means the requirement is fulfilled (reported as a "passed" in the test report).- A result of false means the requirement is violated (reported as a "failed" in the test report). However, in some cases and for testability reasons, the predicate may be designed as a partial indicator e.g. only indicates some cases of fulfillment, or some cases of violation. As a result, when "true" indicates fulfillment it may be that "false" is unconclusive, or conversely "false" will indicate violation, but "true" is unconclusive. In such cases, the "Reporting" element specifies the meaning of the predicate result w/r to the profile requirement. The predicate expression implicitly refers to the target (whic is its "XPath context") although it may explicitly refer to it using the variable name "$target". It may refer to any cotarget using its name as variable name ($[name]). |
Prescription: |
[markup: testAssertion/prescription/@level ] (required) Conveys the level of prescription associated with the profile requirement. At least three values may be used:
|
Reporting: |
[markup: testAssertion/reporting ] (optional) For each possible outcome of the predicate (true or false), specifies how it must be interpreted w/r to the profile feature. Two attributes are used that both must be present, when this element is present:
NOTES: the predicate of the TA may be worded in a negative way so that @false='passed' although that is not recommended. The result of a test should not be related to the prescription level, e.g. a "preferred" or "permitted" level should not imply that @false='warning'. Other test results that are automatically generated and not controlled by the "reporting" element are:
|
Test Assertion Analysis: | RSP2011b |
---|---|
General Notes: | |
Coverage Assessment: | partial: |
Target Type: | ENVELOPE |
Test Target: | |
Test co-Target(s): | |
Test Prerequisite: | |
Predicate: | |
Prescription: | mandatory |
Reporting: | true=passed, false=failed |
Test Control: |
Test Assertion: | RSP2011b |
---|---|
Description: | |
Target: |
|
co-Target: myOpBinding |
|
Predicate: |
|
Reporting: | true=passed, false=failed |
Prescription: | mandatory |
Error Message: | A SOAP Envelope with an WSDL doc-lit binding, and for which the use of MakeConnection was required, did not contain an appropriate wsa:ReplyTo or wsa:FaultTo value (either anonymous URI or a wsa "none" URI) |
Diagnostic Data: |
|
Test Assertion Part | What it means: |
---|---|
Test Assertion ID: |
[markup: testAssertion/@id] (required) A unique ID for the current test assertion. |
Description: |
[markup: testAssertion/description ] (optional) A plain text description of the current test assertion. At minimum expressing the TA predicate. |
Comments: |
[markup: testAssertion/comments ] (optional) A plain text comment about the TA script and how well it covers the profile requirement. Explanation material for users, and developers (what could be improved, etc.). |
Target: |
[markup: testAssertion/target ] (required) The artifacts to be tested, defined by an XPath expression that returns a list of XML nodes from the log file in input. For every artifact (node) selected by the Target expression, there will be a report entry for this TA in the test report, with a result of either:
See the "reporting" item for the meaning of these results. |
Cotarget: |
[markup: testAssertion/cotarget ] (optional) Artifact that is related to the target, and that needs be accessed for the testing. Identified by an XPath expression that may refer to the related target node using the variable '$target'. For example, the target can be a SOAP message and the cotarget the WSDL file that describes this SOAP message. A cotarget must have a @name attribute that identifies it. The value of this attribute can be used as a variable (when prepending '$' to it) by subsequently defined cotargets, prerequisite and predicate. |
Prerequisite: |
[markup: testAssertion/@preReq ] (optional) [markup: testAssertion/prerequisite ] (optional) The pre-condition for evaluating this Test Assertion on this target. If the prerequisite evaluates to "false" then the target does not qualify for this Test Assertion (the test report is "notRelevant") The first part (preReq attribute) is an enumeration of Test Assertion IDs. Each one of the prerequisite TAs must either use the same target (e.g. SOAP Envelope, or WSDL binding, etc.) as this TA, or a target that is of a more general type than the main TA target. The target must "pass" each one of these prerequisite TAs in order to qualify for this TA. (e.g. the target of TA t1 can be a WSDL binding while the target of a TA t2 prerequisite of t1, can be the entire WSDL file). The second part ("prerequisite" element) is an XPath (boolean) expression of the same nature as the predicate. If present, it must evaluate to "true" for the target to qualify. If it fails, the result for the current TA in the report will be "notRelevant". Otherwise, the target can be further evaluated by the predicate of the main TA. The expression may refer to the target explicitly using the variable name "$target", or to any cotarget using its name as variable name ($[name]). |
Predicate: |
[markup: testAssertion/predicate] required element] A logical expression that evaluates whether this target is fulfilling the profile requirement addressed by this test Assertion. By default: - A result of true means the requirement is fulfilled (reported as a "passed" in the test report).- A result of false means the requirement is violated (reported as a "failed" in the test report). However, in some cases and for testability reasons, the predicate may be designed as a partial indicator e.g. only indicates some cases of fulfillment, or some cases of violation. As a result, when "true" indicates fulfillment it may be that "false" is unconclusive, or conversely "false" will indicate violation, but "true" is unconclusive. In such cases, the "Reporting" element specifies the meaning of the predicate result w/r to the profile requirement. The predicate expression implicitly refers to the target (whic is its "XPath context") although it may explicitly refer to it using the variable name "$target". It may refer to any cotarget using its name as variable name ($[name]). |
Prescription: |
[markup: testAssertion/prescription/@level ] (required) Conveys the level of prescription associated with the profile requirement. At least three values may be used:
|
Reporting: |
[markup: testAssertion/reporting ] (optional) For each possible outcome of the predicate (true or false), specifies how it must be interpreted w/r to the profile feature. Two attributes are used that both must be present, when this element is present:
NOTES: the predicate of the TA may be worded in a negative way so that @false='passed' although that is not recommended. The result of a test should not be related to the prescription level, e.g. a "preferred" or "permitted" level should not imply that @false='warning'. Other test results that are automatically generated and not controlled by the "reporting" element are:
|
R2012 If an endpoint supports the use of
WS-MakeConnection, the INSTANCE corresponding to that endpoint
MUST NOT generate a fault due to the use of the
wsmc:MakeConnection
message. TESTABLE RSP2012
Test Assertion Analysis: | RSP2012 |
---|---|
General Notes: | |
Coverage Assessment: | partial: |
Target Type: | ENVELOPE |
Test Target: | |
Test co-Target(s): | |
Test Prerequisite: | |
Predicate: | |
Prescription: | mandatory |
Reporting: | true=passed, false=failed |
Test Control: |
Test Assertion: | RSP2012 |
---|---|
Description: | |
Target: |
|
Predicate: |
|
Reporting: | true=passed, false=failed |
Prescription: | mandatory |
Error Message: | A SOAP Envelope with an HTTP 500 error code in response to a MakeConnection, in a context where the use of MC is required (MCSupported), contains a Fault with 'ActionNotSupported' code value. |
Diagnostic Data: |
|
Test Assertion Part | What it means: |
---|---|
Test Assertion ID: |
[markup: testAssertion/@id] (required) A unique ID for the current test assertion. |
Description: |
[markup: testAssertion/description ] (optional) A plain text description of the current test assertion. At minimum expressing the TA predicate. |
Comments: |
[markup: testAssertion/comments ] (optional) A plain text comment about the TA script and how well it covers the profile requirement. Explanation material for users, and developers (what could be improved, etc.). |
Target: |
[markup: testAssertion/target ] (required) The artifacts to be tested, defined by an XPath expression that returns a list of XML nodes from the log file in input. For every artifact (node) selected by the Target expression, there will be a report entry for this TA in the test report, with a result of either:
See the "reporting" item for the meaning of these results. |
Cotarget: |
[markup: testAssertion/cotarget ] (optional) Artifact that is related to the target, and that needs be accessed for the testing. Identified by an XPath expression that may refer to the related target node using the variable '$target'. For example, the target can be a SOAP message and the cotarget the WSDL file that describes this SOAP message. A cotarget must have a @name attribute that identifies it. The value of this attribute can be used as a variable (when prepending '$' to it) by subsequently defined cotargets, prerequisite and predicate. |
Prerequisite: |
[markup: testAssertion/@preReq ] (optional) [markup: testAssertion/prerequisite ] (optional) The pre-condition for evaluating this Test Assertion on this target. If the prerequisite evaluates to "false" then the target does not qualify for this Test Assertion (the test report is "notRelevant") The first part (preReq attribute) is an enumeration of Test Assertion IDs. Each one of the prerequisite TAs must either use the same target (e.g. SOAP Envelope, or WSDL binding, etc.) as this TA, or a target that is of a more general type than the main TA target. The target must "pass" each one of these prerequisite TAs in order to qualify for this TA. (e.g. the target of TA t1 can be a WSDL binding while the target of a TA t2 prerequisite of t1, can be the entire WSDL file). The second part ("prerequisite" element) is an XPath (boolean) expression of the same nature as the predicate. If present, it must evaluate to "true" for the target to qualify. If it fails, the result for the current TA in the report will be "notRelevant". Otherwise, the target can be further evaluated by the predicate of the main TA. The expression may refer to the target explicitly using the variable name "$target", or to any cotarget using its name as variable name ($[name]). |
Predicate: |
[markup: testAssertion/predicate] required element] A logical expression that evaluates whether this target is fulfilling the profile requirement addressed by this test Assertion. By default: - A result of true means the requirement is fulfilled (reported as a "passed" in the test report).- A result of false means the requirement is violated (reported as a "failed" in the test report). However, in some cases and for testability reasons, the predicate may be designed as a partial indicator e.g. only indicates some cases of fulfillment, or some cases of violation. As a result, when "true" indicates fulfillment it may be that "false" is unconclusive, or conversely "false" will indicate violation, but "true" is unconclusive. In such cases, the "Reporting" element specifies the meaning of the predicate result w/r to the profile requirement. The predicate expression implicitly refers to the target (whic is its "XPath context") although it may explicitly refer to it using the variable name "$target". It may refer to any cotarget using its name as variable name ($[name]). |
Prescription: |
[markup: testAssertion/prescription/@level ] (required) Conveys the level of prescription associated with the profile requirement. At least three values may be used:
|
Reporting: |
[markup: testAssertion/reporting ] (optional) For each possible outcome of the predicate (true or false), specifies how it must be interpreted w/r to the profile feature. Two attributes are used that both must be present, when this element is present:
NOTES: the predicate of the TA may be worded in a negative way so that @false='passed' although that is not recommended. The result of a test should not be related to the prescription level, e.g. a "preferred" or "permitted" level should not imply that @false='warning'. Other test results that are automatically generated and not controlled by the "reporting" element are:
|
R2013 If an endpoint supports the use of
WS-MakeConnection, the INSTANCE corresponding to that endpoint
MUST NOT generate a fault due to the use of a MakeConnection
Anonymous URI in the wsa:Address
element on any
response EPRs in a request message. TESTABLE RSP2013
Test Assertion Analysis: | RSP2013 |
---|---|
General Notes: | |
Coverage Assessment: | partial: |
Target Type: | ENVELOPE |
Test Target: | |
Test co-Target(s): | |
Test Prerequisite: | |
Predicate: | |
Prescription: | mandatory |
Reporting: | true=passed, false=failed |
Test Control: |
Test Assertion: | RSP2013 |
---|---|
Description: | |
Target: |
|
Predicate: |
|
Reporting: | true=passed, false=warning |
Prescription: | mandatory |
Error Message: | A SOAP Envelope in response to a request with ReplyTo address set to MakeConnection anonymous URI, in a context where the use of MC is required (MCSupported) contains a Fault with 'InvalidAddressingHeader' code value. |
Diagnostic Data: |
|
Test Assertion Part | What it means: |
---|---|
Test Assertion ID: |
[markup: testAssertion/@id] (required) A unique ID for the current test assertion. |
Description: |
[markup: testAssertion/description ] (optional) A plain text description of the current test assertion. At minimum expressing the TA predicate. |
Comments: |
[markup: testAssertion/comments ] (optional) A plain text comment about the TA script and how well it covers the profile requirement. Explanation material for users, and developers (what could be improved, etc.). |
Target: |
[markup: testAssertion/target ] (required) The artifacts to be tested, defined by an XPath expression that returns a list of XML nodes from the log file in input. For every artifact (node) selected by the Target expression, there will be a report entry for this TA in the test report, with a result of either:
See the "reporting" item for the meaning of these results. |
Cotarget: |
[markup: testAssertion/cotarget ] (optional) Artifact that is related to the target, and that needs be accessed for the testing. Identified by an XPath expression that may refer to the related target node using the variable '$target'. For example, the target can be a SOAP message and the cotarget the WSDL file that describes this SOAP message. A cotarget must have a @name attribute that identifies it. The value of this attribute can be used as a variable (when prepending '$' to it) by subsequently defined cotargets, prerequisite and predicate. |
Prerequisite: |
[markup: testAssertion/@preReq ] (optional) [markup: testAssertion/prerequisite ] (optional) The pre-condition for evaluating this Test Assertion on this target. If the prerequisite evaluates to "false" then the target does not qualify for this Test Assertion (the test report is "notRelevant") The first part (preReq attribute) is an enumeration of Test Assertion IDs. Each one of the prerequisite TAs must either use the same target (e.g. SOAP Envelope, or WSDL binding, etc.) as this TA, or a target that is of a more general type than the main TA target. The target must "pass" each one of these prerequisite TAs in order to qualify for this TA. (e.g. the target of TA t1 can be a WSDL binding while the target of a TA t2 prerequisite of t1, can be the entire WSDL file). The second part ("prerequisite" element) is an XPath (boolean) expression of the same nature as the predicate. If present, it must evaluate to "true" for the target to qualify. If it fails, the result for the current TA in the report will be "notRelevant". Otherwise, the target can be further evaluated by the predicate of the main TA. The expression may refer to the target explicitly using the variable name "$target", or to any cotarget using its name as variable name ($[name]). |
Predicate: |
[markup: testAssertion/predicate] required element] A logical expression that evaluates whether this target is fulfilling the profile requirement addressed by this test Assertion. By default: - A result of true means the requirement is fulfilled (reported as a "passed" in the test report).- A result of false means the requirement is violated (reported as a "failed" in the test report). However, in some cases and for testability reasons, the predicate may be designed as a partial indicator e.g. only indicates some cases of fulfillment, or some cases of violation. As a result, when "true" indicates fulfillment it may be that "false" is unconclusive, or conversely "false" will indicate violation, but "true" is unconclusive. In such cases, the "Reporting" element specifies the meaning of the predicate result w/r to the profile requirement. The predicate expression implicitly refers to the target (whic is its "XPath context") although it may explicitly refer to it using the variable name "$target". It may refer to any cotarget using its name as variable name ($[name]). |
Prescription: |
[markup: testAssertion/prescription/@level ] (required) Conveys the level of prescription associated with the profile requirement. At least three values may be used:
|
Reporting: |
[markup: testAssertion/reporting ] (optional) For each possible outcome of the predicate (true or false), specifies how it must be interpreted w/r to the profile feature. Two attributes are used that both must be present, when this element is present:
NOTES: the predicate of the TA may be worded in a negative way so that @false='passed' although that is not recommended. The result of a test should not be related to the prescription level, e.g. a "preferred" or "permitted" level should not imply that @false='warning'. Other test results that are automatically generated and not controlled by the "reporting" element are:
|
R2014 If an endpoint requires the use of
WS-MakeConnection, any MESSAGE transmitted from this endpoint
MUST be transmitted over a connection that is associated with
either an instance of the WS-MakeConnection Anonymous URI or the
WS-Addressing anonymous URI
(http://www.w3.org/2005/08/addressing/anonymous
).
TESTABLE RSP2014a RSP2014b
Test Assertion: | RSP2014a |
---|---|
Description: | If an endpoint using a doc-lit binding requires the use of WS-MakeConnection, any MESSAGE transmitted from this endpoint MUST be transmitted over a connection that is associated with either an instance of the WS-MakeConnection Anonymous URI or the WS-Addressing anonymous URI (http://www.w3.org/2005/08/addressing/anonymous). |
Target: |
|
co-Target: myOpBinding |
|
Predicate: |
|
Reporting: | true=passed, false=failed |
Prescription: | mandatory |
Error Message: | In a context where the use of MC is required (MCSupported), a response message in a WSDL doc/lit request-response exchange was sent over an HTTP request. |
Diagnostic Data: |
|
Test Assertion Part | What it means: |
---|---|
Test Assertion ID: |
[markup: testAssertion/@id] (required) A unique ID for the current test assertion. |
Description: |
[markup: testAssertion/description ] (optional) A plain text description of the current test assertion. At minimum expressing the TA predicate. |
Comments: |
[markup: testAssertion/comments ] (optional) A plain text comment about the TA script and how well it covers the profile requirement. Explanation material for users, and developers (what could be improved, etc.). |
Target: |
[markup: testAssertion/target ] (required) The artifacts to be tested, defined by an XPath expression that returns a list of XML nodes from the log file in input. For every artifact (node) selected by the Target expression, there will be a report entry for this TA in the test report, with a result of either:
See the "reporting" item for the meaning of these results. |
Cotarget: |
[markup: testAssertion/cotarget ] (optional) Artifact that is related to the target, and that needs be accessed for the testing. Identified by an XPath expression that may refer to the related target node using the variable '$target'. For example, the target can be a SOAP message and the cotarget the WSDL file that describes this SOAP message. A cotarget must have a @name attribute that identifies it. The value of this attribute can be used as a variable (when prepending '$' to it) by subsequently defined cotargets, prerequisite and predicate. |
Prerequisite: |
[markup: testAssertion/@preReq ] (optional) [markup: testAssertion/prerequisite ] (optional) The pre-condition for evaluating this Test Assertion on this target. If the prerequisite evaluates to "false" then the target does not qualify for this Test Assertion (the test report is "notRelevant") The first part (preReq attribute) is an enumeration of Test Assertion IDs. Each one of the prerequisite TAs must either use the same target (e.g. SOAP Envelope, or WSDL binding, etc.) as this TA, or a target that is of a more general type than the main TA target. The target must "pass" each one of these prerequisite TAs in order to qualify for this TA. (e.g. the target of TA t1 can be a WSDL binding while the target of a TA t2 prerequisite of t1, can be the entire WSDL file). The second part ("prerequisite" element) is an XPath (boolean) expression of the same nature as the predicate. If present, it must evaluate to "true" for the target to qualify. If it fails, the result for the current TA in the report will be "notRelevant". Otherwise, the target can be further evaluated by the predicate of the main TA. The expression may refer to the target explicitly using the variable name "$target", or to any cotarget using its name as variable name ($[name]). |
Predicate: |
[markup: testAssertion/predicate] required element] A logical expression that evaluates whether this target is fulfilling the profile requirement addressed by this test Assertion. By default: - A result of true means the requirement is fulfilled (reported as a "passed" in the test report).- A result of false means the requirement is violated (reported as a "failed" in the test report). However, in some cases and for testability reasons, the predicate may be designed as a partial indicator e.g. only indicates some cases of fulfillment, or some cases of violation. As a result, when "true" indicates fulfillment it may be that "false" is unconclusive, or conversely "false" will indicate violation, but "true" is unconclusive. In such cases, the "Reporting" element specifies the meaning of the predicate result w/r to the profile requirement. The predicate expression implicitly refers to the target (whic is its "XPath context") although it may explicitly refer to it using the variable name "$target". It may refer to any cotarget using its name as variable name ($[name]). |
Prescription: |
[markup: testAssertion/prescription/@level ] (required) Conveys the level of prescription associated with the profile requirement. At least three values may be used:
|
Reporting: |
[markup: testAssertion/reporting ] (optional) For each possible outcome of the predicate (true or false), specifies how it must be interpreted w/r to the profile feature. Two attributes are used that both must be present, when this element is present:
NOTES: the predicate of the TA may be worded in a negative way so that @false='passed' although that is not recommended. The result of a test should not be related to the prescription level, e.g. a "preferred" or "permitted" level should not imply that @false='warning'. Other test results that are automatically generated and not controlled by the "reporting" element are:
|
Test Assertion: | RSP2014b |
---|---|
Description: | If an endpoint using a rpc-lit binding requires the use of WS-MakeConnection, any MESSAGE transmitted from this endpoint MUST be transmitted over a connection that is associated with either an instance of the WS-MakeConnection Anonymous URI or the WS-Addressing anonymous URI (http://www.w3.org/2005/08/addressing/anonymous). |
Target: |
|
co-Target: myOpBinding |
|
Predicate: |
|
Reporting: | true=passed, false=failed |
Prescription: | mandatory |
Error Message: | In a context where the use of MC is required (MCSupported), a response message in a WSDL rpc/lit request-response exchange was sent over an HTTP request. |
Diagnostic Data: |
|
Test Assertion Part | What it means: |
---|---|
Test Assertion ID: |
[markup: testAssertion/@id] (required) A unique ID for the current test assertion. |
Description: |
[markup: testAssertion/description ] (optional) A plain text description of the current test assertion. At minimum expressing the TA predicate. |
Comments: |
[markup: testAssertion/comments ] (optional) A plain text comment about the TA script and how well it covers the profile requirement. Explanation material for users, and developers (what could be improved, etc.). |
Target: |
[markup: testAssertion/target ] (required) The artifacts to be tested, defined by an XPath expression that returns a list of XML nodes from the log file in input. For every artifact (node) selected by the Target expression, there will be a report entry for this TA in the test report, with a result of either:
See the "reporting" item for the meaning of these results. |
Cotarget: |
[markup: testAssertion/cotarget ] (optional) Artifact that is related to the target, and that needs be accessed for the testing. Identified by an XPath expression that may refer to the related target node using the variable '$target'. For example, the target can be a SOAP message and the cotarget the WSDL file that describes this SOAP message. A cotarget must have a @name attribute that identifies it. The value of this attribute can be used as a variable (when prepending '$' to it) by subsequently defined cotargets, prerequisite and predicate. |
Prerequisite: |
[markup: testAssertion/@preReq ] (optional) [markup: testAssertion/prerequisite ] (optional) The pre-condition for evaluating this Test Assertion on this target. If the prerequisite evaluates to "false" then the target does not qualify for this Test Assertion (the test report is "notRelevant") The first part (preReq attribute) is an enumeration of Test Assertion IDs. Each one of the prerequisite TAs must either use the same target (e.g. SOAP Envelope, or WSDL binding, etc.) as this TA, or a target that is of a more general type than the main TA target. The target must "pass" each one of these prerequisite TAs in order to qualify for this TA. (e.g. the target of TA t1 can be a WSDL binding while the target of a TA t2 prerequisite of t1, can be the entire WSDL file). The second part ("prerequisite" element) is an XPath (boolean) expression of the same nature as the predicate. If present, it must evaluate to "true" for the target to qualify. If it fails, the result for the current TA in the report will be "notRelevant". Otherwise, the target can be further evaluated by the predicate of the main TA. The expression may refer to the target explicitly using the variable name "$target", or to any cotarget using its name as variable name ($[name]). |
Predicate: |
[markup: testAssertion/predicate] required element] A logical expression that evaluates whether this target is fulfilling the profile requirement addressed by this test Assertion. By default: - A result of true means the requirement is fulfilled (reported as a "passed" in the test report).- A result of false means the requirement is violated (reported as a "failed" in the test report). However, in some cases and for testability reasons, the predicate may be designed as a partial indicator e.g. only indicates some cases of fulfillment, or some cases of violation. As a result, when "true" indicates fulfillment it may be that "false" is unconclusive, or conversely "false" will indicate violation, but "true" is unconclusive. In such cases, the "Reporting" element specifies the meaning of the predicate result w/r to the profile requirement. The predicate expression implicitly refers to the target (whic is its "XPath context") although it may explicitly refer to it using the variable name "$target". It may refer to any cotarget using its name as variable name ($[name]). |
Prescription: |
[markup: testAssertion/prescription/@level ] (required) Conveys the level of prescription associated with the profile requirement. At least three values may be used:
|
Reporting: |
[markup: testAssertion/reporting ] (optional) For each possible outcome of the predicate (true or false), specifies how it must be interpreted w/r to the profile feature. Two attributes are used that both must be present, when this element is present:
NOTES: the predicate of the TA may be worded in a negative way so that @false='passed' although that is not recommended. The result of a test should not be related to the prescription level, e.g. a "preferred" or "permitted" level should not imply that @false='warning'. Other test results that are automatically generated and not controlled by the "reporting" element are:
|
The association referred to in R2014 can be established by
either a request message that carries response EPRs that use
instances of the MakeConnection Anonymous URI, a request message
that carries response EPRs that use instances of the WS-Addressing
Anonymous URI, or a wsmc:MakeConnection
message.
This section describes how, when wsmc:MakeConnection is used, WSDL input and output messages correspond to SOAP envelopes containing a request or a response sent over HTTP.
The WS-MakeConnection specification, while not formally requiring the use of WS-Addressing headers, neglects to mention what the wsa:Action and soapAction URIs should be - when needed.
R2030 If an ENVELOPE contains a wsmc:MakeConnection
element as the child of the SOAP Body, the wsa:Action
header, if present, MUST contain the value
"http://docs.oasis-open.org/ws-rx/wsmc/200702/MakeConnection".
TESTABLE RSP2030
Test Assertion Analysis: | RSP2030 |
---|---|
General Notes: | . |
Coverage Assessment: | Good |
Target Type: | ENVELOPE |
Test Target: | For an Envelope with s:Body/MC and wsa:Action header |
Test co-Target(s): | |
Test Prerequisite: | |
Predicate: | wsa:Action value is http://docs.oasis-open.org/ws-rx/wsmc/200702/MakeConnection |
Prescription: | mandatory |
Reporting: | (default) |
Test Control: |
Test Assertion: | RSP2030 |
---|---|
Description: | |
Target: |
[*:Body/wsmc:MakeConnection and *:Header/wsa:Action] |
Predicate: |
|
Reporting: | true=passed, false=failed |
Prescription: | mandatory |
Error Message: | An Envelope with soap:Body/wsmc:MakeConnection and wsa:Action header, does not have http://docs.oasis-open.org/ws-rx/wsmc/200702/MakeConnection in wsa:Action. |
Diagnostic Data: |
|
Test Assertion Part | What it means: |
---|---|
Test Assertion ID: |
[markup: testAssertion/@id] (required) A unique ID for the current test assertion. |
Description: |
[markup: testAssertion/description ] (optional) A plain text description of the current test assertion. At minimum expressing the TA predicate. |
Comments: |
[markup: testAssertion/comments ] (optional) A plain text comment about the TA script and how well it covers the profile requirement. Explanation material for users, and developers (what could be improved, etc.). |
Target: |
[markup: testAssertion/target ] (required) The artifacts to be tested, defined by an XPath expression that returns a list of XML nodes from the log file in input. For every artifact (node) selected by the Target expression, there will be a report entry for this TA in the test report, with a result of either:
See the "reporting" item for the meaning of these results. |
Cotarget: |
[markup: testAssertion/cotarget ] (optional) Artifact that is related to the target, and that needs be accessed for the testing. Identified by an XPath expression that may refer to the related target node using the variable '$target'. For example, the target can be a SOAP message and the cotarget the WSDL file that describes this SOAP message. A cotarget must have a @name attribute that identifies it. The value of this attribute can be used as a variable (when prepending '$' to it) by subsequently defined cotargets, prerequisite and predicate. |
Prerequisite: |
[markup: testAssertion/@preReq ] (optional) [markup: testAssertion/prerequisite ] (optional) The pre-condition for evaluating this Test Assertion on this target. If the prerequisite evaluates to "false" then the target does not qualify for this Test Assertion (the test report is "notRelevant") The first part (preReq attribute) is an enumeration of Test Assertion IDs. Each one of the prerequisite TAs must either use the same target (e.g. SOAP Envelope, or WSDL binding, etc.) as this TA, or a target that is of a more general type than the main TA target. The target must "pass" each one of these prerequisite TAs in order to qualify for this TA. (e.g. the target of TA t1 can be a WSDL binding while the target of a TA t2 prerequisite of t1, can be the entire WSDL file). The second part ("prerequisite" element) is an XPath (boolean) expression of the same nature as the predicate. If present, it must evaluate to "true" for the target to qualify. If it fails, the result for the current TA in the report will be "notRelevant". Otherwise, the target can be further evaluated by the predicate of the main TA. The expression may refer to the target explicitly using the variable name "$target", or to any cotarget using its name as variable name ($[name]). |
Predicate: |
[markup: testAssertion/predicate] required element] A logical expression that evaluates whether this target is fulfilling the profile requirement addressed by this test Assertion. By default: - A result of true means the requirement is fulfilled (reported as a "passed" in the test report).- A result of false means the requirement is violated (reported as a "failed" in the test report). However, in some cases and for testability reasons, the predicate may be designed as a partial indicator e.g. only indicates some cases of fulfillment, or some cases of violation. As a result, when "true" indicates fulfillment it may be that "false" is unconclusive, or conversely "false" will indicate violation, but "true" is unconclusive. In such cases, the "Reporting" element specifies the meaning of the predicate result w/r to the profile requirement. The predicate expression implicitly refers to the target (whic is its "XPath context") although it may explicitly refer to it using the variable name "$target". It may refer to any cotarget using its name as variable name ($[name]). |
Prescription: |
[markup: testAssertion/prescription/@level ] (required) Conveys the level of prescription associated with the profile requirement. At least three values may be used:
|
Reporting: |
[markup: testAssertion/reporting ] (optional) For each possible outcome of the predicate (true or false), specifies how it must be interpreted w/r to the profile feature. Two attributes are used that both must be present, when this element is present:
NOTES: the predicate of the TA may be worded in a negative way so that @false='passed' although that is not recommended. The result of a test should not be related to the prescription level, e.g. a "preferred" or "permitted" level should not imply that @false='warning'. Other test results that are automatically generated and not controlled by the "reporting" element are:
|
R2031 If a MESSAGE contains a SOAP 1.1 envelope with
the wsmc:MakeConnection element as the child of the Body, the HTTP
SOAPAction
header, if present and not equal to the
value of "" (empty string), MUST contain the value
"http://docs.oasis-open.org/ws-rx/wsmc/200702/MakeConnection".
TESTABLE RSP2031
Test Assertion Analysis: | RSP2031 |
---|---|
General Notes: | If a MESSAGE contains a SOAP 1.1 envelope with the wsmc:MakeConnection element as the child of the Body, the HTTP SOAPAction header, if present and not equal to the value of "" (empty string), MUST contain the value "http://docs.oasis-open.org/ws-rx/wsmc/200702/MakeConnection. |
Coverage Assessment: | Good |
Target Type: | MESSAGE |
Test Target: | For a Message with sopa11:Body/MC and HTTP SOAPAction header |
Test co-Target(s): | |
Test Prerequisite: | |
Predicate: | either SOAPAction value isempty string, or "http://docs.oasis-open.org/ws-rx/wsmc/200702/MakeConnection" |
Prescription: | mandatory |
Reporting: | (default) |
Test Control: |
Test Assertion: | RSP2031 |
---|---|
Description: | |
Target: |
[wsil:messageContents/soap11:Envelope/soap11:Body/wsmc:MakeConnection and (some $ky in wsil:httpHeaders/wsil:httpHeader/@key satisfies fn:lower-case($ky) = 'soapaction' )] |
Predicate: |
(wsil:httpHeaders/wsil:httpHeader[fn:lower-case(@key) =
'soapaction']/@value =
'http://docs.oasis-open.org/ws-rx/wsmc/200702/MakeConnection'
andor wsil:httpHeaders/wsil:httpHeader[fn:lower-case(@key) = 'soapaction']/@value = '' )
(wsil:httpHeaders/wsil:httpHeader[fn:lower-case(@key) =
'soapaction']/@quoted = 'true' or
not (wsil:httpHeaders/wsil:httpHeader[fn:lower-case(@key) = 'soapaction']/@quoted )) |
Reporting: | true=passed, false=failed |
Prescription: | mandatory |
Error Message: | A message containing wsmc:MakeConnection has a non-empty SOAPAction header value different from 'http://docs.oasis-open.org/ws-rx/wsmc/200702/MakeConnection' or this HTTP header is not quoted. |
Diagnostic Data: |
|
Test Assertion Part | What it means: |
---|---|
Test Assertion ID: |
[markup: testAssertion/@id] (required) A unique ID for the current test assertion. |
Description: |
[markup: testAssertion/description ] (optional) A plain text description of the current test assertion. At minimum expressing the TA predicate. |
Comments: |
[markup: testAssertion/comments ] (optional) A plain text comment about the TA script and how well it covers the profile requirement. Explanation material for users, and developers (what could be improved, etc.). |
Target: |
[markup: testAssertion/target ] (required) The artifacts to be tested, defined by an XPath expression that returns a list of XML nodes from the log file in input. For every artifact (node) selected by the Target expression, there will be a report entry for this TA in the test report, with a result of either:
See the "reporting" item for the meaning of these results. |
Cotarget: |
[markup: testAssertion/cotarget ] (optional) Artifact that is related to the target, and that needs be accessed for the testing. Identified by an XPath expression that may refer to the related target node using the variable '$target'. For example, the target can be a SOAP message and the cotarget the WSDL file that describes this SOAP message. A cotarget must have a @name attribute that identifies it. The value of this attribute can be used as a variable (when prepending '$' to it) by subsequently defined cotargets, prerequisite and predicate. |
Prerequisite: |
[markup: testAssertion/@preReq ] (optional) [markup: testAssertion/prerequisite ] (optional) The pre-condition for evaluating this Test Assertion on this target. If the prerequisite evaluates to "false" then the target does not qualify for this Test Assertion (the test report is "notRelevant") The first part (preReq attribute) is an enumeration of Test Assertion IDs. Each one of the prerequisite TAs must either use the same target (e.g. SOAP Envelope, or WSDL binding, etc.) as this TA, or a target that is of a more general type than the main TA target. The target must "pass" each one of these prerequisite TAs in order to qualify for this TA. (e.g. the target of TA t1 can be a WSDL binding while the target of a TA t2 prerequisite of t1, can be the entire WSDL file). The second part ("prerequisite" element) is an XPath (boolean) expression of the same nature as the predicate. If present, it must evaluate to "true" for the target to qualify. If it fails, the result for the current TA in the report will be "notRelevant". Otherwise, the target can be further evaluated by the predicate of the main TA. The expression may refer to the target explicitly using the variable name "$target", or to any cotarget using its name as variable name ($[name]). |
Predicate: |
[markup: testAssertion/predicate] required element] A logical expression that evaluates whether this target is fulfilling the profile requirement addressed by this test Assertion. By default: - A result of true means the requirement is fulfilled (reported as a "passed" in the test report).- A result of false means the requirement is violated (reported as a "failed" in the test report). However, in some cases and for testability reasons, the predicate may be designed as a partial indicator e.g. only indicates some cases of fulfillment, or some cases of violation. As a result, when "true" indicates fulfillment it may be that "false" is unconclusive, or conversely "false" will indicate violation, but "true" is unconclusive. In such cases, the "Reporting" element specifies the meaning of the predicate result w/r to the profile requirement. The predicate expression implicitly refers to the target (whic is its "XPath context") although it may explicitly refer to it using the variable name "$target". It may refer to any cotarget using its name as variable name ($[name]). |
Prescription: |
[markup: testAssertion/prescription/@level ] (required) Conveys the level of prescription associated with the profile requirement. At least three values may be used:
|
Reporting: |
[markup: testAssertion/reporting ] (optional) For each possible outcome of the predicate (true or false), specifies how it must be interpreted w/r to the profile feature. Two attributes are used that both must be present, when this element is present:
NOTES: the predicate of the TA may be worded in a negative way so that @false='passed' although that is not recommended. The result of a test should not be related to the prescription level, e.g. a "preferred" or "permitted" level should not imply that @false='warning'. Other test results that are automatically generated and not controlled by the "reporting" element are:
|
R2032 If a MESSAGE contains a SOAP 1.2 envelope with
the wsmc:MakeConnection element as the child of the Body, the
action
parameter of the HTTP Content-Type
header, if present, MUST contain the value
"http://docs.oasis-open.org/ws-rx/wsmc/200702/MakeConnection".
TESTABLE RSP2032
Test Assertion Analysis: | RSP2032 |
---|---|
General Notes: | If a MESSAGE contains a SOAP 1.2 envelope with the wsmc:MakeConnection element as the child of the Body, the action parameter of the HTTP Content-Type header, if present, MUST contain the value "http://docs.oasis-open.org/ws-rx/wsmc/200702/MakeConnection" |
Coverage Assessment: | Good |
Target Type: | MESSAGE |
Test Target: | For an Message with sopa12:Body/MC and action parameter of the HTTP Content-Type header |
Test co-Target(s): | |
Test Prerequisite: | |
Predicate: | action parameter ="http://docs.oasis-open.org/ws-rx/wsmc/200702/MakeConnection" |
Prescription: | mandatory |
Reporting: | (default) |
Test Control: |
Test Assertion: | RSP2032 |
---|---|
Description: | |
Target: |
[wsil:messageContents/soap12:Envelope/soap12:Body/wsmc:MakeConnection and (wsil:httpHeaders/wsil:contentTypeHeader/wsil:parameter/@key = 'action' )] |
Predicate: |
|
Reporting: | true=passed, false=failed |
Prescription: | mandatory |
Error Message: | In a SOAP 1.2 MESSAGE with the wsmc:MakeConnection element, the action parameter of the HTTP Content-Type header does not contain the value "http://docs.oasis-open.org/ws-rx/wsmc/200702/MakeConnection". |
Diagnostic Data: |
|
Test Assertion Part | What it means: |
---|---|
Test Assertion ID: |
[markup: testAssertion/@id] (required) A unique ID for the current test assertion. |
Description: |
[markup: testAssertion/description ] (optional) A plain text description of the current test assertion. At minimum expressing the TA predicate. |
Comments: |
[markup: testAssertion/comments ] (optional) A plain text comment about the TA script and how well it covers the profile requirement. Explanation material for users, and developers (what could be improved, etc.). |
Target: |
[markup: testAssertion/target ] (required) The artifacts to be tested, defined by an XPath expression that returns a list of XML nodes from the log file in input. For every artifact (node) selected by the Target expression, there will be a report entry for this TA in the test report, with a result of either:
See the "reporting" item for the meaning of these results. |
Cotarget: |
[markup: testAssertion/cotarget ] (optional) Artifact that is related to the target, and that needs be accessed for the testing. Identified by an XPath expression that may refer to the related target node using the variable '$target'. For example, the target can be a SOAP message and the cotarget the WSDL file that describes this SOAP message. A cotarget must have a @name attribute that identifies it. The value of this attribute can be used as a variable (when prepending '$' to it) by subsequently defined cotargets, prerequisite and predicate. |
Prerequisite: |
[markup: testAssertion/@preReq ] (optional) [markup: testAssertion/prerequisite ] (optional) The pre-condition for evaluating this Test Assertion on this target. If the prerequisite evaluates to "false" then the target does not qualify for this Test Assertion (the test report is "notRelevant") The first part (preReq attribute) is an enumeration of Test Assertion IDs. Each one of the prerequisite TAs must either use the same target (e.g. SOAP Envelope, or WSDL binding, etc.) as this TA, or a target that is of a more general type than the main TA target. The target must "pass" each one of these prerequisite TAs in order to qualify for this TA. (e.g. the target of TA t1 can be a WSDL binding while the target of a TA t2 prerequisite of t1, can be the entire WSDL file). The second part ("prerequisite" element) is an XPath (boolean) expression of the same nature as the predicate. If present, it must evaluate to "true" for the target to qualify. If it fails, the result for the current TA in the report will be "notRelevant". Otherwise, the target can be further evaluated by the predicate of the main TA. The expression may refer to the target explicitly using the variable name "$target", or to any cotarget using its name as variable name ($[name]). |
Predicate: |
[markup: testAssertion/predicate] required element] A logical expression that evaluates whether this target is fulfilling the profile requirement addressed by this test Assertion. By default: - A result of true means the requirement is fulfilled (reported as a "passed" in the test report).- A result of false means the requirement is violated (reported as a "failed" in the test report). However, in some cases and for testability reasons, the predicate may be designed as a partial indicator e.g. only indicates some cases of fulfillment, or some cases of violation. As a result, when "true" indicates fulfillment it may be that "false" is unconclusive, or conversely "false" will indicate violation, but "true" is unconclusive. In such cases, the "Reporting" element specifies the meaning of the predicate result w/r to the profile requirement. The predicate expression implicitly refers to the target (whic is its "XPath context") although it may explicitly refer to it using the variable name "$target". It may refer to any cotarget using its name as variable name ($[name]). |
Prescription: |
[markup: testAssertion/prescription/@level ] (required) Conveys the level of prescription associated with the profile requirement. At least three values may be used:
|
Reporting: |
[markup: testAssertion/reporting ] (optional) For each possible outcome of the predicate (true or false), specifies how it must be interpreted w/r to the profile feature. Two attributes are used that both must be present, when this element is present:
NOTES: the predicate of the TA may be worded in a negative way so that @false='passed' although that is not recommended. The result of a test should not be related to the prescription level, e.g. a "preferred" or "permitted" level should not imply that @false='warning'. Other test results that are automatically generated and not controlled by the "reporting" element are:
|
Consider the case of a non-addressable client NA invoking an addressable service B that supports a WSDL request-response operation. A possible request-response exchange involving wsmc:MakeConnection might take the following form:
Note: If the HTTP response from step 5 above does not contain a response message corresponding to the output message in the WSDL request-response operation, NA repeats step 3 above until a response message corresponding to the output message in the WSDL request-response operation is retrieved from B , as described in step 4.
Now consider the case of an addressable client A invoking a non-addressable service NB . Another possible message exchange involving wsmc:MakeConnection might take the following form:
Note: In step 3 above, if NB encounters an infrastructure level fault resulting from the processing the SOAP request message (that corresponds to and is described by the input message in the WSDL operation supported by NB ), NB will send the fault to A via a separate HTTP request. Notice, this fault message replaces the output message in the WSDL request-response operation, if any, supported by NB .
A non-addressable endpoint may use wsmc:MakeConnection in a SOAP envelope to obtain any pending messages from an endpoint.
The MakeConnection specification does not mandate how long an MCReceiver needs to wait for an outgoing message to be generated - this is left as an implementation choice. For example, in some environments if there is no message ready to be sent back to the MCSender then returning an HTTP 202 immediately might be appropriate, while in some other cases waiting a certain period of time might improve performance with respect to network traffic. Either case could occur.
When the SOAP request-response MEP is in use and the client is non-addressable the general rules for binding SOAP envelopes to HTTP requests messages (as described by the Basic Profile) apply. SOAP envelopes, that are described by the input message of the WSDL operations supported by a service, are bound to HTTP request messages. SOAP envelopes, that are described by the output message of the WSDL operations supported by a service, are bound to HTTP response messages. For non-addressable services the situation is reversed; the SOAP envelopes, that are described by the input message of the WSDL operations supported by the service, are bound to HTTP response messages and SOAP envelopes, that are described by the output message of the WSDL operations supported by the service, are bound to HTTP request messages.
The following requirements extend the requirements defined in Basic Profile:
R2004 When the wsa:ReplyTo addressing property of a request message (SOAP envelope included in the HTTP entity body of the HTTP request) described by the input message of a WSDL request-response operation is set to a MakeConnection anonymous URI, the corresponding response MESSAGE (SOAP envelope included in the HTTP entity body of the HTTP response) described by the WSDL output message of the same WSDL request-response operation MUST be sent as an HTTP response to either the HTTP request that carried the WSDL input message, or to the HTTP request that carried a wsmc:MakeConnection message with the correct MakeConnection anonymous URI.TESTABLE RSP2004a RSP2004b
Test Assertion Analysis: | RSP2004a |
---|---|
General Notes: | When the wsa:ReplyTo addressing property of a request message (SOAP envelope included in the HTTP entity body of the HTTP request) described by the input message of a WSDL request-response operation is set to a MakeConnection anonymous URI, the corresponding response MESSAGE (SOAP envelope included in the HTTP entity body of the HTTP response) described by the WSDL output message of the same WSDL request-response operation MUST be sent as an HTTP response to either the HTTP request that carried the WSDL input message, or to the HTTP request that carried a wsmc:MakeConnection message with the correct MakeConnection anonymous URI. |
Coverage Assessment: | Good |
Target Type: | MESSAGE |
Test Target: | response message to a MakeConnection that has an MC anon ReplyTo |
Test co-Target(s): | related request-response WSDL op |
Test Prerequisite: | |
Predicate: | response message is sent on same HTTP connection (response), or is sent on another HTTP response of a MakeConnection request with same MC URI in wsmc:Address. |
Prescription: | mandatory |
Reporting: | true=passed, false=failed |
Test Control: |
Test Assertion: | RSP2004a |
---|---|
Description: | |
Target: |
[.//*:Envelope[*:Header/wsa:RelatesTo and not(*:Header/wsse:Security//xenc:ReferenceList) and not(*:Body/*:Fault) and not(*:Body/wsrm:*)]] [ some $resp1 in . satisfies some $req1 in /wsil:testLog/wsil:messageLog/wsil:message[.//*:Header/wsa:MessageID = $resp1//wsa:RelatesTo[@RelationshipType = 'http://www.w3.org/2005/08/addressing/reply' or not (@RelationshipType)]] satisfies (
$req1/wsil:messageContents/*:Envelope[not(*:Body/wsmc:MakeConnection)
and fn:contains(xsd:string(./*:Header/wsa:ReplyTo[1]/wsa:Address),
'http://docs.oasis-open.org/ws-rx/wsmc/200702/anonymous?id=') ]
and
]/wsil:testLog/wsil:descriptionFiles/wsil:descriptionFile/wsdl:definitions/wsdl:binding[.//*[@style = 'rpc']]/wsdl:operation[wsdl:input and wsdl:output][@name = fn:local-name-from-QName(node-name($req1//*:Body/*[1]))]) |
co-Target: myRequestMsg |
[.//*:Header/wsa:MessageID = $target//wsa:RelatesTo[@RelationshipType = 'http://www.w3.org/2005/08/addressing/reply' or not (@RelationshipType)] and not (./wsil:messageContents/*:Envelope/*:Body/wsmc:MakeConnection )] |
co-Target: myOpBinding |
[.//*[@style =
'rpc']]/wsdl:operation[wsdl:input and wsdl:output][@name =
fn:local-name-from-QName(node-name($myRequestMsg//*:Body/*[1]))][1]
|
Predicate: |
(some $req2 in /wsil:testLog/wsil:messageLog/wsil:message[@type = 'request' and @conversation = $target/@conversation] satisfies (
$req2/wsil:messageContents/*:Envelope/*:Body/wsmc:MakeConnection/wsmc:Address
=
$myRequestMsg/wsil:messageContents/*:Envelope/*:Header/wsa:ReplyTo/wsa:Address
)
)) |
Reporting: | true=passed, false=failed |
Prescription: | mandatory |
Error Message: | A response message that binds to an rpc-literal WSDL request-response binding, and relates to a request message sent over HTTP request, is not sent over same HTTP connection (response), and is not sent on an HTTP response to a MakeConnection request with same MC URI in wsmc:Address. |
Diagnostic Data: |
|
Test Assertion Part | What it means: |
---|---|
Test Assertion ID: |
[markup: testAssertion/@id] (required) A unique ID for the current test assertion. |
Description: |
[markup: testAssertion/description ] (optional) A plain text description of the current test assertion. At minimum expressing the TA predicate. |
Comments: |
[markup: testAssertion/comments ] (optional) A plain text comment about the TA script and how well it covers the profile requirement. Explanation material for users, and developers (what could be improved, etc.). |
Target: |
[markup: testAssertion/target ] (required) The artifacts to be tested, defined by an XPath expression that returns a list of XML nodes from the log file in input. For every artifact (node) selected by the Target expression, there will be a report entry for this TA in the test report, with a result of either:
See the "reporting" item for the meaning of these results. |
Cotarget: |
[markup: testAssertion/cotarget ] (optional) Artifact that is related to the target, and that needs be accessed for the testing. Identified by an XPath expression that may refer to the related target node using the variable '$target'. For example, the target can be a SOAP message and the cotarget the WSDL file that describes this SOAP message. A cotarget must have a @name attribute that identifies it. The value of this attribute can be used as a variable (when prepending '$' to it) by subsequently defined cotargets, prerequisite and predicate. |
Prerequisite: |
[markup: testAssertion/@preReq ] (optional) [markup: testAssertion/prerequisite ] (optional) The pre-condition for evaluating this Test Assertion on this target. If the prerequisite evaluates to "false" then the target does not qualify for this Test Assertion (the test report is "notRelevant") The first part (preReq attribute) is an enumeration of Test Assertion IDs. Each one of the prerequisite TAs must either use the same target (e.g. SOAP Envelope, or WSDL binding, etc.) as this TA, or a target that is of a more general type than the main TA target. The target must "pass" each one of these prerequisite TAs in order to qualify for this TA. (e.g. the target of TA t1 can be a WSDL binding while the target of a TA t2 prerequisite of t1, can be the entire WSDL file). The second part ("prerequisite" element) is an XPath (boolean) expression of the same nature as the predicate. If present, it must evaluate to "true" for the target to qualify. If it fails, the result for the current TA in the report will be "notRelevant". Otherwise, the target can be further evaluated by the predicate of the main TA. The expression may refer to the target explicitly using the variable name "$target", or to any cotarget using its name as variable name ($[name]). |
Predicate: |
[markup: testAssertion/predicate] required element] A logical expression that evaluates whether this target is fulfilling the profile requirement addressed by this test Assertion. By default: - A result of true means the requirement is fulfilled (reported as a "passed" in the test report).- A result of false means the requirement is violated (reported as a "failed" in the test report). However, in some cases and for testability reasons, the predicate may be designed as a partial indicator e.g. only indicates some cases of fulfillment, or some cases of violation. As a result, when "true" indicates fulfillment it may be that "false" is unconclusive, or conversely "false" will indicate violation, but "true" is unconclusive. In such cases, the "Reporting" element specifies the meaning of the predicate result w/r to the profile requirement. The predicate expression implicitly refers to the target (whic is its "XPath context") although it may explicitly refer to it using the variable name "$target". It may refer to any cotarget using its name as variable name ($[name]). |
Prescription: |
[markup: testAssertion/prescription/@level ] (required) Conveys the level of prescription associated with the profile requirement. At least three values may be used:
|
Reporting: |
[markup: testAssertion/reporting ] (optional) For each possible outcome of the predicate (true or false), specifies how it must be interpreted w/r to the profile feature. Two attributes are used that both must be present, when this element is present:
NOTES: the predicate of the TA may be worded in a negative way so that @false='passed' although that is not recommended. The result of a test should not be related to the prescription level, e.g. a "preferred" or "permitted" level should not imply that @false='warning'. Other test results that are automatically generated and not controlled by the "reporting" element are:
|
Test Assertion Analysis: | RSP2004b |
---|---|
General Notes: | When the wsa:ReplyTo addressing property of a request message (SOAP envelope included in the HTTP entity body of the HTTP request) described by the input message of a WSDL request-response operation is set to a MakeConnection anonymous URI, the corresponding response MESSAGE (SOAP envelope included in the HTTP entity body of the HTTP response) described by the WSDL output message of the same WSDL request-response operation MUST be sent as an HTTP response to either the HTTP request that carried the WSDL input message, or to the HTTP request that carried a wsmc:MakeConnection message with the correct MakeConnection anonymous URI. |
Coverage Assessment: | Good |
Target Type: | MESSAGE |
Test Target: | response message to a MakeConnection that has an MC anon ReplyTo |
Test co-Target(s): | related request-response WSDL op |
Test Prerequisite: | |
Predicate: | response message is sent on same HTTP connection (response), or is sent on another HTTP response of a MakeConnection request with same MC URI in wsmc:Address. |
Prescription: | mandatory |
Reporting: | true=passed, false=failed |
Test Control: |
Test Assertion: | RSP2004b |
---|---|
Description: | |
Target: |
[.//*:Envelope[*:Header/wsa:RelatesTo and not(*:Header/wsse:Security//xenc:ReferenceList) and not(*:Body/*:Fault) and not(*:Body/wsrm:*)]] [ some $resp1 in . satisfies some $req1 in /wsil:testLog/wsil:messageLog/wsil:message[.//*:Header/wsa:MessageID = $resp1//wsa:RelatesTo[@RelationshipType = 'http://www.w3.org/2005/08/addressing/reply' or not (@RelationshipType)]] satisfies (
$req1/wsil:messageContents/*:Envelope[not(*:Body/wsmc:MakeConnection)
and fn:contains(xsd:string(./*:Header/wsa:ReplyTo[1]/wsa:Address),
'http://docs.oasis-open.org/ws-rx/wsmc/200702/anonymous?id=') ]
and
]/wsil:testLog/wsil:descriptionFiles/wsil:descriptionFile/wsdl:definitions/wsdl:message[fn:resolve-QName(xsd:string(wsdl:part[1]/@element), . ) = fn:node-name($req1//*:Envelope/*:Body/*[1])]) |
co-Target: myRequestMsg |
[.//*:Header/wsa:MessageID = $target//wsa:RelatesTo[@RelationshipType = 'http://www.w3.org/2005/08/addressing/reply' or not (@RelationshipType)] and not (./wsil:messageContents/*:Envelope/*:Body/wsmc:MakeConnection )] |
co-Target: myOpBinding |
[wsdl:input and wsdl:output] [ some $opBinding in . satisfies some $dmesg in /wsil:testLog/wsil:descriptionFiles/wsil:descriptionFile/wsdl:definitions/wsdl:message[wsdl:part[fn:resolve-QName(xsd:string(@element), . ) = fn:node-name($myRequestMsg//*:Envelope/*:Body/*[1])] ] satisfies some $dopmsg in
/wsil:testLog/wsil:descriptionFiles/wsil:descriptionFile/wsdl:definitions/wsdl:portType/wsdl:operation/wsdl:input
[fn:local-name-from-QName(fn:resolve-QName(xsd:string(@message), .
)) = $dmesg/@name] satisfies
][1]$opBinding/@name = $dopmsg/../@name |
Predicate: |
(some $req2 in /wsil:testLog/wsil:messageLog/wsil:message[@type = 'request' and @conversation = $target/@conversation] satisfies (
$req2/wsil:messageContents/*:Envelope/*:Body/wsmc:MakeConnection/wsmc:Address
=
$myRequestMsg/wsil:messageContents/*:Envelope/*:Header/wsa:ReplyTo/wsa:Address
)
)) |
Reporting: | true=passed, false=failed |
Prescription: | mandatory |
Error Message: | A response message that binds to an doc-literal WSDL request-response binding, and relates to a request message sent over HTTP request, is not sent over same HTTP connection (response), and is not sent on an HTTP response to a MakeConnection request with same MC URI in wsmc:Address. |
Diagnostic Data: |
|
Test Assertion Part | What it means: |
---|---|
Test Assertion ID: |
[markup: testAssertion/@id] (required) A unique ID for the current test assertion. |
Description: |
[markup: testAssertion/description ] (optional) A plain text description of the current test assertion. At minimum expressing the TA predicate. |
Comments: |
[markup: testAssertion/comments ] (optional) A plain text comment about the TA script and how well it covers the profile requirement. Explanation material for users, and developers (what could be improved, etc.). |
Target: |
[markup: testAssertion/target ] (required) The artifacts to be tested, defined by an XPath expression that returns a list of XML nodes from the log file in input. For every artifact (node) selected by the Target expression, there will be a report entry for this TA in the test report, with a result of either:
See the "reporting" item for the meaning of these results. |
Cotarget: |
[markup: testAssertion/cotarget ] (optional) Artifact that is related to the target, and that needs be accessed for the testing. Identified by an XPath expression that may refer to the related target node using the variable '$target'. For example, the target can be a SOAP message and the cotarget the WSDL file that describes this SOAP message. A cotarget must have a @name attribute that identifies it. The value of this attribute can be used as a variable (when prepending '$' to it) by subsequently defined cotargets, prerequisite and predicate. |
Prerequisite: |
[markup: testAssertion/@preReq ] (optional) [markup: testAssertion/prerequisite ] (optional) The pre-condition for evaluating this Test Assertion on this target. If the prerequisite evaluates to "false" then the target does not qualify for this Test Assertion (the test report is "notRelevant") The first part (preReq attribute) is an enumeration of Test Assertion IDs. Each one of the prerequisite TAs must either use the same target (e.g. SOAP Envelope, or WSDL binding, etc.) as this TA, or a target that is of a more general type than the main TA target. The target must "pass" each one of these prerequisite TAs in order to qualify for this TA. (e.g. the target of TA t1 can be a WSDL binding while the target of a TA t2 prerequisite of t1, can be the entire WSDL file). The second part ("prerequisite" element) is an XPath (boolean) expression of the same nature as the predicate. If present, it must evaluate to "true" for the target to qualify. If it fails, the result for the current TA in the report will be "notRelevant". Otherwise, the target can be further evaluated by the predicate of the main TA. The expression may refer to the target explicitly using the variable name "$target", or to any cotarget using its name as variable name ($[name]). |
Predicate: |
[markup: testAssertion/predicate] required element] A logical expression that evaluates whether this target is fulfilling the profile requirement addressed by this test Assertion. By default: - A result of true means the requirement is fulfilled (reported as a "passed" in the test report).- A result of false means the requirement is violated (reported as a "failed" in the test report). However, in some cases and for testability reasons, the predicate may be designed as a partial indicator e.g. only indicates some cases of fulfillment, or some cases of violation. As a result, when "true" indicates fulfillment it may be that "false" is unconclusive, or conversely "false" will indicate violation, but "true" is unconclusive. In such cases, the "Reporting" element specifies the meaning of the predicate result w/r to the profile requirement. The predicate expression implicitly refers to the target (whic is its "XPath context") although it may explicitly refer to it using the variable name "$target". It may refer to any cotarget using its name as variable name ($[name]). |
Prescription: |
[markup: testAssertion/prescription/@level ] (required) Conveys the level of prescription associated with the profile requirement. At least three values may be used:
|
Reporting: |
[markup: testAssertion/reporting ] (optional) For each possible outcome of the predicate (true or false), specifies how it must be interpreted w/r to the profile feature. Two attributes are used that both must be present, when this element is present:
NOTES: the predicate of the TA may be worded in a negative way so that @false='passed' although that is not recommended. The result of a test should not be related to the prescription level, e.g. a "preferred" or "permitted" level should not imply that @false='warning'. Other test results that are automatically generated and not controlled by the "reporting" element are:
|
R2005 Any MESSAGE resulting from the processing of a SOAP envelope included in the HTTP entity body of the HTTP response, if transmitted, MUST be sent via a new HTTP request.TESTABLE RSP2005
Test Assertion Analysis: | RSP2005 |
---|---|
General Notes: | |
Coverage Assessment: | good |
Target Type: | ENVELOPE |
Test Target: | for a soap:Envelope sent as a response (wsa:RelatesTo) to another Envelope sent over an HTTP response |
Test co-Target(s): | |
Test Prerequisite: | |
Predicate: | The target Envelope is sent over an HTTP Request |
Prescription: | mandatory |
Reporting: | true=passed, false=failed |
Test Control: |
Test Assertion: | RSP2005 |
---|---|
Description: | |
Target: |
some $reqm in /wsil:testLog/wsil:messageLog/wsil:message/wsil:messageContents/*:Envelope satisfies $reqm/*:Header/wsa:MessageID = ./*:Header/wsa:RelatesTo[@RelationshipType = 'http://www.w3.org/2005/08/addressing/reply' or not (@RelationshipType)] and $reqm/../../@type = 'response' ] |
Predicate: |
|
Reporting: | true=passed, false=failed |
Prescription: | mandatory |
Error Message: | A soap:Envelope is sent as a response (wsa:RelatesTo) to another Envelope sent over an HTTP response. Such an envelope was not sent over an HTTP Request. |
Diagnostic Data: |
|
Test Assertion Part | What it means: |
---|---|
Test Assertion ID: |
[markup: testAssertion/@id] (required) A unique ID for the current test assertion. |
Description: |
[markup: testAssertion/description ] (optional) A plain text description of the current test assertion. At minimum expressing the TA predicate. |
Comments: |
[markup: testAssertion/comments ] (optional) A plain text comment about the TA script and how well it covers the profile requirement. Explanation material for users, and developers (what could be improved, etc.). |
Target: |
[markup: testAssertion/target ] (required) The artifacts to be tested, defined by an XPath expression that returns a list of XML nodes from the log file in input. For every artifact (node) selected by the Target expression, there will be a report entry for this TA in the test report, with a result of either:
See the "reporting" item for the meaning of these results. |
Cotarget: |
[markup: testAssertion/cotarget ] (optional) Artifact that is related to the target, and that needs be accessed for the testing. Identified by an XPath expression that may refer to the related target node using the variable '$target'. For example, the target can be a SOAP message and the cotarget the WSDL file that describes this SOAP message. A cotarget must have a @name attribute that identifies it. The value of this attribute can be used as a variable (when prepending '$' to it) by subsequently defined cotargets, prerequisite and predicate. |
Prerequisite: |
[markup: testAssertion/@preReq ] (optional) [markup: testAssertion/prerequisite ] (optional) The pre-condition for evaluating this Test Assertion on this target. If the prerequisite evaluates to "false" then the target does not qualify for this Test Assertion (the test report is "notRelevant") The first part (preReq attribute) is an enumeration of Test Assertion IDs. Each one of the prerequisite TAs must either use the same target (e.g. SOAP Envelope, or WSDL binding, etc.) as this TA, or a target that is of a more general type than the main TA target. The target must "pass" each one of these prerequisite TAs in order to qualify for this TA. (e.g. the target of TA t1 can be a WSDL binding while the target of a TA t2 prerequisite of t1, can be the entire WSDL file). The second part ("prerequisite" element) is an XPath (boolean) expression of the same nature as the predicate. If present, it must evaluate to "true" for the target to qualify. If it fails, the result for the current TA in the report will be "notRelevant". Otherwise, the target can be further evaluated by the predicate of the main TA. The expression may refer to the target explicitly using the variable name "$target", or to any cotarget using its name as variable name ($[name]). |
Predicate: |
[markup: testAssertion/predicate] required element] A logical expression that evaluates whether this target is fulfilling the profile requirement addressed by this test Assertion. By default: - A result of true means the requirement is fulfilled (reported as a "passed" in the test report).- A result of false means the requirement is violated (reported as a "failed" in the test report). However, in some cases and for testability reasons, the predicate may be designed as a partial indicator e.g. only indicates some cases of fulfillment, or some cases of violation. As a result, when "true" indicates fulfillment it may be that "false" is unconclusive, or conversely "false" will indicate violation, but "true" is unconclusive. In such cases, the "Reporting" element specifies the meaning of the predicate result w/r to the profile requirement. The predicate expression implicitly refers to the target (whic is its "XPath context") although it may explicitly refer to it using the variable name "$target". It may refer to any cotarget using its name as variable name ($[name]). |
Prescription: |
[markup: testAssertion/prescription/@level ] (required) Conveys the level of prescription associated with the profile requirement. At least three values may be used:
|
Reporting: |
[markup: testAssertion/reporting ] (optional) For each possible outcome of the predicate (true or false), specifies how it must be interpreted w/r to the profile feature. Two attributes are used that both must be present, when this element is present:
NOTES: the predicate of the TA may be worded in a negative way so that @false='passed' although that is not recommended. The result of a test should not be related to the prescription level, e.g. a "preferred" or "permitted" level should not imply that @false='warning'. Other test results that are automatically generated and not controlled by the "reporting" element are:
|
Section 3.2 of the WS-MakeConnection specification states that there is no reply to the MakeConnection message and therefore section 3.4 ("Formulating a Reply Message") of the WS-Addressing specification is not used. This requires some clarification with respect to Fault processing. The MakeConnection message is, by definition, a one-way message. Therefore, if during the processing of the MakeConnection message a Fault is generated that is related to the processing of MakeConnection message itself, that Fault message is to be treated like any other Fault related to a one-way message; that is, if the Fault message is transmitted then it will follow the rules defined by section 3.4 of the WS-Addressing specification. Note that this is different from the use of the MakeConnection protocol to transmit a Fault message - those messages are not replies to the MakeConnection message and section 3.4 would not apply.
R2050 If, when processing a MakeConnection message, an MC-RECEIVER generates a fault related to the MakeConnection message (e.g. a wsmc:UnsupportedSelection or a wsmc:MissingSelection Fault) the transmission of that Fault MUST adhere to the rules as defined by section 3.4 of the WS-Addressing specification.TESTABLE RSP2050
Test Assertion Analysis: | RSP2050 |
---|---|
General Notes: | . |
Coverage Assessment: | Good |
Target Type: | ENVELOPE |
Test Target: | A SOAP Envelope in which any of the following appear: a. wsmc:UnsupportedSelection b. wsmc:MissingSelection |
Test co-Target(s): | |
Test Prerequisite: | |
Predicate: | The [target] has a wsa:RelatesTo that points to an MC with wsa:MessageId, AND the wsa:To matches the wsa:FaultTo (or wsa:ReplyTo if no faultTo). |
Prescription: | mandatory |
Reporting: | true=passed, false=failed |
Test Control: |
Test Assertion: | RSP2050 |
---|---|
Description: | |
Target: |
[*:Body/*:Fault//*:Value[ (: fn:namespace-uri-for-prefix(fn:substring-before(string(node()),':' ) , . ) = 'http://docs.oasis-open.org/ws-rx/wsmc/200702' and :) (fn:contains(string(node()), 'MissingSelection') or fn:contains(string(node()), 'UnsupportedSelection'))] or *:Body/*:Fault//*:faultcode[ (: fn:namespace-uri-for-prefix(fn:substring-before(string(node()),':' ) , . ) = 'http://docs.oasis-open.org/ws-rx/wsmc/200702' and :) (fn:contains(string(node()), 'MissingSelection') or fn:contains(string(node()), 'UnsupportedSelection'))] ] |
Predicate: |
( not($target/*:Header/wsa:To) or ($target/*:Header/wsa:To = $mc/*:Header/wsa:FaultTo/wsa:Address or (not($mc/*:Header/wsa:FaultTo) and ($target/*:Header/wsa:To = $mc/*:Header/wsa:ReplyTo/wsa:Address or (not($mc/*:Header/wsa:ReplyTo) and fn:contains($target/*:Header/wsa:To, 'http://www.w3.org/2005/08/addressing/anonymous') ) )))) :) ) or (not($mc/*:Header/wsa:MessageID) and $mc/../../@conversation = $target/../../@conversation and (not($target/*:Header/wsa:To) or fn:contains($target/*:Header/wsa:To, 'http://www.w3.org/2005/08/addressing/anonymous')) ) |
Reporting: | true=passed, false=failed |
Prescription: | mandatory |
Error Message: | A wsmc:UnsupportedSelection or wsmc:MissingSelection Fault either does not relate to a MakeConnection message or has a wsa:To content that does not match the wsa:FaultTo or wsa:ReplyTo in the MC message if no FaultTo. |
Diagnostic Data: |
|
Test Assertion Part | What it means: |
---|---|
Test Assertion ID: |
[markup: testAssertion/@id] (required) A unique ID for the current test assertion. |
Description: |
[markup: testAssertion/description ] (optional) A plain text description of the current test assertion. At minimum expressing the TA predicate. |
Comments: |
[markup: testAssertion/comments ] (optional) A plain text comment about the TA script and how well it covers the profile requirement. Explanation material for users, and developers (what could be improved, etc.). |
Target: |
[markup: testAssertion/target ] (required) The artifacts to be tested, defined by an XPath expression that returns a list of XML nodes from the log file in input. For every artifact (node) selected by the Target expression, there will be a report entry for this TA in the test report, with a result of either:
See the "reporting" item for the meaning of these results. |
Cotarget: |
[markup: testAssertion/cotarget ] (optional) Artifact that is related to the target, and that needs be accessed for the testing. Identified by an XPath expression that may refer to the related target node using the variable '$target'. For example, the target can be a SOAP message and the cotarget the WSDL file that describes this SOAP message. A cotarget must have a @name attribute that identifies it. The value of this attribute can be used as a variable (when prepending '$' to it) by subsequently defined cotargets, prerequisite and predicate. |
Prerequisite: |
[markup: testAssertion/@preReq ] (optional) [markup: testAssertion/prerequisite ] (optional) The pre-condition for evaluating this Test Assertion on this target. If the prerequisite evaluates to "false" then the target does not qualify for this Test Assertion (the test report is "notRelevant") The first part (preReq attribute) is an enumeration of Test Assertion IDs. Each one of the prerequisite TAs must either use the same target (e.g. SOAP Envelope, or WSDL binding, etc.) as this TA, or a target that is of a more general type than the main TA target. The target must "pass" each one of these prerequisite TAs in order to qualify for this TA. (e.g. the target of TA t1 can be a WSDL binding while the target of a TA t2 prerequisite of t1, can be the entire WSDL file). The second part ("prerequisite" element) is an XPath (boolean) expression of the same nature as the predicate. If present, it must evaluate to "true" for the target to qualify. If it fails, the result for the current TA in the report will be "notRelevant". Otherwise, the target can be further evaluated by the predicate of the main TA. The expression may refer to the target explicitly using the variable name "$target", or to any cotarget using its name as variable name ($[name]). |
Predicate: |
[markup: testAssertion/predicate] required element] A logical expression that evaluates whether this target is fulfilling the profile requirement addressed by this test Assertion. By default: - A result of true means the requirement is fulfilled (reported as a "passed" in the test report).- A result of false means the requirement is violated (reported as a "failed" in the test report). However, in some cases and for testability reasons, the predicate may be designed as a partial indicator e.g. only indicates some cases of fulfillment, or some cases of violation. As a result, when "true" indicates fulfillment it may be that "false" is unconclusive, or conversely "false" will indicate violation, but "true" is unconclusive. In such cases, the "Reporting" element specifies the meaning of the predicate result w/r to the profile requirement. The predicate expression implicitly refers to the target (whic is its "XPath context") although it may explicitly refer to it using the variable name "$target". It may refer to any cotarget using its name as variable name ($[name]). |
Prescription: |
[markup: testAssertion/prescription/@level ] (required) Conveys the level of prescription associated with the profile requirement. At least three values may be used:
|
Reporting: |
[markup: testAssertion/reporting ] (optional) For each possible outcome of the predicate (true or false), specifies how it must be interpreted w/r to the profile feature. Two attributes are used that both must be present, when this element is present:
NOTES: the predicate of the TA may be worded in a negative way so that @false='passed' although that is not recommended. The result of a test should not be related to the prescription level, e.g. a "preferred" or "permitted" level should not imply that @false='warning'. Other test results that are automatically generated and not controlled by the "reporting" element are:
|
In section 3.1 of the WS-MakeConnection specification the WS-MC Anonymous URI is defined to uniquely identity anonymous endpoints and to signal the intention to use the MakeConnection protocol to transfer messages between the endpoints. The WS-MakeConnection protocol uses the receipt of the MakeConnection message at an endpoint as the mechanism by which the back-channel of that connection can be uniquely identified. Once identified, the MC Receiver is then free to use that back-channel to send any pending message targeted to the URI specified within the MakeConnection message.
The WS-MakeConnection specification defines two distinct ways for the MC-Sender to indicate its messages of interest. One of these mechanisms uses the wsmc:MakeConnection Anonymous URI, the other uses a WS-RM Sequence ID. However, the WS-MakeConnection specification doesn't define any way of advertising or agreeing upon which variant of the MakeConnection protocol is supported or required by an endpoint. This creates the potential for different, incompatible implementations of WS-MakeConnection. To promote interoperability this Profile refines the WS-MakeConnection specification with additional requirements to mandate the use of a single, consistent addressing variant. Since the URI variant of WS-MakeConnection is a superset of the functionality of the Sequence-ID variant, use of the URI variant is mandated by this Profile.
R2100 If an ENVELOPE contains a wsmc:MakeConnection element as a child of the SOAP Body, the wsmc:MakeConnection element MUST contain a wsmc:Address child element.TESTABLE RSP2100
Test Assertion Analysis: | RSP2100 |
---|---|
General Notes: | There's an option in the MC spec that allows for the retrieval of messages based on things other than the target URI – however, RSP limits this by requiring that a search MUST, at least, be based on the target URI (ie. the wsa:To URI). |
Coverage Assessment: | Good |
Target Type: | ENVELOPE |
Test Target: | For an Envelope with s:Body/MC |
Test co-Target(s): | |
Test Prerequisite: | |
Predicate: | there exists MC/wsmc:Address child element |
Prescription: | mandatory |
Reporting: | (default) |
Test Control: | provide context and cause MC sending such as do a req/resp and the response is lost. Flag=much more difficult study required to force use of MC. Run some request/response tests and set the wsa:ReplyTo of the request messages (from a non-addressable endpoint) to an instance of the MC Anonymous URI Template |
Test Assertion: | RSP2100 |
---|---|
Description: | |
Target: |
|
Predicate: |
|
Reporting: | true=passed, false=failed |
Prescription: | mandatory |
Error Message: | The MakeConenction element does not contain a wsmc:Address child element. |
Diagnostic Data: |
|
Test Assertion Part | What it means: |
---|---|
Test Assertion ID: |
[markup: testAssertion/@id] (required) A unique ID for the current test assertion. |
Description: |
[markup: testAssertion/description ] (optional) A plain text description of the current test assertion. At minimum expressing the TA predicate. |
Comments: |
[markup: testAssertion/comments ] (optional) A plain text comment about the TA script and how well it covers the profile requirement. Explanation material for users, and developers (what could be improved, etc.). |
Target: |
[markup: testAssertion/target ] (required) The artifacts to be tested, defined by an XPath expression that returns a list of XML nodes from the log file in input. For every artifact (node) selected by the Target expression, there will be a report entry for this TA in the test report, with a result of either:
See the "reporting" item for the meaning of these results. |
Cotarget: |
[markup: testAssertion/cotarget ] (optional) Artifact that is related to the target, and that needs be accessed for the testing. Identified by an XPath expression that may refer to the related target node using the variable '$target'. For example, the target can be a SOAP message and the cotarget the WSDL file that describes this SOAP message. A cotarget must have a @name attribute that identifies it. The value of this attribute can be used as a variable (when prepending '$' to it) by subsequently defined cotargets, prerequisite and predicate. |
Prerequisite: |
[markup: testAssertion/@preReq ] (optional) [markup: testAssertion/prerequisite ] (optional) The pre-condition for evaluating this Test Assertion on this target. If the prerequisite evaluates to "false" then the target does not qualify for this Test Assertion (the test report is "notRelevant") The first part (preReq attribute) is an enumeration of Test Assertion IDs. Each one of the prerequisite TAs must either use the same target (e.g. SOAP Envelope, or WSDL binding, etc.) as this TA, or a target that is of a more general type than the main TA target. The target must "pass" each one of these prerequisite TAs in order to qualify for this TA. (e.g. the target of TA t1 can be a WSDL binding while the target of a TA t2 prerequisite of t1, can be the entire WSDL file). The second part ("prerequisite" element) is an XPath (boolean) expression of the same nature as the predicate. If present, it must evaluate to "true" for the target to qualify. If it fails, the result for the current TA in the report will be "notRelevant". Otherwise, the target can be further evaluated by the predicate of the main TA. The expression may refer to the target explicitly using the variable name "$target", or to any cotarget using its name as variable name ($[name]). |
Predicate: |
[markup: testAssertion/predicate] required element] A logical expression that evaluates whether this target is fulfilling the profile requirement addressed by this test Assertion. By default: - A result of true means the requirement is fulfilled (reported as a "passed" in the test report).- A result of false means the requirement is violated (reported as a "failed" in the test report). However, in some cases and for testability reasons, the predicate may be designed as a partial indicator e.g. only indicates some cases of fulfillment, or some cases of violation. As a result, when "true" indicates fulfillment it may be that "false" is unconclusive, or conversely "false" will indicate violation, but "true" is unconclusive. In such cases, the "Reporting" element specifies the meaning of the predicate result w/r to the profile requirement. The predicate expression implicitly refers to the target (whic is its "XPath context") although it may explicitly refer to it using the variable name "$target". It may refer to any cotarget using its name as variable name ($[name]). |
Prescription: |
[markup: testAssertion/prescription/@level ] (required) Conveys the level of prescription associated with the profile requirement. At least three values may be used:
|
Reporting: |
[markup: testAssertion/reporting ] (optional) For each possible outcome of the predicate (true or false), specifies how it must be interpreted w/r to the profile feature. Two attributes are used that both must be present, when this element is present:
NOTES: the predicate of the TA may be worded in a negative way so that @false='passed' although that is not recommended. The result of a test should not be related to the prescription level, e.g. a "preferred" or "permitted" level should not imply that @false='warning'. Other test results that are automatically generated and not controlled by the "reporting" element are:
|
R2101 If an ENVELOPE contains a wsmc:MakeConnection element as a child of the SOAP Body, the wsmc:MakeConnection element MUST NOT contain a wsrm:Identifier child element.TESTABLE RSP2101
Test Assertion Analysis: | RSP2101 |
---|---|
General Notes: | |
Coverage Assessment: | Good |
Target Type: | ENVELOPE |
Test Target: | For an Envelope with s:Body/MC |
Test co-Target(s): | |
Test Prerequisite: | |
Predicate: | there is no MC/wsrm:Identifier |
Prescription: | mandatory |
Reporting: | (default) |
Test Control: | provide context and cause MC sending such as do a req/resp and the response is lost. Flag=much more difficult study required to force use of MC. Run some request/response tests and set the wsa:ReplyTo of the request messages (from a non-addressable endpoint) to an instance of the MC Anonymous URI Template |
Test Assertion: | RSP2101 |
---|---|
Description: | |
Target: |
|
Predicate: |
|
Reporting: | true=passed, false=failed |
Prescription: | mandatory |
Error Message: | |
Diagnostic Data: |
|
Test Assertion Part | What it means: |
---|---|
Test Assertion ID: |
[markup: testAssertion/@id] (required) A unique ID for the current test assertion. |
Description: |
[markup: testAssertion/description ] (optional) A plain text description of the current test assertion. At minimum expressing the TA predicate. |
Comments: |
[markup: testAssertion/comments ] (optional) A plain text comment about the TA script and how well it covers the profile requirement. Explanation material for users, and developers (what could be improved, etc.). |
Target: |
[markup: testAssertion/target ] (required) The artifacts to be tested, defined by an XPath expression that returns a list of XML nodes from the log file in input. For every artifact (node) selected by the Target expression, there will be a report entry for this TA in the test report, with a result of either:
See the "reporting" item for the meaning of these results. |
Cotarget: |
[markup: testAssertion/cotarget ] (optional) Artifact that is related to the target, and that needs be accessed for the testing. Identified by an XPath expression that may refer to the related target node using the variable '$target'. For example, the target can be a SOAP message and the cotarget the WSDL file that describes this SOAP message. A cotarget must have a @name attribute that identifies it. The value of this attribute can be used as a variable (when prepending '$' to it) by subsequently defined cotargets, prerequisite and predicate. |
Prerequisite: |
[markup: testAssertion/@preReq ] (optional) [markup: testAssertion/prerequisite ] (optional) The pre-condition for evaluating this Test Assertion on this target. If the prerequisite evaluates to "false" then the target does not qualify for this Test Assertion (the test report is "notRelevant") The first part (preReq attribute) is an enumeration of Test Assertion IDs. Each one of the prerequisite TAs must either use the same target (e.g. SOAP Envelope, or WSDL binding, etc.) as this TA, or a target that is of a more general type than the main TA target. The target must "pass" each one of these prerequisite TAs in order to qualify for this TA. (e.g. the target of TA t1 can be a WSDL binding while the target of a TA t2 prerequisite of t1, can be the entire WSDL file). The second part ("prerequisite" element) is an XPath (boolean) expression of the same nature as the predicate. If present, it must evaluate to "true" for the target to qualify. If it fails, the result for the current TA in the report will be "notRelevant". Otherwise, the target can be further evaluated by the predicate of the main TA. The expression may refer to the target explicitly using the variable name "$target", or to any cotarget using its name as variable name ($[name]). |
Predicate: |
[markup: testAssertion/predicate] required element] A logical expression that evaluates whether this target is fulfilling the profile requirement addressed by this test Assertion. By default: - A result of true means the requirement is fulfilled (reported as a "passed" in the test report).- A result of false means the requirement is violated (reported as a "failed" in the test report). However, in some cases and for testability reasons, the predicate may be designed as a partial indicator e.g. only indicates some cases of fulfillment, or some cases of violation. As a result, when "true" indicates fulfillment it may be that "false" is unconclusive, or conversely "false" will indicate violation, but "true" is unconclusive. In such cases, the "Reporting" element specifies the meaning of the predicate result w/r to the profile requirement. The predicate expression implicitly refers to the target (whic is its "XPath context") although it may explicitly refer to it using the variable name "$target". It may refer to any cotarget using its name as variable name ($[name]). |
Prescription: |
[markup: testAssertion/prescription/@level ] (required) Conveys the level of prescription associated with the profile requirement. At least three values may be used:
|
Reporting: |
[markup: testAssertion/reporting ] (optional) For each possible outcome of the predicate (true or false), specifies how it must be interpreted w/r to the profile feature. Two attributes are used that both must be present, when this element is present:
NOTES: the predicate of the TA may be worded in a negative way so that @false='passed' although that is not recommended. The result of a test should not be related to the prescription level, e.g. a "preferred" or "permitted" level should not imply that @false='warning'. Other test results that are automatically generated and not controlled by the "reporting" element are:
|
R2102 If a wsmc:MakeConnection request does not contain a wsmc:Address child element (in violation of R2100), the MC-RECEIVER MUST generate a wsmc:MissingSelection fault.TESTABLE RSP2102
Test Assertion Analysis: | RSP2102 |
---|---|
General Notes: | Counterpart of RSP2100 (in case of violation) |
Coverage Assessment: | Good |
Target Type: | ENVELOPE |
Test Target: | For an Envelope with s:Body/MC and no wsmc:Address |
Test co-Target(s): | |
Test Prerequisite: | |
Predicate: | there exists a Fault generated in response |
Prescription: | mandatory |
Reporting: | (default) |
Test Control: |
Test Assertion: | RSP2102 |
---|---|
Description: | |
Target: |
|
Predicate: |
*:Body/*:Fault//*:faultcode[ (: fn:namespace-uri-for-prefix(fn:substring-before(string(node()),':' ) , . ) = 'http://docs.oasis-open.org/ws-rx/wsmc/200702' and :) fn:contains(string(node()), 'MissingSelection')] ] satisfies ($target/*:Header/wsa:MessageID = $mcfault/*:Header/wsa:RelatesTo[@RelationshipType = 'http://www.w3.org/2005/08/addressing/reply' or not (@RelationshipType)] or (not($target/*:Header/wsa:MessageID) and $mcfault/../../@conversation = $target/../../@conversation)) |
Reporting: | true=passed, false=failed |
Prescription: | mandatory |
Error Message: | A MakeConnection message without wsmc:Address did not cause the generation of a wsmc:MissingSelection Fault associated with this MC message. |
Diagnostic Data: |
|
Test Assertion Part | What it means: |
---|---|
Test Assertion ID: |
[markup: testAssertion/@id] (required) A unique ID for the current test assertion. |
Description: |
[markup: testAssertion/description ] (optional) A plain text description of the current test assertion. At minimum expressing the TA predicate. |
Comments: |
[markup: testAssertion/comments ] (optional) A plain text comment about the TA script and how well it covers the profile requirement. Explanation material for users, and developers (what could be improved, etc.). |
Target: |
[markup: testAssertion/target ] (required) The artifacts to be tested, defined by an XPath expression that returns a list of XML nodes from the log file in input. For every artifact (node) selected by the Target expression, there will be a report entry for this TA in the test report, with a result of either:
See the "reporting" item for the meaning of these results. |
Cotarget: |
[markup: testAssertion/cotarget ] (optional) Artifact that is related to the target, and that needs be accessed for the testing. Identified by an XPath expression that may refer to the related target node using the variable '$target'. For example, the target can be a SOAP message and the cotarget the WSDL file that describes this SOAP message. A cotarget must have a @name attribute that identifies it. The value of this attribute can be used as a variable (when prepending '$' to it) by subsequently defined cotargets, prerequisite and predicate. |
Prerequisite: |
[markup: testAssertion/@preReq ] (optional) [markup: testAssertion/prerequisite ] (optional) The pre-condition for evaluating this Test Assertion on this target. If the prerequisite evaluates to "false" then the target does not qualify for this Test Assertion (the test report is "notRelevant") The first part (preReq attribute) is an enumeration of Test Assertion IDs. Each one of the prerequisite TAs must either use the same target (e.g. SOAP Envelope, or WSDL binding, etc.) as this TA, or a target that is of a more general type than the main TA target. The target must "pass" each one of these prerequisite TAs in order to qualify for this TA. (e.g. the target of TA t1 can be a WSDL binding while the target of a TA t2 prerequisite of t1, can be the entire WSDL file). The second part ("prerequisite" element) is an XPath (boolean) expression of the same nature as the predicate. If present, it must evaluate to "true" for the target to qualify. If it fails, the result for the current TA in the report will be "notRelevant". Otherwise, the target can be further evaluated by the predicate of the main TA. The expression may refer to the target explicitly using the variable name "$target", or to any cotarget using its name as variable name ($[name]). |
Predicate: |
[markup: testAssertion/predicate] required element] A logical expression that evaluates whether this target is fulfilling the profile requirement addressed by this test Assertion. By default: - A result of true means the requirement is fulfilled (reported as a "passed" in the test report).- A result of false means the requirement is violated (reported as a "failed" in the test report). However, in some cases and for testability reasons, the predicate may be designed as a partial indicator e.g. only indicates some cases of fulfillment, or some cases of violation. As a result, when "true" indicates fulfillment it may be that "false" is unconclusive, or conversely "false" will indicate violation, but "true" is unconclusive. In such cases, the "Reporting" element specifies the meaning of the predicate result w/r to the profile requirement. The predicate expression implicitly refers to the target (whic is its "XPath context") although it may explicitly refer to it using the variable name "$target". It may refer to any cotarget using its name as variable name ($[name]). |
Prescription: |
[markup: testAssertion/prescription/@level ] (required) Conveys the level of prescription associated with the profile requirement. At least three values may be used:
|
Reporting: |
[markup: testAssertion/reporting ] (optional) For each possible outcome of the predicate (true or false), specifies how it must be interpreted w/r to the profile feature. Two attributes are used that both must be present, when this element is present:
NOTES: the predicate of the TA may be worded in a negative way so that @false='passed' although that is not recommended. The result of a test should not be related to the prescription level, e.g. a "preferred" or "permitted" level should not imply that @false='warning'. Other test results that are automatically generated and not controlled by the "reporting" element are:
|
R2103 If a wsmc:MakeConnection request contains a wsrm:Identifier element (in violation of R2101) the MC-RECEIVER MUST generate a wsmc:UnsupportedSelection fault.TESTABLE RSP2103
Test Assertion Analysis: | RSP2103 |
---|---|
General Notes: | Counterpart of RSP2101 (in case of violation) |
Coverage Assessment: | Good |
Target Type: | ENVELOPE |
Test Target: | For an Envelope with s:Body/MC and with wsrm:Identifier |
Test co-Target(s): | |
Test Prerequisite: | |
Predicate: | there exists a Fault generated in response |
Prescription: | mandatory |
Reporting: | (default) |
Test Control: |
Test Assertion: | RSP2103 |
---|---|
Description: | |
Target: |
|
Predicate: |
*:Body/*:Fault//*:faultcode[ (: fn:namespace-uri-for-prefix(fn:substring-before(string(node()),':' ) , . ) = 'http://docs.oasis-open.org/ws-rx/wsmc/200702' and :) fn:contains(string(node()), 'UnsupportedSelection')] ] satisfies ($target/*:Header/wsa:MessageID = $mcfault/*:Header/wsa:RelatesTo[@RelationshipType = 'http://www.w3.org/2005/08/addressing/reply' or not (@RelationshipType)] or (not($target/*:Header/wsa:MessageID) and $mcfault/../../@conversation = $target/../../@conversation)) |
Reporting: | true=passed, false=failed |
Prescription: | mandatory |
Error Message: | A MakeConnection message with an wsrm:Identifier did not cause the generation of a wsmc:UnsupportedSelection Fault associated with this MC message. |
Diagnostic Data: |
|
Test Assertion Part | What it means: |
---|---|
Test Assertion ID: |
[markup: testAssertion/@id] (required) A unique ID for the current test assertion. |
Description: |
[markup: testAssertion/description ] (optional) A plain text description of the current test assertion. At minimum expressing the TA predicate. |
Comments: |
[markup: testAssertion/comments ] (optional) A plain text comment about the TA script and how well it covers the profile requirement. Explanation material for users, and developers (what could be improved, etc.). |
Target: |
[markup: testAssertion/target ] (required) The artifacts to be tested, defined by an XPath expression that returns a list of XML nodes from the log file in input. For every artifact (node) selected by the Target expression, there will be a report entry for this TA in the test report, with a result of either:
See the "reporting" item for the meaning of these results. |
Cotarget: |
[markup: testAssertion/cotarget ] (optional) Artifact that is related to the target, and that needs be accessed for the testing. Identified by an XPath expression that may refer to the related target node using the variable '$target'. For example, the target can be a SOAP message and the cotarget the WSDL file that describes this SOAP message. A cotarget must have a @name attribute that identifies it. The value of this attribute can be used as a variable (when prepending '$' to it) by subsequently defined cotargets, prerequisite and predicate. |
Prerequisite: |
[markup: testAssertion/@preReq ] (optional) [markup: testAssertion/prerequisite ] (optional) The pre-condition for evaluating this Test Assertion on this target. If the prerequisite evaluates to "false" then the target does not qualify for this Test Assertion (the test report is "notRelevant") The first part (preReq attribute) is an enumeration of Test Assertion IDs. Each one of the prerequisite TAs must either use the same target (e.g. SOAP Envelope, or WSDL binding, etc.) as this TA, or a target that is of a more general type than the main TA target. The target must "pass" each one of these prerequisite TAs in order to qualify for this TA. (e.g. the target of TA t1 can be a WSDL binding while the target of a TA t2 prerequisite of t1, can be the entire WSDL file). The second part ("prerequisite" element) is an XPath (boolean) expression of the same nature as the predicate. If present, it must evaluate to "true" for the target to qualify. If it fails, the result for the current TA in the report will be "notRelevant". Otherwise, the target can be further evaluated by the predicate of the main TA. The expression may refer to the target explicitly using the variable name "$target", or to any cotarget using its name as variable name ($[name]). |
Predicate: |
[markup: testAssertion/predicate] required element] A logical expression that evaluates whether this target is fulfilling the profile requirement addressed by this test Assertion. By default: - A result of true means the requirement is fulfilled (reported as a "passed" in the test report).- A result of false means the requirement is violated (reported as a "failed" in the test report). However, in some cases and for testability reasons, the predicate may be designed as a partial indicator e.g. only indicates some cases of fulfillment, or some cases of violation. As a result, when "true" indicates fulfillment it may be that "false" is unconclusive, or conversely "false" will indicate violation, but "true" is unconclusive. In such cases, the "Reporting" element specifies the meaning of the predicate result w/r to the profile requirement. The predicate expression implicitly refers to the target (whic is its "XPath context") although it may explicitly refer to it using the variable name "$target". It may refer to any cotarget using its name as variable name ($[name]). |
Prescription: |
[markup: testAssertion/prescription/@level ] (required) Conveys the level of prescription associated with the profile requirement. At least three values may be used:
|
Reporting: |
[markup: testAssertion/reporting ] (optional) For each possible outcome of the predicate (true or false), specifies how it must be interpreted w/r to the profile feature. Two attributes are used that both must be present, when this element is present:
NOTES: the predicate of the TA may be worded in a negative way so that @false='passed' although that is not recommended. The result of a test should not be related to the prescription level, e.g. a "preferred" or "permitted" level should not imply that @false='warning'. Other test results that are automatically generated and not controlled by the "reporting" element are:
|
The following requirements describe how the MakeConnection anonymous URI is used in the various addressing properties and within RM protocol elements transmitted on SOAP messages.
R2110 When present in a SOAP ENVELOPE, the /wsmc:MakeConnection/wsmc:Address element MUST be set to a MakeConnection anonymous URI that identifies the MC-SENDER.TESTABLE RSP2110
Test Assertion Analysis: | RSP2110 |
---|---|
General Notes: | While the MakeConnection specification allows for any URI to be used in the mc:Address element, for the purposes of increasing interoperability the RSP narrows its usage down to just the cases of the MCAnonymous URI |
Coverage Assessment: | Good (should be able to cover all cases) |
Target Type: | ENVELOPE |
Test Target: | Any message that contains a MakeConnection element in the Body |
Test co-Target(s): | |
Test Prerequisite: | |
Predicate: | The [target] contains an mc:MakeConnection/mc:Address child element whose value is an instance of the MC Anonymous URI template (ie. starts with 'http://docs.oasis-open.org/ws-rx/wsmc/200702/anonymous?id=' ). |
Prescription: | mandatory |
Reporting: | true=passed, false=failed |
Test Control: | Run some request/response tests and set the wsa:ReplyTo of the request messages (from a non-addressable endpoint) to an instance of the MC Anonymous URI Template. |
Test Assertion: | RSP2110 |
---|---|
Description: | |
Target: |
|
Predicate: |
|
Reporting: | true=passed, false=failed |
Prescription: | mandatory |
Error Message: | The Envelope contains an wsmc:MakeConnection/wsmc:Address child element whose value is not an instance of the MC Anonymous URI template (ie. does not start with 'http://docs.oasis-open.org/ws-rx/wsmc/200702/anonymous?id=' ) |
Diagnostic Data: |
|
Test Assertion Part | What it means: |
---|---|
Test Assertion ID: |
[markup: testAssertion/@id] (required) A unique ID for the current test assertion. |
Description: |
[markup: testAssertion/description ] (optional) A plain text description of the current test assertion. At minimum expressing the TA predicate. |
Comments: |
[markup: testAssertion/comments ] (optional) A plain text comment about the TA script and how well it covers the profile requirement. Explanation material for users, and developers (what could be improved, etc.). |
Target: |
[markup: testAssertion/target ] (required) The artifacts to be tested, defined by an XPath expression that returns a list of XML nodes from the log file in input. For every artifact (node) selected by the Target expression, there will be a report entry for this TA in the test report, with a result of either:
See the "reporting" item for the meaning of these results. |
Cotarget: |
[markup: testAssertion/cotarget ] (optional) Artifact that is related to the target, and that needs be accessed for the testing. Identified by an XPath expression that may refer to the related target node using the variable '$target'. For example, the target can be a SOAP message and the cotarget the WSDL file that describes this SOAP message. A cotarget must have a @name attribute that identifies it. The value of this attribute can be used as a variable (when prepending '$' to it) by subsequently defined cotargets, prerequisite and predicate. |
Prerequisite: |
[markup: testAssertion/@preReq ] (optional) [markup: testAssertion/prerequisite ] (optional) The pre-condition for evaluating this Test Assertion on this target. If the prerequisite evaluates to "false" then the target does not qualify for this Test Assertion (the test report is "notRelevant") The first part (preReq attribute) is an enumeration of Test Assertion IDs. Each one of the prerequisite TAs must either use the same target (e.g. SOAP Envelope, or WSDL binding, etc.) as this TA, or a target that is of a more general type than the main TA target. The target must "pass" each one of these prerequisite TAs in order to qualify for this TA. (e.g. the target of TA t1 can be a WSDL binding while the target of a TA t2 prerequisite of t1, can be the entire WSDL file). The second part ("prerequisite" element) is an XPath (boolean) expression of the same nature as the predicate. If present, it must evaluate to "true" for the target to qualify. If it fails, the result for the current TA in the report will be "notRelevant". Otherwise, the target can be further evaluated by the predicate of the main TA. The expression may refer to the target explicitly using the variable name "$target", or to any cotarget using its name as variable name ($[name]). |
Predicate: |
[markup: testAssertion/predicate] required element] A logical expression that evaluates whether this target is fulfilling the profile requirement addressed by this test Assertion. By default: - A result of true means the requirement is fulfilled (reported as a "passed" in the test report).- A result of false means the requirement is violated (reported as a "failed" in the test report). However, in some cases and for testability reasons, the predicate may be designed as a partial indicator e.g. only indicates some cases of fulfillment, or some cases of violation. As a result, when "true" indicates fulfillment it may be that "false" is unconclusive, or conversely "false" will indicate violation, but "true" is unconclusive. In such cases, the "Reporting" element specifies the meaning of the predicate result w/r to the profile requirement. The predicate expression implicitly refers to the target (whic is its "XPath context") although it may explicitly refer to it using the variable name "$target". It may refer to any cotarget using its name as variable name ($[name]). |
Prescription: |
[markup: testAssertion/prescription/@level ] (required) Conveys the level of prescription associated with the profile requirement. At least three values may be used:
|
Reporting: |
[markup: testAssertion/reporting ] (optional) For each possible outcome of the predicate (true or false), specifies how it must be interpreted w/r to the profile feature. Two attributes are used that both must be present, when this element is present:
NOTES: the predicate of the TA may be worded in a negative way so that @false='passed' although that is not recommended. The result of a test should not be related to the prescription level, e.g. a "preferred" or "permitted" level should not imply that @false='warning'. Other test results that are automatically generated and not controlled by the "reporting" element are:
|
R2111 Once the MakeConnection protocol is established through the exchange of an EPR that contains the wsmc:MakeConnection Anonymous URI as its [address] property, the MC-RECEIVER MUST make use of the MakeConnection response channel to transfer messages targeted to that EPR.TESTABLE RSP2111
Test Assertion Analysis: | RSP2111 |
---|---|
General Notes: | This is a test to make sure that messages targeted to the MakeConnection Anonymous URI flow over an HTTP response flow (as opposed to an HTTP request flow). |
Coverage Assessment: | Good (should be able to cover all cases) |
Target Type: | ENVELOPE |
Test Target: | A message with a wsa:To value set to an instance of the MC Anonymous URI template (ie. starts with "http://docs.oasis-open.org/ws-rx/wsmc/200702/anonymous?id=" ). |
Test co-Target(s): | |
Test Prerequisite: | |
Predicate: | The [target] is an HTTP response message. |
Prescription: | mandatory |
Reporting: | true=passed, false=failed |
Test Control: | Run some request/response tests and set the wsa:ReplyTo of the request messages (from a non-addressable endpoint) to an instance of the MC Anonymous URI Template. |
Test Assertion: | RSP2111 |
---|---|
Description: | |
Target: |
|
Predicate: |
|
Reporting: | true=passed, false=failed |
Prescription: | mandatory |
Error Message: | A message with a wsa:To value set to an instance of the MC Anonymous URI template (ie. starts with "http://docs.oasis-open.org/ws-rx/wsmc/200702/anonymous?id=" ) is not sent as an HTTP response. |
Diagnostic Data: |
|
Test Assertion Part | What it means: |
---|---|
Test Assertion ID: |
[markup: testAssertion/@id] (required) A unique ID for the current test assertion. |
Description: |
[markup: testAssertion/description ] (optional) A plain text description of the current test assertion. At minimum expressing the TA predicate. |
Comments: |
[markup: testAssertion/comments ] (optional) A plain text comment about the TA script and how well it covers the profile requirement. Explanation material for users, and developers (what could be improved, etc.). |
Target: |
[markup: testAssertion/target ] (required) The artifacts to be tested, defined by an XPath expression that returns a list of XML nodes from the log file in input. For every artifact (node) selected by the Target expression, there will be a report entry for this TA in the test report, with a result of either:
See the "reporting" item for the meaning of these results. |
Cotarget: |
[markup: testAssertion/cotarget ] (optional) Artifact that is related to the target, and that needs be accessed for the testing. Identified by an XPath expression that may refer to the related target node using the variable '$target'. For example, the target can be a SOAP message and the cotarget the WSDL file that describes this SOAP message. A cotarget must have a @name attribute that identifies it. The value of this attribute can be used as a variable (when prepending '$' to it) by subsequently defined cotargets, prerequisite and predicate. |
Prerequisite: |
[markup: testAssertion/@preReq ] (optional) [markup: testAssertion/prerequisite ] (optional) The pre-condition for evaluating this Test Assertion on this target. If the prerequisite evaluates to "false" then the target does not qualify for this Test Assertion (the test report is "notRelevant") The first part (preReq attribute) is an enumeration of Test Assertion IDs. Each one of the prerequisite TAs must either use the same target (e.g. SOAP Envelope, or WSDL binding, etc.) as this TA, or a target that is of a more general type than the main TA target. The target must "pass" each one of these prerequisite TAs in order to qualify for this TA. (e.g. the target of TA t1 can be a WSDL binding while the target of a TA t2 prerequisite of t1, can be the entire WSDL file). The second part ("prerequisite" element) is an XPath (boolean) expression of the same nature as the predicate. If present, it must evaluate to "true" for the target to qualify. If it fails, the result for the current TA in the report will be "notRelevant". Otherwise, the target can be further evaluated by the predicate of the main TA. The expression may refer to the target explicitly using the variable name "$target", or to any cotarget using its name as variable name ($[name]). |
Predicate: |
[markup: testAssertion/predicate] required element] A logical expression that evaluates whether this target is fulfilling the profile requirement addressed by this test Assertion. By default: - A result of true means the requirement is fulfilled (reported as a "passed" in the test report).- A result of false means the requirement is violated (reported as a "failed" in the test report). However, in some cases and for testability reasons, the predicate may be designed as a partial indicator e.g. only indicates some cases of fulfillment, or some cases of violation. As a result, when "true" indicates fulfillment it may be that "false" is unconclusive, or conversely "false" will indicate violation, but "true" is unconclusive. In such cases, the "Reporting" element specifies the meaning of the predicate result w/r to the profile requirement. The predicate expression implicitly refers to the target (whic is its "XPath context") although it may explicitly refer to it using the variable name "$target". It may refer to any cotarget using its name as variable name ($[name]). |
Prescription: |
[markup: testAssertion/prescription/@level ] (required) Conveys the level of prescription associated with the profile requirement. At least three values may be used:
|
Reporting: |
[markup: testAssertion/reporting ] (optional) For each possible outcome of the predicate (true or false), specifies how it must be interpreted w/r to the profile feature. Two attributes are used that both must be present, when this element is present:
NOTES: the predicate of the TA may be worded in a negative way so that @false='passed' although that is not recommended. The result of a test should not be related to the prescription level, e.g. a "preferred" or "permitted" level should not imply that @false='warning'. Other test results that are automatically generated and not controlled by the "reporting" element are:
|
R2112 A MESSAGE sent to a non-addressable endpoint MUST have the wsa:To addressing property set to an instance of the MakeConnection anonymous URI that identifies that endpoint, except in the following situation where this is [permitted but] not required (a) the message (that is not a WS-RM lifecycle message) is sent non-reliably over the back-channel of an underlying protocol connection initiated by the non-addressable endpoint.TESTABLE RSP2112
Test Assertion Analysis: | RSP2112 |
---|---|
General Notes: | This requirement focuses on ensuring that when RM is being used by an anonymous endpoint, that the MC Anonymous URI is used so that the full features of RM can still continue to be used. So: IF MC anon used in request, and same used i response/wsa:To then OK else Fail. IF MC anon not used in request, but regular anon, THEN fail. |
Coverage Assessment: | Good (should be able to cover all cases) |
Target Type: | ENVELOPE |
Test Target: | Any Message sent on an HTTP response flow that contains a wsrm:Sequence Header. |
Test co-Target(s): | |
Test Prerequisite: | |
Predicate: | The [target] has a wsa:To Header whose value is an instance of the MC Anonymous URI (ie. starts with "http://docs.oasis-open.org/ws-rx/wsmc/200702/anonymous?id="). |
Prescription: | mandatory |
Reporting: | true=passed, false=failed |
Test Control: | Run some request/response tests and set the wsa:ReplyTo of the request messages (from a non-addressable endpoint) to an instance of the MC Anonymous URI Template. |
Test Assertion: | RSP2112 |
---|---|
Description: | |
Target: |
|
Predicate: |
|
Reporting: | true=passed, false=failed |
Prescription: | mandatory |
Error Message: | A Message sent on an HTTP response contains a wsrm:Sequence Header, but the wsa:To Header is not an instance of the MC Anonymous URI (ie. does not start with 'http://docs.oasis-open.org/ws-rx/wsmc/200702/anonymous?id=') |
Diagnostic Data: |
|
Test Assertion Part | What it means: |
---|---|
Test Assertion ID: |
[markup: testAssertion/@id] (required) A unique ID for the current test assertion. |
Description: |
[markup: testAssertion/description ] (optional) A plain text description of the current test assertion. At minimum expressing the TA predicate. |
Comments: |
[markup: testAssertion/comments ] (optional) A plain text comment about the TA script and how well it covers the profile requirement. Explanation material for users, and developers (what could be improved, etc.). |
Target: |
[markup: testAssertion/target ] (required) The artifacts to be tested, defined by an XPath expression that returns a list of XML nodes from the log file in input. For every artifact (node) selected by the Target expression, there will be a report entry for this TA in the test report, with a result of either:
See the "reporting" item for the meaning of these results. |
Cotarget: |
[markup: testAssertion/cotarget ] (optional) Artifact that is related to the target, and that needs be accessed for the testing. Identified by an XPath expression that may refer to the related target node using the variable '$target'. For example, the target can be a SOAP message and the cotarget the WSDL file that describes this SOAP message. A cotarget must have a @name attribute that identifies it. The value of this attribute can be used as a variable (when prepending '$' to it) by subsequently defined cotargets, prerequisite and predicate. |
Prerequisite: |
[markup: testAssertion/@preReq ] (optional) [markup: testAssertion/prerequisite ] (optional) The pre-condition for evaluating this Test Assertion on this target. If the prerequisite evaluates to "false" then the target does not qualify for this Test Assertion (the test report is "notRelevant") The first part (preReq attribute) is an enumeration of Test Assertion IDs. Each one of the prerequisite TAs must either use the same target (e.g. SOAP Envelope, or WSDL binding, etc.) as this TA, or a target that is of a more general type than the main TA target. The target must "pass" each one of these prerequisite TAs in order to qualify for this TA. (e.g. the target of TA t1 can be a WSDL binding while the target of a TA t2 prerequisite of t1, can be the entire WSDL file). The second part ("prerequisite" element) is an XPath (boolean) expression of the same nature as the predicate. If present, it must evaluate to "true" for the target to qualify. If it fails, the result for the current TA in the report will be "notRelevant". Otherwise, the target can be further evaluated by the predicate of the main TA. The expression may refer to the target explicitly using the variable name "$target", or to any cotarget using its name as variable name ($[name]). |
Predicate: |
[markup: testAssertion/predicate] required element] A logical expression that evaluates whether this target is fulfilling the profile requirement addressed by this test Assertion. By default: - A result of true means the requirement is fulfilled (reported as a "passed" in the test report).- A result of false means the requirement is violated (reported as a "failed" in the test report). However, in some cases and for testability reasons, the predicate may be designed as a partial indicator e.g. only indicates some cases of fulfillment, or some cases of violation. As a result, when "true" indicates fulfillment it may be that "false" is unconclusive, or conversely "false" will indicate violation, but "true" is unconclusive. In such cases, the "Reporting" element specifies the meaning of the predicate result w/r to the profile requirement. The predicate expression implicitly refers to the target (whic is its "XPath context") although it may explicitly refer to it using the variable name "$target". It may refer to any cotarget using its name as variable name ($[name]). |
Prescription: |
[markup: testAssertion/prescription/@level ] (required) Conveys the level of prescription associated with the profile requirement. At least three values may be used:
|
Reporting: |
[markup: testAssertion/reporting ] (optional) For each possible outcome of the predicate (true or false), specifies how it must be interpreted w/r to the profile feature. Two attributes are used that both must be present, when this element is present:
NOTES: the predicate of the TA may be worded in a negative way so that @false='passed' although that is not recommended. The result of a test should not be related to the prescription level, e.g. a "preferred" or "permitted" level should not imply that @false='warning'. Other test results that are automatically generated and not controlled by the "reporting" element are:
|
R2113 When referring to a non-addressable endpoint, and if present in a SOAP ENVELOPE, the /wsrm:CreateSequence/wsrm:Offer/wsrm:Endpoint element MUST be set to an instance of the WS-MakeConnection anonymous URI.TESTABLE RSP2113
Test Assertion Analysis: | RSP2113 |
---|---|
General Notes: | To ensure all of the RM features can be used, even when a non-addressable endpoint is used, the RSP requires implementations to use an instance of the MC Anonymous URI in the CS/Offer/Endpoint EPR. |
Coverage Assessment: | Good (should be able to cover all cases) |
Target Type: | ENVELOPE |
Test Target: | A CreateSequence message that contains an Offer element. |
Test co-Target(s): | |
Test Prerequisite: | |
Predicate: | The [target] does not have a CreateSequence/Offer/wsa:Address element with a value of wsa:Anonymous or wsa:None. |
Prescription: | mandatory |
Reporting: | true=passed, false=failed |
Test Control: | Run some reliable request/response tests where the client is non-addressable and make sure the CreateSequence contains an Offer. |
Test Assertion: | RSP2113 |
---|---|
Description: | |
Target: |
[*:Body/wsrm:CreateSequence/wsrm:Offer and
(fn:contains(xsd:string(*:Body/wsrm:CreateSequence/wsrm:Offer/wsrm:Endpoint/*:Address),
'anonymous') or
]fn:contains(xsd:string(*:Body/wsrm:CreateSequence/wsrm:Offer/wsrm:Endpoint/*:Address), 'none')) |
Predicate: |
|
Reporting: | true=passed, false=failed |
Prescription: | mandatory |
Error Message: | The CreateSequence message is Offering a sequence and provides an Endpoint address that does not indicate an addressable endpoint, yet that is not an MC Anonymous URI. |
Diagnostic Data: |
|
Test Assertion Part | What it means: |
---|---|
Test Assertion ID: |
[markup: testAssertion/@id] (required) A unique ID for the current test assertion. |
Description: |
[markup: testAssertion/description ] (optional) A plain text description of the current test assertion. At minimum expressing the TA predicate. |
Comments: |
[markup: testAssertion/comments ] (optional) A plain text comment about the TA script and how well it covers the profile requirement. Explanation material for users, and developers (what could be improved, etc.). |
Target: |
[markup: testAssertion/target ] (required) The artifacts to be tested, defined by an XPath expression that returns a list of XML nodes from the log file in input. For every artifact (node) selected by the Target expression, there will be a report entry for this TA in the test report, with a result of either:
See the "reporting" item for the meaning of these results. |
Cotarget: |
[markup: testAssertion/cotarget ] (optional) Artifact that is related to the target, and that needs be accessed for the testing. Identified by an XPath expression that may refer to the related target node using the variable '$target'. For example, the target can be a SOAP message and the cotarget the WSDL file that describes this SOAP message. A cotarget must have a @name attribute that identifies it. The value of this attribute can be used as a variable (when prepending '$' to it) by subsequently defined cotargets, prerequisite and predicate. |
Prerequisite: |
[markup: testAssertion/@preReq ] (optional) [markup: testAssertion/prerequisite ] (optional) The pre-condition for evaluating this Test Assertion on this target. If the prerequisite evaluates to "false" then the target does not qualify for this Test Assertion (the test report is "notRelevant") The first part (preReq attribute) is an enumeration of Test Assertion IDs. Each one of the prerequisite TAs must either use the same target (e.g. SOAP Envelope, or WSDL binding, etc.) as this TA, or a target that is of a more general type than the main TA target. The target must "pass" each one of these prerequisite TAs in order to qualify for this TA. (e.g. the target of TA t1 can be a WSDL binding while the target of a TA t2 prerequisite of t1, can be the entire WSDL file). The second part ("prerequisite" element) is an XPath (boolean) expression of the same nature as the predicate. If present, it must evaluate to "true" for the target to qualify. If it fails, the result for the current TA in the report will be "notRelevant". Otherwise, the target can be further evaluated by the predicate of the main TA. The expression may refer to the target explicitly using the variable name "$target", or to any cotarget using its name as variable name ($[name]). |
Predicate: |
[markup: testAssertion/predicate] required element] A logical expression that evaluates whether this target is fulfilling the profile requirement addressed by this test Assertion. By default: - A result of true means the requirement is fulfilled (reported as a "passed" in the test report).- A result of false means the requirement is violated (reported as a "failed" in the test report). However, in some cases and for testability reasons, the predicate may be designed as a partial indicator e.g. only indicates some cases of fulfillment, or some cases of violation. As a result, when "true" indicates fulfillment it may be that "false" is unconclusive, or conversely "false" will indicate violation, but "true" is unconclusive. In such cases, the "Reporting" element specifies the meaning of the predicate result w/r to the profile requirement. The predicate expression implicitly refers to the target (whic is its "XPath context") although it may explicitly refer to it using the variable name "$target". It may refer to any cotarget using its name as variable name ($[name]). |
Prescription: |
[markup: testAssertion/prescription/@level ] (required) Conveys the level of prescription associated with the profile requirement. At least three values may be used:
|
Reporting: |
[markup: testAssertion/reporting ] (optional) For each possible outcome of the predicate (true or false), specifies how it must be interpreted w/r to the profile feature. Two attributes are used that both must be present, when this element is present:
NOTES: the predicate of the TA may be worded in a negative way so that @false='passed' although that is not recommended. The result of a test should not be related to the prescription level, e.g. a "preferred" or "permitted" level should not imply that @false='warning'. Other test results that are automatically generated and not controlled by the "reporting" element are:
|
Section 4 of WS-MakeConnection describes how to map the
properties of the faults generated by WS-MakeConnection
implementations to SOAP 1.1 and 1.2 fault messages. Although the
description of the binding to SOAP 1.2 binds the [Detail] property
of a fault to the /soap12:Fault/soap12:Detail
element,
there is no description of how to bind the [Detail] property to any
element of a SOAP 1.1 fault message.
The following requirement describes how to bind the [Detail] property of a fault to a SOAP 1.1 fault message.
R2200 An MC-RECEIVER that generates a SOAP 1.1 fault MUST include the value of the [Detail] property, if such a value exists, as the first child of the /soap11:Fault/detail element.TESTABLE RSP2200
Test Assertion Analysis: | RSP2200 |
---|---|
General Notes: | . |
Coverage Assessment: | |
Target Type: | |
Test Target: | |
Test co-Target(s): | |
Test Prerequisite: | |
Predicate: | |
Prescription: | mandatory |
Reporting: | |
Test Control: |
Test Assertion: | RSP2200 |
---|---|
Description: | An MC-RECEIVER that generates a SOAP 1.1 fault MUST include the value of the [Detail] property, if such a value exists, as the first child of the /soap11:Fault/detail element. |
Target: |
|
Predicate: |
|
Reporting: | true=passed, false=failed |
Prescription: | mandatory |
Error Message: | A SOAP 1.1 message containing a Fault element in its body, has a default element that is not immediate child of soap11:Body/soap11:Fault. |
Diagnostic Data: |
|
Test Assertion Part | What it means: |
---|---|
Test Assertion ID: |
[markup: testAssertion/@id] (required) A unique ID for the current test assertion. |
Description: |
[markup: testAssertion/description ] (optional) A plain text description of the current test assertion. At minimum expressing the TA predicate. |
Comments: |
[markup: testAssertion/comments ] (optional) A plain text comment about the TA script and how well it covers the profile requirement. Explanation material for users, and developers (what could be improved, etc.). |
Target: |
[markup: testAssertion/target ] (required) The artifacts to be tested, defined by an XPath expression that returns a list of XML nodes from the log file in input. For every artifact (node) selected by the Target expression, there will be a report entry for this TA in the test report, with a result of either:
See the "reporting" item for the meaning of these results. |
Cotarget: |
[markup: testAssertion/cotarget ] (optional) Artifact that is related to the target, and that needs be accessed for the testing. Identified by an XPath expression that may refer to the related target node using the variable '$target'. For example, the target can be a SOAP message and the cotarget the WSDL file that describes this SOAP message. A cotarget must have a @name attribute that identifies it. The value of this attribute can be used as a variable (when prepending '$' to it) by subsequently defined cotargets, prerequisite and predicate. |
Prerequisite: |
[markup: testAssertion/@preReq ] (optional) [markup: testAssertion/prerequisite ] (optional) The pre-condition for evaluating this Test Assertion on this target. If the prerequisite evaluates to "false" then the target does not qualify for this Test Assertion (the test report is "notRelevant") The first part (preReq attribute) is an enumeration of Test Assertion IDs. Each one of the prerequisite TAs must either use the same target (e.g. SOAP Envelope, or WSDL binding, etc.) as this TA, or a target that is of a more general type than the main TA target. The target must "pass" each one of these prerequisite TAs in order to qualify for this TA. (e.g. the target of TA t1 can be a WSDL binding while the target of a TA t2 prerequisite of t1, can be the entire WSDL file). The second part ("prerequisite" element) is an XPath (boolean) expression of the same nature as the predicate. If present, it must evaluate to "true" for the target to qualify. If it fails, the result for the current TA in the report will be "notRelevant". Otherwise, the target can be further evaluated by the predicate of the main TA. The expression may refer to the target explicitly using the variable name "$target", or to any cotarget using its name as variable name ($[name]). |
Predicate: |
[markup: testAssertion/predicate] required element] A logical expression that evaluates whether this target is fulfilling the profile requirement addressed by this test Assertion. By default: - A result of true means the requirement is fulfilled (reported as a "passed" in the test report).- A result of false means the requirement is violated (reported as a "failed" in the test report). However, in some cases and for testability reasons, the predicate may be designed as a partial indicator e.g. only indicates some cases of fulfillment, or some cases of violation. As a result, when "true" indicates fulfillment it may be that "false" is unconclusive, or conversely "false" will indicate violation, but "true" is unconclusive. In such cases, the "Reporting" element specifies the meaning of the predicate result w/r to the profile requirement. The predicate expression implicitly refers to the target (whic is its "XPath context") although it may explicitly refer to it using the variable name "$target". It may refer to any cotarget using its name as variable name ($[name]). |
Prescription: |
[markup: testAssertion/prescription/@level ] (required) Conveys the level of prescription associated with the profile requirement. At least three values may be used:
|
Reporting: |
[markup: testAssertion/reporting ] (optional) For each possible outcome of the predicate (true or false), specifies how it must be interpreted w/r to the profile feature. Two attributes are used that both must be present, when this element is present:
NOTES: the predicate of the TA may be worded in a negative way so that @false='passed' although that is not recommended. The result of a test should not be related to the prescription level, e.g. a "preferred" or "permitted" level should not imply that @false='warning'. Other test results that are automatically generated and not controlled by the "reporting" element are:
|
This section of the Profile contains requirements that address the composition of reliable and secure messaging.
This section of the Profile incorporates the following specifications by reference:
These extensibility points are listed, along with any extensibility points from other sections of this Profile, in Appendix B
Section 5.2.2.1 of the WS-ReliableMessaging specification states that "During the CreateSequence exchange, the RM Source SHOULD explicitly identify the security context that will be used to protect the Sequence". This leaves open the possibility for RMS implementations that, for some reason, attempt to use WS-SC to secure their Sequences in some manner that does not explicitly identify the security context that will be used to protect the Sequence (e.g. by some out of band understanding of an inferred security context). This possibility creates an obvious operational and interoperability issues since (a) point-to-point, out-of-band configuration creates unscalable operational overhead and (b) not all WS-RM implementations may be capable of supporting such understandings.
Within Section 6, the phrase "secure Sequence" is defined as "a Sequence beginning with an exchange in which the wsrm:CreateSequence element has been extended with a wsse:SecurityTokenReference element." This profile does not cover the out-of-band understandings mentioned just above.
When initiating a secure Sequence, an RMS must ensure that the RMD both understands and will conform to the requirements listed above.
R3010 If an ENVELOPE contains a wsrm:CreateSequence element as a child of the SOAP Body, and the proposed Sequence is to be secured, the ENVELOPE MUST also include the wsrm:UsesSequenceSTR element as a SOAP header block.TESTABLE RSP3010
Test Assertion Analysis: | RSP3010 |
---|---|
General Notes: | |
Coverage Assessment: | Good |
Target Type: | ENVELOPE |
Test Target: | For an Envelope that contains a wsrm:CreateSequence element that has security token ref |
Test co-Target(s): | |
Test Prerequisite: | |
Predicate: | Envelope includes the UsesSequenceSTR header |
Prescription: | mandatory |
Reporting: | (default) |
Test Control: | scenario provide the expected "context" (manipulate content of CreateSequence) |
Test Assertion: | RSP3010 |
---|---|
Description: | |
Target: |
|
Predicate: |
|
Reporting: | true=passed, false=failed |
Prescription: | mandatory |
Error Message: | An Envelope that contains a wsrm:CreateSequence element that has a security token reference (wsse:SecurityTokenReference) does not include the UsesSequenceSTR header. |
Diagnostic Data: |
|
Test Assertion Part | What it means: |
---|---|
Test Assertion ID: |
[markup: testAssertion/@id] (required) A unique ID for the current test assertion. |
Description: |
[markup: testAssertion/description ] (optional) A plain text description of the current test assertion. At minimum expressing the TA predicate. |
Comments: |
[markup: testAssertion/comments ] (optional) A plain text comment about the TA script and how well it covers the profile requirement. Explanation material for users, and developers (what could be improved, etc.). |
Target: |
[markup: testAssertion/target ] (required) The artifacts to be tested, defined by an XPath expression that returns a list of XML nodes from the log file in input. For every artifact (node) selected by the Target expression, there will be a report entry for this TA in the test report, with a result of either:
See the "reporting" item for the meaning of these results. |
Cotarget: |
[markup: testAssertion/cotarget ] (optional) Artifact that is related to the target, and that needs be accessed for the testing. Identified by an XPath expression that may refer to the related target node using the variable '$target'. For example, the target can be a SOAP message and the cotarget the WSDL file that describes this SOAP message. A cotarget must have a @name attribute that identifies it. The value of this attribute can be used as a variable (when prepending '$' to it) by subsequently defined cotargets, prerequisite and predicate. |
Prerequisite: |
[markup: testAssertion/@preReq ] (optional) [markup: testAssertion/prerequisite ] (optional) The pre-condition for evaluating this Test Assertion on this target. If the prerequisite evaluates to "false" then the target does not qualify for this Test Assertion (the test report is "notRelevant") The first part (preReq attribute) is an enumeration of Test Assertion IDs. Each one of the prerequisite TAs must either use the same target (e.g. SOAP Envelope, or WSDL binding, etc.) as this TA, or a target that is of a more general type than the main TA target. The target must "pass" each one of these prerequisite TAs in order to qualify for this TA. (e.g. the target of TA t1 can be a WSDL binding while the target of a TA t2 prerequisite of t1, can be the entire WSDL file). The second part ("prerequisite" element) is an XPath (boolean) expression of the same nature as the predicate. If present, it must evaluate to "true" for the target to qualify. If it fails, the result for the current TA in the report will be "notRelevant". Otherwise, the target can be further evaluated by the predicate of the main TA. The expression may refer to the target explicitly using the variable name "$target", or to any cotarget using its name as variable name ($[name]). |
Predicate: |
[markup: testAssertion/predicate] required element] A logical expression that evaluates whether this target is fulfilling the profile requirement addressed by this test Assertion. By default: - A result of true means the requirement is fulfilled (reported as a "passed" in the test report).- A result of false means the requirement is violated (reported as a "failed" in the test report). However, in some cases and for testability reasons, the predicate may be designed as a partial indicator e.g. only indicates some cases of fulfillment, or some cases of violation. As a result, when "true" indicates fulfillment it may be that "false" is unconclusive, or conversely "false" will indicate violation, but "true" is unconclusive. In such cases, the "Reporting" element specifies the meaning of the predicate result w/r to the profile requirement. The predicate expression implicitly refers to the target (whic is its "XPath context") although it may explicitly refer to it using the variable name "$target". It may refer to any cotarget using its name as variable name ($[name]). |
Prescription: |
[markup: testAssertion/prescription/@level ] (required) Conveys the level of prescription associated with the profile requirement. At least three values may be used:
|
Reporting: |
[markup: testAssertion/reporting ] (optional) For each possible outcome of the predicate (true or false), specifies how it must be interpreted w/r to the profile feature. Two attributes are used that both must be present, when this element is present:
NOTES: the predicate of the TA may be worded in a negative way so that @false='passed' although that is not recommended. The result of a test should not be related to the prescription level, e.g. a "preferred" or "permitted" level should not imply that @false='warning'. Other test results that are automatically generated and not controlled by the "reporting" element are:
|
In a secure Sequence there exists both security and interoperability issues around the inclusion of SOAP message elements within signatures.
As discussed in Section 5.1.1 of WS-ReliableMessaging, any mechanism which allows an attacker to alter the information in a Sequence Traffic Message or break the linkage between a wsrm:Sequence header block and its assigned message, represents a threat to the WS-RM protocol.
R3100 When present in an ENVELOPE in a secure Sequence, the wsrm:Sequence header block MUST be included in a signature.TESTABLE RSP3100a RSP3100b
Test Assertion Analysis: | RSP3100a |
---|---|
General Notes: | The signature elt contains a key ref that points to CreateSequence (the CS defining a Secured RM Sequence), and either (a) the sig signs directly the Body, or (b) signs another sig element with same key ref, that itself references the Body. |
Coverage Assessment: | Partial |
Target Type: | ENVELOPE |
Test Target: | In an Envelope that belong to a secured RM seq. (has a related qualifying CS that contains UsesSequenceSTR) |
Test co-Target(s): | |
Test Prerequisite: | |
Predicate: | (negative case) there is a sig element that signs the seq Header that does not also reference the Body OR there is no element that signs the body |
Prescription: | mandatory |
Reporting: | true=fail, false=undetermined |
Test Control: |
Test Assertion: | RSP3100a |
---|---|
Description: | Case non-encrypted CS/CSR |
Target: |
|
Predicate: |
|
Reporting: | true=passed, false=failed |
Prescription: | mandatory |
Error Message: | In an Envelope that belong to a secured RM sequence the wsrm:Sequence element is not signed. (Case with wsrm:CSR non-encrypted) |
Diagnostic Data: |
|
Test Assertion Part | What it means: |
---|---|
Test Assertion ID: |
[markup: testAssertion/@id] (required) A unique ID for the current test assertion. |
Description: |
[markup: testAssertion/description ] (optional) A plain text description of the current test assertion. At minimum expressing the TA predicate. |
Comments: |
[markup: testAssertion/comments ] (optional) A plain text comment about the TA script and how well it covers the profile requirement. Explanation material for users, and developers (what could be improved, etc.). |
Target: |
[markup: testAssertion/target ] (required) The artifacts to be tested, defined by an XPath expression that returns a list of XML nodes from the log file in input. For every artifact (node) selected by the Target expression, there will be a report entry for this TA in the test report, with a result of either:
See the "reporting" item for the meaning of these results. |
Cotarget: |
[markup: testAssertion/cotarget ] (optional) Artifact that is related to the target, and that needs be accessed for the testing. Identified by an XPath expression that may refer to the related target node using the variable '$target'. For example, the target can be a SOAP message and the cotarget the WSDL file that describes this SOAP message. A cotarget must have a @name attribute that identifies it. The value of this attribute can be used as a variable (when prepending '$' to it) by subsequently defined cotargets, prerequisite and predicate. |
Prerequisite: |
[markup: testAssertion/@preReq ] (optional) [markup: testAssertion/prerequisite ] (optional) The pre-condition for evaluating this Test Assertion on this target. If the prerequisite evaluates to "false" then the target does not qualify for this Test Assertion (the test report is "notRelevant") The first part (preReq attribute) is an enumeration of Test Assertion IDs. Each one of the prerequisite TAs must either use the same target (e.g. SOAP Envelope, or WSDL binding, etc.) as this TA, or a target that is of a more general type than the main TA target. The target must "pass" each one of these prerequisite TAs in order to qualify for this TA. (e.g. the target of TA t1 can be a WSDL binding while the target of a TA t2 prerequisite of t1, can be the entire WSDL file). The second part ("prerequisite" element) is an XPath (boolean) expression of the same nature as the predicate. If present, it must evaluate to "true" for the target to qualify. If it fails, the result for the current TA in the report will be "notRelevant". Otherwise, the target can be further evaluated by the predicate of the main TA. The expression may refer to the target explicitly using the variable name "$target", or to any cotarget using its name as variable name ($[name]). |
Predicate: |
[markup: testAssertion/predicate] required element] A logical expression that evaluates whether this target is fulfilling the profile requirement addressed by this test Assertion. By default: - A result of true means the requirement is fulfilled (reported as a "passed" in the test report).- A result of false means the requirement is violated (reported as a "failed" in the test report). However, in some cases and for testability reasons, the predicate may be designed as a partial indicator e.g. only indicates some cases of fulfillment, or some cases of violation. As a result, when "true" indicates fulfillment it may be that "false" is unconclusive, or conversely "false" will indicate violation, but "true" is unconclusive. In such cases, the "Reporting" element specifies the meaning of the predicate result w/r to the profile requirement. The predicate expression implicitly refers to the target (whic is its "XPath context") although it may explicitly refer to it using the variable name "$target". It may refer to any cotarget using its name as variable name ($[name]). |
Prescription: |
[markup: testAssertion/prescription/@level ] (required) Conveys the level of prescription associated with the profile requirement. At least three values may be used:
|
Reporting: |
[markup: testAssertion/reporting ] (optional) For each possible outcome of the predicate (true or false), specifies how it must be interpreted w/r to the profile feature. Two attributes are used that both must be present, when this element is present:
NOTES: the predicate of the TA may be worded in a negative way so that @false='passed' although that is not recommended. The result of a test should not be related to the prescription level, e.g. a "preferred" or "permitted" level should not imply that @false='warning'. Other test results that are automatically generated and not controlled by the "reporting" element are:
|
Test Assertion Analysis: | RSP3100b |
---|---|
General Notes: | The signature elt contains a key ref that points to CreateSequence (the CS defining a Secured RM Sequence), and either (a) the sig signs directly the Body, or (b) signs another sig element with same key ref, that itself references the Body. |
Coverage Assessment: | Partial |
Target Type: | ENVELOPE |
Test Target: | In an Envelope that belong to a secured RM seq. (has a related qualifying CS that contains UsesSequenceSTR) |
Test co-Target(s): | |
Test Prerequisite: | |
Predicate: | (negative case) there is a sig element that signs the seq Header that does not also reference the Body OR there is no element that signs the body |
Prescription: | mandatory |
Reporting: | true=fail, false=undetermined |
Test Control: |
Test Assertion: | RSP3100b |
---|---|
Description: | Case encrypted CS/CSR |
Target: |
|
Predicate: |
|
Reporting: | true=passed, false=failed |
Prescription: | mandatory |
Error Message: | In an Envelope that belong to a secured RM sequence the wsrm:Sequence element is not signed. (Case with wsrm:CSR encrypted) |
Diagnostic Data: |
|
Test Assertion Part | What it means: |
---|---|
Test Assertion ID: |
[markup: testAssertion/@id] (required) A unique ID for the current test assertion. |
Description: |
[markup: testAssertion/description ] (optional) A plain text description of the current test assertion. At minimum expressing the TA predicate. |
Comments: |
[markup: testAssertion/comments ] (optional) A plain text comment about the TA script and how well it covers the profile requirement. Explanation material for users, and developers (what could be improved, etc.). |
Target: |
[markup: testAssertion/target ] (required) The artifacts to be tested, defined by an XPath expression that returns a list of XML nodes from the log file in input. For every artifact (node) selected by the Target expression, there will be a report entry for this TA in the test report, with a result of either:
See the "reporting" item for the meaning of these results. |
Cotarget: |
[markup: testAssertion/cotarget ] (optional) Artifact that is related to the target, and that needs be accessed for the testing. Identified by an XPath expression that may refer to the related target node using the variable '$target'. For example, the target can be a SOAP message and the cotarget the WSDL file that describes this SOAP message. A cotarget must have a @name attribute that identifies it. The value of this attribute can be used as a variable (when prepending '$' to it) by subsequently defined cotargets, prerequisite and predicate. |
Prerequisite: |
[markup: testAssertion/@preReq ] (optional) [markup: testAssertion/prerequisite ] (optional) The pre-condition for evaluating this Test Assertion on this target. If the prerequisite evaluates to "false" then the target does not qualify for this Test Assertion (the test report is "notRelevant") The first part (preReq attribute) is an enumeration of Test Assertion IDs. Each one of the prerequisite TAs must either use the same target (e.g. SOAP Envelope, or WSDL binding, etc.) as this TA, or a target that is of a more general type than the main TA target. The target must "pass" each one of these prerequisite TAs in order to qualify for this TA. (e.g. the target of TA t1 can be a WSDL binding while the target of a TA t2 prerequisite of t1, can be the entire WSDL file). The second part ("prerequisite" element) is an XPath (boolean) expression of the same nature as the predicate. If present, it must evaluate to "true" for the target to qualify. If it fails, the result for the current TA in the report will be "notRelevant". Otherwise, the target can be further evaluated by the predicate of the main TA. The expression may refer to the target explicitly using the variable name "$target", or to any cotarget using its name as variable name ($[name]). |
Predicate: |
[markup: testAssertion/predicate] required element] A logical expression that evaluates whether this target is fulfilling the profile requirement addressed by this test Assertion. By default: - A result of true means the requirement is fulfilled (reported as a "passed" in the test report).- A result of false means the requirement is violated (reported as a "failed" in the test report). However, in some cases and for testability reasons, the predicate may be designed as a partial indicator e.g. only indicates some cases of fulfillment, or some cases of violation. As a result, when "true" indicates fulfillment it may be that "false" is unconclusive, or conversely "false" will indicate violation, but "true" is unconclusive. In such cases, the "Reporting" element specifies the meaning of the predicate result w/r to the profile requirement. The predicate expression implicitly refers to the target (whic is its "XPath context") although it may explicitly refer to it using the variable name "$target". It may refer to any cotarget using its name as variable name ($[name]). |
Prescription: |
[markup: testAssertion/prescription/@level ] (required) Conveys the level of prescription associated with the profile requirement. At least three values may be used:
|
Reporting: |
[markup: testAssertion/reporting ] (optional) For each possible outcome of the predicate (true or false), specifies how it must be interpreted w/r to the profile feature. Two attributes are used that both must be present, when this element is present:
NOTES: the predicate of the TA may be worded in a negative way so that @false='passed' although that is not recommended. The result of a test should not be related to the prescription level, e.g. a "preferred" or "permitted" level should not imply that @false='warning'. Other test results that are automatically generated and not controlled by the "reporting" element are:
|
R3101 In an ENVELOPE, the signature referred to in R3100 MUST be coupled cryptographically (e.g. share a common signature) with the message body.TESTABLE RSP3101a RSP3101b
Test Assertion Analysis: | RSP3101a |
---|---|
General Notes: | |
Coverage Assessment: | Good |
Target Type: | ENVELOPE |
Test Target: | |
Test co-Target(s): | |
Test Prerequisite: | |
Predicate: | |
Prescription: | mandatory |
Reporting: | true=pass, false=fail |
Test Control: |
Test Assertion: | RSP3101a |
---|---|
Description: | Case non-encrypted CS/CSR |
Target: |
|
Prerequisite: | RSP3100a |
Predicate: |
|
Reporting: | true=passed, false=failed |
Prescription: | mandatory |
Error Message: | The wsrm:Sequence element is not signed with the same signature as the Body signature, based on existing @wsu:Id references. |
Diagnostic Data: |
|
Test Assertion Part | What it means: |
---|---|
Test Assertion ID: |
[markup: testAssertion/@id] (required) A unique ID for the current test assertion. |
Description: |
[markup: testAssertion/description ] (optional) A plain text description of the current test assertion. At minimum expressing the TA predicate. |
Comments: |
[markup: testAssertion/comments ] (optional) A plain text comment about the TA script and how well it covers the profile requirement. Explanation material for users, and developers (what could be improved, etc.). |
Target: |
[markup: testAssertion/target ] (required) The artifacts to be tested, defined by an XPath expression that returns a list of XML nodes from the log file in input. For every artifact (node) selected by the Target expression, there will be a report entry for this TA in the test report, with a result of either:
See the "reporting" item for the meaning of these results. |
Cotarget: |
[markup: testAssertion/cotarget ] (optional) Artifact that is related to the target, and that needs be accessed for the testing. Identified by an XPath expression that may refer to the related target node using the variable '$target'. For example, the target can be a SOAP message and the cotarget the WSDL file that describes this SOAP message. A cotarget must have a @name attribute that identifies it. The value of this attribute can be used as a variable (when prepending '$' to it) by subsequently defined cotargets, prerequisite and predicate. |
Prerequisite: |
[markup: testAssertion/@preReq ] (optional) [markup: testAssertion/prerequisite ] (optional) The pre-condition for evaluating this Test Assertion on this target. If the prerequisite evaluates to "false" then the target does not qualify for this Test Assertion (the test report is "notRelevant") The first part (preReq attribute) is an enumeration of Test Assertion IDs. Each one of the prerequisite TAs must either use the same target (e.g. SOAP Envelope, or WSDL binding, etc.) as this TA, or a target that is of a more general type than the main TA target. The target must "pass" each one of these prerequisite TAs in order to qualify for this TA. (e.g. the target of TA t1 can be a WSDL binding while the target of a TA t2 prerequisite of t1, can be the entire WSDL file). The second part ("prerequisite" element) is an XPath (boolean) expression of the same nature as the predicate. If present, it must evaluate to "true" for the target to qualify. If it fails, the result for the current TA in the report will be "notRelevant". Otherwise, the target can be further evaluated by the predicate of the main TA. The expression may refer to the target explicitly using the variable name "$target", or to any cotarget using its name as variable name ($[name]). |
Predicate: |
[markup: testAssertion/predicate] required element] A logical expression that evaluates whether this target is fulfilling the profile requirement addressed by this test Assertion. By default: - A result of true means the requirement is fulfilled (reported as a "passed" in the test report).- A result of false means the requirement is violated (reported as a "failed" in the test report). However, in some cases and for testability reasons, the predicate may be designed as a partial indicator e.g. only indicates some cases of fulfillment, or some cases of violation. As a result, when "true" indicates fulfillment it may be that "false" is unconclusive, or conversely "false" will indicate violation, but "true" is unconclusive. In such cases, the "Reporting" element specifies the meaning of the predicate result w/r to the profile requirement. The predicate expression implicitly refers to the target (whic is its "XPath context") although it may explicitly refer to it using the variable name "$target". It may refer to any cotarget using its name as variable name ($[name]). |
Prescription: |
[markup: testAssertion/prescription/@level ] (required) Conveys the level of prescription associated with the profile requirement. At least three values may be used:
|
Reporting: |
[markup: testAssertion/reporting ] (optional) For each possible outcome of the predicate (true or false), specifies how it must be interpreted w/r to the profile feature. Two attributes are used that both must be present, when this element is present:
NOTES: the predicate of the TA may be worded in a negative way so that @false='passed' although that is not recommended. The result of a test should not be related to the prescription level, e.g. a "preferred" or "permitted" level should not imply that @false='warning'. Other test results that are automatically generated and not controlled by the "reporting" element are:
|
Test Assertion Analysis: | RSP3101b |
---|---|
General Notes: | |
Coverage Assessment: | Good |
Target Type: | ENVELOPE |
Test Target: | |
Test co-Target(s): | |
Test Prerequisite: | |
Predicate: | |
Prescription: | mandatory |
Reporting: | true=pass, false=fail |
Test Control: |
Test Assertion: | RSP3101b |
---|---|
Description: | Case encrypted CS/CSR |
Target: |
|
Prerequisite: | RSP3100b |
Predicate: |
|
Reporting: | true=passed, false=failed |
Prescription: | mandatory |
Error Message: | The wsrm:Sequence element is not signed with the same signature as the Body signature, based on existing @wsu:Id references. |
Diagnostic Data: |
|
Test Assertion Part | What it means: |
---|---|
Test Assertion ID: |
[markup: testAssertion/@id] (required) A unique ID for the current test assertion. |
Description: |
[markup: testAssertion/description ] (optional) A plain text description of the current test assertion. At minimum expressing the TA predicate. |
Comments: |
[markup: testAssertion/comments ] (optional) A plain text comment about the TA script and how well it covers the profile requirement. Explanation material for users, and developers (what could be improved, etc.). |
Target: |
[markup: testAssertion/target ] (required) The artifacts to be tested, defined by an XPath expression that returns a list of XML nodes from the log file in input. For every artifact (node) selected by the Target expression, there will be a report entry for this TA in the test report, with a result of either:
See the "reporting" item for the meaning of these results. |
Cotarget: |
[markup: testAssertion/cotarget ] (optional) Artifact that is related to the target, and that needs be accessed for the testing. Identified by an XPath expression that may refer to the related target node using the variable '$target'. For example, the target can be a SOAP message and the cotarget the WSDL file that describes this SOAP message. A cotarget must have a @name attribute that identifies it. The value of this attribute can be used as a variable (when prepending '$' to it) by subsequently defined cotargets, prerequisite and predicate. |
Prerequisite: |
[markup: testAssertion/@preReq ] (optional) [markup: testAssertion/prerequisite ] (optional) The pre-condition for evaluating this Test Assertion on this target. If the prerequisite evaluates to "false" then the target does not qualify for this Test Assertion (the test report is "notRelevant") The first part (preReq attribute) is an enumeration of Test Assertion IDs. Each one of the prerequisite TAs must either use the same target (e.g. SOAP Envelope, or WSDL binding, etc.) as this TA, or a target that is of a more general type than the main TA target. The target must "pass" each one of these prerequisite TAs in order to qualify for this TA. (e.g. the target of TA t1 can be a WSDL binding while the target of a TA t2 prerequisite of t1, can be the entire WSDL file). The second part ("prerequisite" element) is an XPath (boolean) expression of the same nature as the predicate. If present, it must evaluate to "true" for the target to qualify. If it fails, the result for the current TA in the report will be "notRelevant". Otherwise, the target can be further evaluated by the predicate of the main TA. The expression may refer to the target explicitly using the variable name "$target", or to any cotarget using its name as variable name ($[name]). |
Predicate: |
[markup: testAssertion/predicate] required element] A logical expression that evaluates whether this target is fulfilling the profile requirement addressed by this test Assertion. By default: - A result of true means the requirement is fulfilled (reported as a "passed" in the test report).- A result of false means the requirement is violated (reported as a "failed" in the test report). However, in some cases and for testability reasons, the predicate may be designed as a partial indicator e.g. only indicates some cases of fulfillment, or some cases of violation. As a result, when "true" indicates fulfillment it may be that "false" is unconclusive, or conversely "false" will indicate violation, but "true" is unconclusive. In such cases, the "Reporting" element specifies the meaning of the predicate result w/r to the profile requirement. The predicate expression implicitly refers to the target (whic is its "XPath context") although it may explicitly refer to it using the variable name "$target". It may refer to any cotarget using its name as variable name ($[name]). |
Prescription: |
[markup: testAssertion/prescription/@level ] (required) Conveys the level of prescription associated with the profile requirement. At least three values may be used:
|
Reporting: |
[markup: testAssertion/reporting ] (optional) For each possible outcome of the predicate (true or false), specifies how it must be interpreted w/r to the profile feature. Two attributes are used that both must be present, when this element is present:
NOTES: the predicate of the TA may be worded in a negative way so that @false='passed' although that is not recommended. The result of a test should not be related to the prescription level, e.g. a "preferred" or "permitted" level should not imply that @false='warning'. Other test results that are automatically generated and not controlled by the "reporting" element are:
|
R3102 In an ENVELOPE, the signature referred to in R3100 MUST be created using the key(s) associated with the security context that protects the applicable Sequence.NOT_TESTABLE
As discussed in Section 5.1.1 of WS-ReliableMessaging, any mechanism which allows an attacker to alter the information in a Sequence Lifecycle Message, Acknowledgement Messages, Acknowledgement Request, or Sequence-related fault represents a threat to the WS-RM protocol.
R3110 If a wsrm:CreateSequence, wsrm:CreateSequenceResponse, wsrm:CloseSequence, wsrm:CloseSequenceResponse, wsrm:TerminateSequence, or wsrm:TerminateSequenceResponse element appears in the body of an ENVELOPE in a secure Sequence, that body MUST be included in a signature.TESTABLE RSP3110a RSP3110b
Test Assertion Analysis: | RSP3110a |
---|---|
General Notes: | |
Coverage Assessment: | |
Target Type: | |
Test Target: | |
Test co-Target(s): | |
Test Prerequisite: | |
Predicate: | |
Prescription: | mandatory |
Reporting: | |
Test Control: |
Test Assertion: | RSP3110a |
---|---|
Description: | Case non-encrypted CS/CSR |
Target: |
|
Predicate: |
|
Reporting: | true=passed, false=failed |
Prescription: | mandatory |
Error Message: | The Body of an RM Sequence LifeCycle message that relates to a secure RM sequence is not included in a Signature. (Case non-encrypted CS/CSR) |
Diagnostic Data: |
|
Test Assertion Part | What it means: |
---|---|
Test Assertion ID: |
[markup: testAssertion/@id] (required) A unique ID for the current test assertion. |
Description: |
[markup: testAssertion/description ] (optional) A plain text description of the current test assertion. At minimum expressing the TA predicate. |
Comments: |
[markup: testAssertion/comments ] (optional) A plain text comment about the TA script and how well it covers the profile requirement. Explanation material for users, and developers (what could be improved, etc.). |
Target: |
[markup: testAssertion/target ] (required) The artifacts to be tested, defined by an XPath expression that returns a list of XML nodes from the log file in input. For every artifact (node) selected by the Target expression, there will be a report entry for this TA in the test report, with a result of either:
See the "reporting" item for the meaning of these results. |
Cotarget: |
[markup: testAssertion/cotarget ] (optional) Artifact that is related to the target, and that needs be accessed for the testing. Identified by an XPath expression that may refer to the related target node using the variable '$target'. For example, the target can be a SOAP message and the cotarget the WSDL file that describes this SOAP message. A cotarget must have a @name attribute that identifies it. The value of this attribute can be used as a variable (when prepending '$' to it) by subsequently defined cotargets, prerequisite and predicate. |
Prerequisite: |
[markup: testAssertion/@preReq ] (optional) [markup: testAssertion/prerequisite ] (optional) The pre-condition for evaluating this Test Assertion on this target. If the prerequisite evaluates to "false" then the target does not qualify for this Test Assertion (the test report is "notRelevant") The first part (preReq attribute) is an enumeration of Test Assertion IDs. Each one of the prerequisite TAs must either use the same target (e.g. SOAP Envelope, or WSDL binding, etc.) as this TA, or a target that is of a more general type than the main TA target. The target must "pass" each one of these prerequisite TAs in order to qualify for this TA. (e.g. the target of TA t1 can be a WSDL binding while the target of a TA t2 prerequisite of t1, can be the entire WSDL file). The second part ("prerequisite" element) is an XPath (boolean) expression of the same nature as the predicate. If present, it must evaluate to "true" for the target to qualify. If it fails, the result for the current TA in the report will be "notRelevant". Otherwise, the target can be further evaluated by the predicate of the main TA. The expression may refer to the target explicitly using the variable name "$target", or to any cotarget using its name as variable name ($[name]). |
Predicate: |
[markup: testAssertion/predicate] required element] A logical expression that evaluates whether this target is fulfilling the profile requirement addressed by this test Assertion. By default: - A result of true means the requirement is fulfilled (reported as a "passed" in the test report).- A result of false means the requirement is violated (reported as a "failed" in the test report). However, in some cases and for testability reasons, the predicate may be designed as a partial indicator e.g. only indicates some cases of fulfillment, or some cases of violation. As a result, when "true" indicates fulfillment it may be that "false" is unconclusive, or conversely "false" will indicate violation, but "true" is unconclusive. In such cases, the "Reporting" element specifies the meaning of the predicate result w/r to the profile requirement. The predicate expression implicitly refers to the target (whic is its "XPath context") although it may explicitly refer to it using the variable name "$target". It may refer to any cotarget using its name as variable name ($[name]). |
Prescription: |
[markup: testAssertion/prescription/@level ] (required) Conveys the level of prescription associated with the profile requirement. At least three values may be used:
|
Reporting: |
[markup: testAssertion/reporting ] (optional) For each possible outcome of the predicate (true or false), specifies how it must be interpreted w/r to the profile feature. Two attributes are used that both must be present, when this element is present:
NOTES: the predicate of the TA may be worded in a negative way so that @false='passed' although that is not recommended. The result of a test should not be related to the prescription level, e.g. a "preferred" or "permitted" level should not imply that @false='warning'. Other test results that are automatically generated and not controlled by the "reporting" element are:
|
Test Assertion Analysis: | RSP3110b |
---|---|
General Notes: | |
Coverage Assessment: | |
Target Type: | |
Test Target: | |
Test co-Target(s): | |
Test Prerequisite: | |
Predicate: | |
Prescription: | mandatory |
Reporting: | |
Test Control: |
Test Assertion: | RSP3110b |
---|---|
Description: | Case encrypted CS/CSR |
Target: |
|
Predicate: |
|
Reporting: | true=passed, false=failed |
Prescription: | mandatory |
Error Message: | The Body of an RM Sequence LifeCycle message that relates to a secure RM sequence is not included in a Signature. (Case encrypted CS/CSR) |
Diagnostic Data: |
|
Test Assertion Part | What it means: |
---|---|
Test Assertion ID: |
[markup: testAssertion/@id] (required) A unique ID for the current test assertion. |
Description: |
[markup: testAssertion/description ] (optional) A plain text description of the current test assertion. At minimum expressing the TA predicate. |
Comments: |
[markup: testAssertion/comments ] (optional) A plain text comment about the TA script and how well it covers the profile requirement. Explanation material for users, and developers (what could be improved, etc.). |
Target: |
[markup: testAssertion/target ] (required) The artifacts to be tested, defined by an XPath expression that returns a list of XML nodes from the log file in input. For every artifact (node) selected by the Target expression, there will be a report entry for this TA in the test report, with a result of either:
See the "reporting" item for the meaning of these results. |
Cotarget: |
[markup: testAssertion/cotarget ] (optional) Artifact that is related to the target, and that needs be accessed for the testing. Identified by an XPath expression that may refer to the related target node using the variable '$target'. For example, the target can be a SOAP message and the cotarget the WSDL file that describes this SOAP message. A cotarget must have a @name attribute that identifies it. The value of this attribute can be used as a variable (when prepending '$' to it) by subsequently defined cotargets, prerequisite and predicate. |
Prerequisite: |
[markup: testAssertion/@preReq ] (optional) [markup: testAssertion/prerequisite ] (optional) The pre-condition for evaluating this Test Assertion on this target. If the prerequisite evaluates to "false" then the target does not qualify for this Test Assertion (the test report is "notRelevant") The first part (preReq attribute) is an enumeration of Test Assertion IDs. Each one of the prerequisite TAs must either use the same target (e.g. SOAP Envelope, or WSDL binding, etc.) as this TA, or a target that is of a more general type than the main TA target. The target must "pass" each one of these prerequisite TAs in order to qualify for this TA. (e.g. the target of TA t1 can be a WSDL binding while the target of a TA t2 prerequisite of t1, can be the entire WSDL file). The second part ("prerequisite" element) is an XPath (boolean) expression of the same nature as the predicate. If present, it must evaluate to "true" for the target to qualify. If it fails, the result for the current TA in the report will be "notRelevant". Otherwise, the target can be further evaluated by the predicate of the main TA. The expression may refer to the target explicitly using the variable name "$target", or to any cotarget using its name as variable name ($[name]). |
Predicate: |
[markup: testAssertion/predicate] required element] A logical expression that evaluates whether this target is fulfilling the profile requirement addressed by this test Assertion. By default: - A result of true means the requirement is fulfilled (reported as a "passed" in the test report).- A result of false means the requirement is violated (reported as a "failed" in the test report). However, in some cases and for testability reasons, the predicate may be designed as a partial indicator e.g. only indicates some cases of fulfillment, or some cases of violation. As a result, when "true" indicates fulfillment it may be that "false" is unconclusive, or conversely "false" will indicate violation, but "true" is unconclusive. In such cases, the "Reporting" element specifies the meaning of the predicate result w/r to the profile requirement. The predicate expression implicitly refers to the target (whic is its "XPath context") although it may explicitly refer to it using the variable name "$target". It may refer to any cotarget using its name as variable name ($[name]). |
Prescription: |
[markup: testAssertion/prescription/@level ] (required) Conveys the level of prescription associated with the profile requirement. At least three values may be used:
|
Reporting: |
[markup: testAssertion/reporting ] (optional) For each possible outcome of the predicate (true or false), specifies how it must be interpreted w/r to the profile feature. Two attributes are used that both must be present, when this element is present:
NOTES: the predicate of the TA may be worded in a negative way so that @false='passed' although that is not recommended. The result of a test should not be related to the prescription level, e.g. a "preferred" or "permitted" level should not imply that @false='warning'. Other test results that are automatically generated and not controlled by the "reporting" element are:
|
R3111 In an ENVELOPE, the signature referred to in R3110 MUST be created using the key(s) associated with the security context, that protects the applicable Sequence.NOT_TESTABLE
R3114 If a wsrm:AckRequested, or wsrm:SequenceAcknowledgement element appears in the header of an ENVELOPE and that element refers to a secure Sequence, that element MUST be included in a signature.TESTABLE RSP3114a RSP3114b
Test Assertion Analysis: | RSP3114a |
---|---|
General Notes: | |
Coverage Assessment: | |
Target Type: | |
Test Target: | |
Test co-Target(s): | |
Test Prerequisite: | |
Predicate: | |
Prescription: | mandatory |
Reporting: | (default) |
Test Control: |
Test Assertion: | RSP3114a |
---|---|
Description: | Case non-encrypted CS/CSR |
Target: |
|
Prerequisite: | RSP3110a |
Predicate: |
|
Reporting: | true=passed, false=failed |
Prescription: | mandatory |
Error Message: | The wsrm:AckRequested header that relates to a secure RM sequence is not included in a Signature. (Case with wsrm:CSR non-encrypted) |
Diagnostic Data: |
|
Test Assertion Part | What it means: |
---|---|
Test Assertion ID: |
[markup: testAssertion/@id] (required) A unique ID for the current test assertion. |
Description: |
[markup: testAssertion/description ] (optional) A plain text description of the current test assertion. At minimum expressing the TA predicate. |
Comments: |
[markup: testAssertion/comments ] (optional) A plain text comment about the TA script and how well it covers the profile requirement. Explanation material for users, and developers (what could be improved, etc.). |
Target: |
[markup: testAssertion/target ] (required) The artifacts to be tested, defined by an XPath expression that returns a list of XML nodes from the log file in input. For every artifact (node) selected by the Target expression, there will be a report entry for this TA in the test report, with a result of either:
See the "reporting" item for the meaning of these results. |
Cotarget: |
[markup: testAssertion/cotarget ] (optional) Artifact that is related to the target, and that needs be accessed for the testing. Identified by an XPath expression that may refer to the related target node using the variable '$target'. For example, the target can be a SOAP message and the cotarget the WSDL file that describes this SOAP message. A cotarget must have a @name attribute that identifies it. The value of this attribute can be used as a variable (when prepending '$' to it) by subsequently defined cotargets, prerequisite and predicate. |
Prerequisite: |
[markup: testAssertion/@preReq ] (optional) [markup: testAssertion/prerequisite ] (optional) The pre-condition for evaluating this Test Assertion on this target. If the prerequisite evaluates to "false" then the target does not qualify for this Test Assertion (the test report is "notRelevant") The first part (preReq attribute) is an enumeration of Test Assertion IDs. Each one of the prerequisite TAs must either use the same target (e.g. SOAP Envelope, or WSDL binding, etc.) as this TA, or a target that is of a more general type than the main TA target. The target must "pass" each one of these prerequisite TAs in order to qualify for this TA. (e.g. the target of TA t1 can be a WSDL binding while the target of a TA t2 prerequisite of t1, can be the entire WSDL file). The second part ("prerequisite" element) is an XPath (boolean) expression of the same nature as the predicate. If present, it must evaluate to "true" for the target to qualify. If it fails, the result for the current TA in the report will be "notRelevant". Otherwise, the target can be further evaluated by the predicate of the main TA. The expression may refer to the target explicitly using the variable name "$target", or to any cotarget using its name as variable name ($[name]). |
Predicate: |
[markup: testAssertion/predicate] required element] A logical expression that evaluates whether this target is fulfilling the profile requirement addressed by this test Assertion. By default: - A result of true means the requirement is fulfilled (reported as a "passed" in the test report).- A result of false means the requirement is violated (reported as a "failed" in the test report). However, in some cases and for testability reasons, the predicate may be designed as a partial indicator e.g. only indicates some cases of fulfillment, or some cases of violation. As a result, when "true" indicates fulfillment it may be that "false" is unconclusive, or conversely "false" will indicate violation, but "true" is unconclusive. In such cases, the "Reporting" element specifies the meaning of the predicate result w/r to the profile requirement. The predicate expression implicitly refers to the target (whic is its "XPath context") although it may explicitly refer to it using the variable name "$target". It may refer to any cotarget using its name as variable name ($[name]). |
Prescription: |
[markup: testAssertion/prescription/@level ] (required) Conveys the level of prescription associated with the profile requirement. At least three values may be used:
|
Reporting: |
[markup: testAssertion/reporting ] (optional) For each possible outcome of the predicate (true or false), specifies how it must be interpreted w/r to the profile feature. Two attributes are used that both must be present, when this element is present:
NOTES: the predicate of the TA may be worded in a negative way so that @false='passed' although that is not recommended. The result of a test should not be related to the prescription level, e.g. a "preferred" or "permitted" level should not imply that @false='warning'. Other test results that are automatically generated and not controlled by the "reporting" element are:
|
Test Assertion Analysis: | RSP3114b |
---|---|
General Notes: | |
Coverage Assessment: | |
Target Type: | |
Test Target: | |
Test co-Target(s): | |
Test Prerequisite: | |
Predicate: | |
Prescription: | mandatory |
Reporting: | (default) |
Test Control: |
Test Assertion: | RSP3114b |
---|---|
Description: | Case encrypted CS/CSR |
Target: |
|
Prerequisite: | RSP3110b |
Predicate: |
|
Reporting: | true=passed, false=failed |
Prescription: | mandatory |
Error Message: | The wsrm:AckRequested header or wsrm:SequenceAcknowledgement element that relates to a secure RM sequence is not included in a Signature (Case with wsrm:CSR encrypted). |
Diagnostic Data: |
|
Test Assertion Part | What it means: |
---|---|
Test Assertion ID: |
[markup: testAssertion/@id] (required) A unique ID for the current test assertion. |
Description: |
[markup: testAssertion/description ] (optional) A plain text description of the current test assertion. At minimum expressing the TA predicate. |
Comments: |
[markup: testAssertion/comments ] (optional) A plain text comment about the TA script and how well it covers the profile requirement. Explanation material for users, and developers (what could be improved, etc.). |
Target: |
[markup: testAssertion/target ] (required) The artifacts to be tested, defined by an XPath expression that returns a list of XML nodes from the log file in input. For every artifact (node) selected by the Target expression, there will be a report entry for this TA in the test report, with a result of either:
See the "reporting" item for the meaning of these results. |
Cotarget: |
[markup: testAssertion/cotarget ] (optional) Artifact that is related to the target, and that needs be accessed for the testing. Identified by an XPath expression that may refer to the related target node using the variable '$target'. For example, the target can be a SOAP message and the cotarget the WSDL file that describes this SOAP message. A cotarget must have a @name attribute that identifies it. The value of this attribute can be used as a variable (when prepending '$' to it) by subsequently defined cotargets, prerequisite and predicate. |
Prerequisite: |
[markup: testAssertion/@preReq ] (optional) [markup: testAssertion/prerequisite ] (optional) The pre-condition for evaluating this Test Assertion on this target. If the prerequisite evaluates to "false" then the target does not qualify for this Test Assertion (the test report is "notRelevant") The first part (preReq attribute) is an enumeration of Test Assertion IDs. Each one of the prerequisite TAs must either use the same target (e.g. SOAP Envelope, or WSDL binding, etc.) as this TA, or a target that is of a more general type than the main TA target. The target must "pass" each one of these prerequisite TAs in order to qualify for this TA. (e.g. the target of TA t1 can be a WSDL binding while the target of a TA t2 prerequisite of t1, can be the entire WSDL file). The second part ("prerequisite" element) is an XPath (boolean) expression of the same nature as the predicate. If present, it must evaluate to "true" for the target to qualify. If it fails, the result for the current TA in the report will be "notRelevant". Otherwise, the target can be further evaluated by the predicate of the main TA. The expression may refer to the target explicitly using the variable name "$target", or to any cotarget using its name as variable name ($[name]). |
Predicate: |
[markup: testAssertion/predicate] required element] A logical expression that evaluates whether this target is fulfilling the profile requirement addressed by this test Assertion. By default: - A result of true means the requirement is fulfilled (reported as a "passed" in the test report).- A result of false means the requirement is violated (reported as a "failed" in the test report). However, in some cases and for testability reasons, the predicate may be designed as a partial indicator e.g. only indicates some cases of fulfillment, or some cases of violation. As a result, when "true" indicates fulfillment it may be that "false" is unconclusive, or conversely "false" will indicate violation, but "true" is unconclusive. In such cases, the "Reporting" element specifies the meaning of the predicate result w/r to the profile requirement. The predicate expression implicitly refers to the target (whic is its "XPath context") although it may explicitly refer to it using the variable name "$target". It may refer to any cotarget using its name as variable name ($[name]). |
Prescription: |
[markup: testAssertion/prescription/@level ] (required) Conveys the level of prescription associated with the profile requirement. At least three values may be used:
|
Reporting: |
[markup: testAssertion/reporting ] (optional) For each possible outcome of the predicate (true or false), specifies how it must be interpreted w/r to the profile feature. Two attributes are used that both must be present, when this element is present:
NOTES: the predicate of the TA may be worded in a negative way so that @false='passed' although that is not recommended. The result of a test should not be related to the prescription level, e.g. a "preferred" or "permitted" level should not imply that @false='warning'. Other test results that are automatically generated and not controlled by the "reporting" element are:
|
R3115 In an ENVELOPE, the signature referred to in R3114 MUST be created using the key(s) associated with the security context that protects the applicable Sequence.NOT_TESTABLE
R3117 When using SOAP 1.2, if a soap12:Fault element appears as the body of an ENVELOPE and the fault relates to a known secure Sequence, the soap12:Body MUST be included in a signature.TESTABLE RSP3117a RSP3117b
Test Assertion Analysis: | RSP3117a |
---|---|
General Notes: | |
Coverage Assessment: | partial (does not cover UnknownSequence Fault) |
Target Type: | ENVELOPE |
Test Target: | Envelope with Soap12 Fault. a SOAP12 fault that has in its detail element wsrm identifier that refers to a known Secured Seq |
Test co-Target(s): | |
Test Prerequisite: | |
Predicate: | like R3110 |
Prescription: | mandatory |
Reporting: | (default) |
Test Control: |
Test Assertion: | RSP3117a |
---|---|
Description: | Case non-encrypted CS/CSR |
Target: |
|
Predicate: |
|
Reporting: | true=passed, false=failed |
Prescription: | mandatory |
Error Message: | The soap12:Fault element that relates to a secure RM sequence, is not included in a Signature. (Case non-encrypted CS/CSR) |
Diagnostic Data: |
|
Test Assertion Part | What it means: |
---|---|
Test Assertion ID: |
[markup: testAssertion/@id] (required) A unique ID for the current test assertion. |
Description: |
[markup: testAssertion/description ] (optional) A plain text description of the current test assertion. At minimum expressing the TA predicate. |
Comments: |
[markup: testAssertion/comments ] (optional) A plain text comment about the TA script and how well it covers the profile requirement. Explanation material for users, and developers (what could be improved, etc.). |
Target: |
[markup: testAssertion/target ] (required) The artifacts to be tested, defined by an XPath expression that returns a list of XML nodes from the log file in input. For every artifact (node) selected by the Target expression, there will be a report entry for this TA in the test report, with a result of either:
See the "reporting" item for the meaning of these results. |
Cotarget: |
[markup: testAssertion/cotarget ] (optional) Artifact that is related to the target, and that needs be accessed for the testing. Identified by an XPath expression that may refer to the related target node using the variable '$target'. For example, the target can be a SOAP message and the cotarget the WSDL file that describes this SOAP message. A cotarget must have a @name attribute that identifies it. The value of this attribute can be used as a variable (when prepending '$' to it) by subsequently defined cotargets, prerequisite and predicate. |
Prerequisite: |
[markup: testAssertion/@preReq ] (optional) [markup: testAssertion/prerequisite ] (optional) The pre-condition for evaluating this Test Assertion on this target. If the prerequisite evaluates to "false" then the target does not qualify for this Test Assertion (the test report is "notRelevant") The first part (preReq attribute) is an enumeration of Test Assertion IDs. Each one of the prerequisite TAs must either use the same target (e.g. SOAP Envelope, or WSDL binding, etc.) as this TA, or a target that is of a more general type than the main TA target. The target must "pass" each one of these prerequisite TAs in order to qualify for this TA. (e.g. the target of TA t1 can be a WSDL binding while the target of a TA t2 prerequisite of t1, can be the entire WSDL file). The second part ("prerequisite" element) is an XPath (boolean) expression of the same nature as the predicate. If present, it must evaluate to "true" for the target to qualify. If it fails, the result for the current TA in the report will be "notRelevant". Otherwise, the target can be further evaluated by the predicate of the main TA. The expression may refer to the target explicitly using the variable name "$target", or to any cotarget using its name as variable name ($[name]). |
Predicate: |
[markup: testAssertion/predicate] required element] A logical expression that evaluates whether this target is fulfilling the profile requirement addressed by this test Assertion. By default: - A result of true means the requirement is fulfilled (reported as a "passed" in the test report).- A result of false means the requirement is violated (reported as a "failed" in the test report). However, in some cases and for testability reasons, the predicate may be designed as a partial indicator e.g. only indicates some cases of fulfillment, or some cases of violation. As a result, when "true" indicates fulfillment it may be that "false" is unconclusive, or conversely "false" will indicate violation, but "true" is unconclusive. In such cases, the "Reporting" element specifies the meaning of the predicate result w/r to the profile requirement. The predicate expression implicitly refers to the target (whic is its "XPath context") although it may explicitly refer to it using the variable name "$target". It may refer to any cotarget using its name as variable name ($[name]). |
Prescription: |
[markup: testAssertion/prescription/@level ] (required) Conveys the level of prescription associated with the profile requirement. At least three values may be used:
|
Reporting: |
[markup: testAssertion/reporting ] (optional) For each possible outcome of the predicate (true or false), specifies how it must be interpreted w/r to the profile feature. Two attributes are used that both must be present, when this element is present:
NOTES: the predicate of the TA may be worded in a negative way so that @false='passed' although that is not recommended. The result of a test should not be related to the prescription level, e.g. a "preferred" or "permitted" level should not imply that @false='warning'. Other test results that are automatically generated and not controlled by the "reporting" element are:
|
Test Assertion Analysis: | RSP3117b |
---|---|
General Notes: | |
Coverage Assessment: | partial (does not cover UnknownSequence Fault) |
Target Type: | ENVELOPE |
Test Target: | Envelope with Soap12 Fault. a SOAP12 fault that has in its detail element wsrm identifier that refers to a known Secured Seq |
Test co-Target(s): | |
Test Prerequisite: | |
Predicate: | like R3110 |
Prescription: | mandatory |
Reporting: | (default) |
Test Control: |
Test Assertion: | RSP3117b |
---|---|
Description: | Case encrypted CS/CSR |
Target: |
|
Predicate: |
|
Reporting: | true=passed, false=failed |
Prescription: | mandatory |
Error Message: | The soap12:Fault element that relates to a secure RM sequence, is not included in a Signature. (Case encrypted CS/CSR) |
Diagnostic Data: |
|
Test Assertion Part | What it means: |
---|---|
Test Assertion ID: |
[markup: testAssertion/@id] (required) A unique ID for the current test assertion. |
Description: |
[markup: testAssertion/description ] (optional) A plain text description of the current test assertion. At minimum expressing the TA predicate. |
Comments: |
[markup: testAssertion/comments ] (optional) A plain text comment about the TA script and how well it covers the profile requirement. Explanation material for users, and developers (what could be improved, etc.). |
Target: |
[markup: testAssertion/target ] (required) The artifacts to be tested, defined by an XPath expression that returns a list of XML nodes from the log file in input. For every artifact (node) selected by the Target expression, there will be a report entry for this TA in the test report, with a result of either:
See the "reporting" item for the meaning of these results. |
Cotarget: |
[markup: testAssertion/cotarget ] (optional) Artifact that is related to the target, and that needs be accessed for the testing. Identified by an XPath expression that may refer to the related target node using the variable '$target'. For example, the target can be a SOAP message and the cotarget the WSDL file that describes this SOAP message. A cotarget must have a @name attribute that identifies it. The value of this attribute can be used as a variable (when prepending '$' to it) by subsequently defined cotargets, prerequisite and predicate. |
Prerequisite: |
[markup: testAssertion/@preReq ] (optional) [markup: testAssertion/prerequisite ] (optional) The pre-condition for evaluating this Test Assertion on this target. If the prerequisite evaluates to "false" then the target does not qualify for this Test Assertion (the test report is "notRelevant") The first part (preReq attribute) is an enumeration of Test Assertion IDs. Each one of the prerequisite TAs must either use the same target (e.g. SOAP Envelope, or WSDL binding, etc.) as this TA, or a target that is of a more general type than the main TA target. The target must "pass" each one of these prerequisite TAs in order to qualify for this TA. (e.g. the target of TA t1 can be a WSDL binding while the target of a TA t2 prerequisite of t1, can be the entire WSDL file). The second part ("prerequisite" element) is an XPath (boolean) expression of the same nature as the predicate. If present, it must evaluate to "true" for the target to qualify. If it fails, the result for the current TA in the report will be "notRelevant". Otherwise, the target can be further evaluated by the predicate of the main TA. The expression may refer to the target explicitly using the variable name "$target", or to any cotarget using its name as variable name ($[name]). |
Predicate: |
[markup: testAssertion/predicate] required element] A logical expression that evaluates whether this target is fulfilling the profile requirement addressed by this test Assertion. By default: - A result of true means the requirement is fulfilled (reported as a "passed" in the test report).- A result of false means the requirement is violated (reported as a "failed" in the test report). However, in some cases and for testability reasons, the predicate may be designed as a partial indicator e.g. only indicates some cases of fulfillment, or some cases of violation. As a result, when "true" indicates fulfillment it may be that "false" is unconclusive, or conversely "false" will indicate violation, but "true" is unconclusive. In such cases, the "Reporting" element specifies the meaning of the predicate result w/r to the profile requirement. The predicate expression implicitly refers to the target (whic is its "XPath context") although it may explicitly refer to it using the variable name "$target". It may refer to any cotarget using its name as variable name ($[name]). |
Prescription: |
[markup: testAssertion/prescription/@level ] (required) Conveys the level of prescription associated with the profile requirement. At least three values may be used:
|
Reporting: |
[markup: testAssertion/reporting ] (optional) For each possible outcome of the predicate (true or false), specifies how it must be interpreted w/r to the profile feature. Two attributes are used that both must be present, when this element is present:
NOTES: the predicate of the TA may be worded in a negative way so that @false='passed' although that is not recommended. The result of a test should not be related to the prescription level, e.g. a "preferred" or "permitted" level should not imply that @false='warning'. Other test results that are automatically generated and not controlled by the "reporting" element are:
|
R3118 In an ENVELOPE, the signature referred to in R3117 MUST be created using the key(s) associated with the security context that protects the applicable Sequence.NOT_TESTABLE
As described in Section 4.1 of WS-ReliableMessaging, the wsrm:SequenceFault element is used to carry the specific details any SOAP 1.1 faults generated during the WS-RM-specific processing of a message. As with SOAP 1.2, the integrity of fault information needs to be protected. In addition to this, it is necessary to ensure that the linkage between a wsrm:SequenceFault header and the soap11:Fault body is preserved.
R3120 When using SOAP 1.1, if a wsrm:SequenceFault appears in the header of an ENVELOPE and the fault relates to a known secure Sequence, the wsrm:SequenceFault header MUST be included in a signature.TESTABLE RSP3120a RSP3120b RSP3120c
Test Assertion Analysis: | RSP3120a |
---|---|
General Notes: | |
Coverage Assessment: | partial (does not cover UnknownSequence Fault) |
Target Type: | ENVELOPE |
Test Target: | Envelope with Soap11 Fault. |
Test co-Target(s): | |
Test Prerequisite: | |
Predicate: | like R3100 |
Prescription: | mandatory |
Reporting: | (default) |
Test Control: |
Test Assertion: | RSP3120a |
---|---|
Description: | Case non encrypted CS/CSR |
Target: |
|
Predicate: |
|
Reporting: | true=passed, false=failed |
Prescription: | mandatory |
Error Message: | The wsrm:SequenceFault element of a SOAP 1.1 envelope is not signed while referring to a secure RM sequence. |
Diagnostic Data: |
|
Test Assertion Part | What it means: |
---|---|
Test Assertion ID: |
[markup: testAssertion/@id] (required) A unique ID for the current test assertion. |
Description: |
[markup: testAssertion/description ] (optional) A plain text description of the current test assertion. At minimum expressing the TA predicate. |
Comments: |
[markup: testAssertion/comments ] (optional) A plain text comment about the TA script and how well it covers the profile requirement. Explanation material for users, and developers (what could be improved, etc.). |
Target: |
[markup: testAssertion/target ] (required) The artifacts to be tested, defined by an XPath expression that returns a list of XML nodes from the log file in input. For every artifact (node) selected by the Target expression, there will be a report entry for this TA in the test report, with a result of either:
See the "reporting" item for the meaning of these results. |
Cotarget: |
[markup: testAssertion/cotarget ] (optional) Artifact that is related to the target, and that needs be accessed for the testing. Identified by an XPath expression that may refer to the related target node using the variable '$target'. For example, the target can be a SOAP message and the cotarget the WSDL file that describes this SOAP message. A cotarget must have a @name attribute that identifies it. The value of this attribute can be used as a variable (when prepending '$' to it) by subsequently defined cotargets, prerequisite and predicate. |
Prerequisite: |
[markup: testAssertion/@preReq ] (optional) [markup: testAssertion/prerequisite ] (optional) The pre-condition for evaluating this Test Assertion on this target. If the prerequisite evaluates to "false" then the target does not qualify for this Test Assertion (the test report is "notRelevant") The first part (preReq attribute) is an enumeration of Test Assertion IDs. Each one of the prerequisite TAs must either use the same target (e.g. SOAP Envelope, or WSDL binding, etc.) as this TA, or a target that is of a more general type than the main TA target. The target must "pass" each one of these prerequisite TAs in order to qualify for this TA. (e.g. the target of TA t1 can be a WSDL binding while the target of a TA t2 prerequisite of t1, can be the entire WSDL file). The second part ("prerequisite" element) is an XPath (boolean) expression of the same nature as the predicate. If present, it must evaluate to "true" for the target to qualify. If it fails, the result for the current TA in the report will be "notRelevant". Otherwise, the target can be further evaluated by the predicate of the main TA. The expression may refer to the target explicitly using the variable name "$target", or to any cotarget using its name as variable name ($[name]). |
Predicate: |
[markup: testAssertion/predicate] required element] A logical expression that evaluates whether this target is fulfilling the profile requirement addressed by this test Assertion. By default: - A result of true means the requirement is fulfilled (reported as a "passed" in the test report).- A result of false means the requirement is violated (reported as a "failed" in the test report). However, in some cases and for testability reasons, the predicate may be designed as a partial indicator e.g. only indicates some cases of fulfillment, or some cases of violation. As a result, when "true" indicates fulfillment it may be that "false" is unconclusive, or conversely "false" will indicate violation, but "true" is unconclusive. In such cases, the "Reporting" element specifies the meaning of the predicate result w/r to the profile requirement. The predicate expression implicitly refers to the target (whic is its "XPath context") although it may explicitly refer to it using the variable name "$target". It may refer to any cotarget using its name as variable name ($[name]). |
Prescription: |
[markup: testAssertion/prescription/@level ] (required) Conveys the level of prescription associated with the profile requirement. At least three values may be used:
|
Reporting: |
[markup: testAssertion/reporting ] (optional) For each possible outcome of the predicate (true or false), specifies how it must be interpreted w/r to the profile feature. Two attributes are used that both must be present, when this element is present:
NOTES: the predicate of the TA may be worded in a negative way so that @false='passed' although that is not recommended. The result of a test should not be related to the prescription level, e.g. a "preferred" or "permitted" level should not imply that @false='warning'. Other test results that are automatically generated and not controlled by the "reporting" element are:
|
Test Assertion Analysis: | RSP3120b |
---|---|
General Notes: | |
Coverage Assessment: | partial (does not cover UnknownSequence Fault) |
Target Type: | ENVELOPE |
Test Target: | Envelope with Soap11 Fault. |
Test co-Target(s): | |
Test Prerequisite: | |
Predicate: | like R3100 |
Prescription: | mandatory |
Reporting: | (default) |
Test Control: |
Test Assertion: | RSP3120b |
---|---|
Description: | Case encrypted CS/CSR |
Target: |
|
Predicate: |
|
Reporting: | true=passed, false=failed |
Prescription: | mandatory |
Error Message: | The wsrm:SequenceFault element of a SOAP 1.1 envelope is not signed while referring to a secure RM sequence. |
Diagnostic Data: |
|
Test Assertion Part | What it means: |
---|---|
Test Assertion ID: |
[markup: testAssertion/@id] (required) A unique ID for the current test assertion. |
Description: |
[markup: testAssertion/description ] (optional) A plain text description of the current test assertion. At minimum expressing the TA predicate. |
Comments: |
[markup: testAssertion/comments ] (optional) A plain text comment about the TA script and how well it covers the profile requirement. Explanation material for users, and developers (what could be improved, etc.). |
Target: |
[markup: testAssertion/target ] (required) The artifacts to be tested, defined by an XPath expression that returns a list of XML nodes from the log file in input. For every artifact (node) selected by the Target expression, there will be a report entry for this TA in the test report, with a result of either:
See the "reporting" item for the meaning of these results. |
Cotarget: |
[markup: testAssertion/cotarget ] (optional) Artifact that is related to the target, and that needs be accessed for the testing. Identified by an XPath expression that may refer to the related target node using the variable '$target'. For example, the target can be a SOAP message and the cotarget the WSDL file that describes this SOAP message. A cotarget must have a @name attribute that identifies it. The value of this attribute can be used as a variable (when prepending '$' to it) by subsequently defined cotargets, prerequisite and predicate. |
Prerequisite: |
[markup: testAssertion/@preReq ] (optional) [markup: testAssertion/prerequisite ] (optional) The pre-condition for evaluating this Test Assertion on this target. If the prerequisite evaluates to "false" then the target does not qualify for this Test Assertion (the test report is "notRelevant") The first part (preReq attribute) is an enumeration of Test Assertion IDs. Each one of the prerequisite TAs must either use the same target (e.g. SOAP Envelope, or WSDL binding, etc.) as this TA, or a target that is of a more general type than the main TA target. The target must "pass" each one of these prerequisite TAs in order to qualify for this TA. (e.g. the target of TA t1 can be a WSDL binding while the target of a TA t2 prerequisite of t1, can be the entire WSDL file). The second part ("prerequisite" element) is an XPath (boolean) expression of the same nature as the predicate. If present, it must evaluate to "true" for the target to qualify. If it fails, the result for the current TA in the report will be "notRelevant". Otherwise, the target can be further evaluated by the predicate of the main TA. The expression may refer to the target explicitly using the variable name "$target", or to any cotarget using its name as variable name ($[name]). |
Predicate: |
[markup: testAssertion/predicate] required element] A logical expression that evaluates whether this target is fulfilling the profile requirement addressed by this test Assertion. By default: - A result of true means the requirement is fulfilled (reported as a "passed" in the test report).- A result of false means the requirement is violated (reported as a "failed" in the test report). However, in some cases and for testability reasons, the predicate may be designed as a partial indicator e.g. only indicates some cases of fulfillment, or some cases of violation. As a result, when "true" indicates fulfillment it may be that "false" is unconclusive, or conversely "false" will indicate violation, but "true" is unconclusive. In such cases, the "Reporting" element specifies the meaning of the predicate result w/r to the profile requirement. The predicate expression implicitly refers to the target (whic is its "XPath context") although it may explicitly refer to it using the variable name "$target". It may refer to any cotarget using its name as variable name ($[name]). |
Prescription: |
[markup: testAssertion/prescription/@level ] (required) Conveys the level of prescription associated with the profile requirement. At least three values may be used:
|
Reporting: |
[markup: testAssertion/reporting ] (optional) For each possible outcome of the predicate (true or false), specifies how it must be interpreted w/r to the profile feature. Two attributes are used that both must be present, when this element is present:
NOTES: the predicate of the TA may be worded in a negative way so that @false='passed' although that is not recommended. The result of a test should not be related to the prescription level, e.g. a "preferred" or "permitted" level should not imply that @false='warning'. Other test results that are automatically generated and not controlled by the "reporting" element are:
|
Test Assertion Analysis: | RSP3120c |
---|---|
General Notes: | |
Coverage Assessment: | partial (does not cover UnknownSequence Fault) |
Target Type: | ENVELOPE |
Test Target: | Envelope with Soap11 Fault. |
Test co-Target(s): | |
Test Prerequisite: | |
Predicate: | like R3100 |
Prescription: | mandatory |
Reporting: | (default) |
Test Control: |
Test Assertion: | RSP3120c |
---|---|
Description: | Case where CS itself is faulted |
Target: |
|
Predicate: |
|
Reporting: | true=passed, false=failed |
Prescription: | mandatory |
Error Message: | The wsrm:SequenceFault element of a SOAP 1.1 envelope is not signed while referring to a secure RM sequence. |
Diagnostic Data: |
|
Test Assertion Part | What it means: |
---|---|
Test Assertion ID: |
[markup: testAssertion/@id] (required) A unique ID for the current test assertion. |
Description: |
[markup: testAssertion/description ] (optional) A plain text description of the current test assertion. At minimum expressing the TA predicate. |
Comments: |
[markup: testAssertion/comments ] (optional) A plain text comment about the TA script and how well it covers the profile requirement. Explanation material for users, and developers (what could be improved, etc.). |
Target: |
[markup: testAssertion/target ] (required) The artifacts to be tested, defined by an XPath expression that returns a list of XML nodes from the log file in input. For every artifact (node) selected by the Target expression, there will be a report entry for this TA in the test report, with a result of either:
See the "reporting" item for the meaning of these results. |
Cotarget: |
[markup: testAssertion/cotarget ] (optional) Artifact that is related to the target, and that needs be accessed for the testing. Identified by an XPath expression that may refer to the related target node using the variable '$target'. For example, the target can be a SOAP message and the cotarget the WSDL file that describes this SOAP message. A cotarget must have a @name attribute that identifies it. The value of this attribute can be used as a variable (when prepending '$' to it) by subsequently defined cotargets, prerequisite and predicate. |
Prerequisite: |
[markup: testAssertion/@preReq ] (optional) [markup: testAssertion/prerequisite ] (optional) The pre-condition for evaluating this Test Assertion on this target. If the prerequisite evaluates to "false" then the target does not qualify for this Test Assertion (the test report is "notRelevant") The first part (preReq attribute) is an enumeration of Test Assertion IDs. Each one of the prerequisite TAs must either use the same target (e.g. SOAP Envelope, or WSDL binding, etc.) as this TA, or a target that is of a more general type than the main TA target. The target must "pass" each one of these prerequisite TAs in order to qualify for this TA. (e.g. the target of TA t1 can be a WSDL binding while the target of a TA t2 prerequisite of t1, can be the entire WSDL file). The second part ("prerequisite" element) is an XPath (boolean) expression of the same nature as the predicate. If present, it must evaluate to "true" for the target to qualify. If it fails, the result for the current TA in the report will be "notRelevant". Otherwise, the target can be further evaluated by the predicate of the main TA. The expression may refer to the target explicitly using the variable name "$target", or to any cotarget using its name as variable name ($[name]). |
Predicate: |
[markup: testAssertion/predicate] required element] A logical expression that evaluates whether this target is fulfilling the profile requirement addressed by this test Assertion. By default: - A result of true means the requirement is fulfilled (reported as a "passed" in the test report).- A result of false means the requirement is violated (reported as a "failed" in the test report). However, in some cases and for testability reasons, the predicate may be designed as a partial indicator e.g. only indicates some cases of fulfillment, or some cases of violation. As a result, when "true" indicates fulfillment it may be that "false" is unconclusive, or conversely "false" will indicate violation, but "true" is unconclusive. In such cases, the "Reporting" element specifies the meaning of the predicate result w/r to the profile requirement. The predicate expression implicitly refers to the target (whic is its "XPath context") although it may explicitly refer to it using the variable name "$target". It may refer to any cotarget using its name as variable name ($[name]). |
Prescription: |
[markup: testAssertion/prescription/@level ] (required) Conveys the level of prescription associated with the profile requirement. At least three values may be used:
|
Reporting: |
[markup: testAssertion/reporting ] (optional) For each possible outcome of the predicate (true or false), specifies how it must be interpreted w/r to the profile feature. Two attributes are used that both must be present, when this element is present:
NOTES: the predicate of the TA may be worded in a negative way so that @false='passed' although that is not recommended. The result of a test should not be related to the prescription level, e.g. a "preferred" or "permitted" level should not imply that @false='warning'. Other test results that are automatically generated and not controlled by the "reporting" element are:
|
R3121 In an ENVELOPE, the signature referred to in R3120 MUST be coupled cryptographically (e.g. share a common signature) with the message body.TESTABLE RSP3121a RSP3121b
Test Assertion Analysis: | RSP3121a |
---|---|
General Notes: | |
Coverage Assessment: | partial (does not cover UnknownSequence Fault) |
Target Type: | ENVELOPE |
Test Target: | Envelope with Soap11 Fault. a SOAP11 fault that has in its detail element wsrm identifier that refers to a known Secured Seq |
Test co-Target(s): | |
Test Prerequisite: | |
Predicate: | |
Prescription: | mandatory |
Reporting: | (default) |
Test Control: |
Test Assertion: | RSP3121a |
---|---|
Description: | Case non-encrypted CS/CSR |
Target: |
|
Prerequisite: | RSP3120a |
Predicate: |
|
Reporting: | true=passed, false=failed |
Prescription: | mandatory |
Error Message: | The Body of a SOAP 1.1 message with signed wsrm:SequenceFault element is not covered by the same signature while referring to a secure RM sequence. |
Diagnostic Data: |
|
Test Assertion Part | What it means: |
---|---|
Test Assertion ID: |
[markup: testAssertion/@id] (required) A unique ID for the current test assertion. |
Description: |
[markup: testAssertion/description ] (optional) A plain text description of the current test assertion. At minimum expressing the TA predicate. |
Comments: |
[markup: testAssertion/comments ] (optional) A plain text comment about the TA script and how well it covers the profile requirement. Explanation material for users, and developers (what could be improved, etc.). |
Target: |
[markup: testAssertion/target ] (required) The artifacts to be tested, defined by an XPath expression that returns a list of XML nodes from the log file in input. For every artifact (node) selected by the Target expression, there will be a report entry for this TA in the test report, with a result of either:
See the "reporting" item for the meaning of these results. |
Cotarget: |
[markup: testAssertion/cotarget ] (optional) Artifact that is related to the target, and that needs be accessed for the testing. Identified by an XPath expression that may refer to the related target node using the variable '$target'. For example, the target can be a SOAP message and the cotarget the WSDL file that describes this SOAP message. A cotarget must have a @name attribute that identifies it. The value of this attribute can be used as a variable (when prepending '$' to it) by subsequently defined cotargets, prerequisite and predicate. |
Prerequisite: |
[markup: testAssertion/@preReq ] (optional) [markup: testAssertion/prerequisite ] (optional) The pre-condition for evaluating this Test Assertion on this target. If the prerequisite evaluates to "false" then the target does not qualify for this Test Assertion (the test report is "notRelevant") The first part (preReq attribute) is an enumeration of Test Assertion IDs. Each one of the prerequisite TAs must either use the same target (e.g. SOAP Envelope, or WSDL binding, etc.) as this TA, or a target that is of a more general type than the main TA target. The target must "pass" each one of these prerequisite TAs in order to qualify for this TA. (e.g. the target of TA t1 can be a WSDL binding while the target of a TA t2 prerequisite of t1, can be the entire WSDL file). The second part ("prerequisite" element) is an XPath (boolean) expression of the same nature as the predicate. If present, it must evaluate to "true" for the target to qualify. If it fails, the result for the current TA in the report will be "notRelevant". Otherwise, the target can be further evaluated by the predicate of the main TA. The expression may refer to the target explicitly using the variable name "$target", or to any cotarget using its name as variable name ($[name]). |
Predicate: |
[markup: testAssertion/predicate] required element] A logical expression that evaluates whether this target is fulfilling the profile requirement addressed by this test Assertion. By default: - A result of true means the requirement is fulfilled (reported as a "passed" in the test report).- A result of false means the requirement is violated (reported as a "failed" in the test report). However, in some cases and for testability reasons, the predicate may be designed as a partial indicator e.g. only indicates some cases of fulfillment, or some cases of violation. As a result, when "true" indicates fulfillment it may be that "false" is unconclusive, or conversely "false" will indicate violation, but "true" is unconclusive. In such cases, the "Reporting" element specifies the meaning of the predicate result w/r to the profile requirement. The predicate expression implicitly refers to the target (whic is its "XPath context") although it may explicitly refer to it using the variable name "$target". It may refer to any cotarget using its name as variable name ($[name]). |
Prescription: |
[markup: testAssertion/prescription/@level ] (required) Conveys the level of prescription associated with the profile requirement. At least three values may be used:
|
Reporting: |
[markup: testAssertion/reporting ] (optional) For each possible outcome of the predicate (true or false), specifies how it must be interpreted w/r to the profile feature. Two attributes are used that both must be present, when this element is present:
NOTES: the predicate of the TA may be worded in a negative way so that @false='passed' although that is not recommended. The result of a test should not be related to the prescription level, e.g. a "preferred" or "permitted" level should not imply that @false='warning'. Other test results that are automatically generated and not controlled by the "reporting" element are:
|
Test Assertion Analysis: | RSP3121b |
---|---|
General Notes: | |
Coverage Assessment: | partial (does not cover UnknownSequence Fault) |
Target Type: | ENVELOPE |
Test Target: | Envelope with Soap11 Fault. a SOAP11 fault that has in its detail element wsrm identifier that refers to a known Secured Seq |
Test co-Target(s): | |
Test Prerequisite: | |
Predicate: | |
Prescription: | mandatory |
Reporting: | (default) |
Test Control: |
Test Assertion: | RSP3121b |
---|---|
Description: | Case encrypted CS/CSR |
Target: |
|
Prerequisite: | RSP3120b |
Predicate: |
|
Reporting: | true=passed, false=failed |
Prescription: | mandatory |
Error Message: | The Body of a SOAP 1.1 message with signed wsrm:SequenceFault element is not covered by the same signature while referring to a secure RM sequence. |
Diagnostic Data: |
|
Test Assertion Part | What it means: |
---|---|
Test Assertion ID: |
[markup: testAssertion/@id] (required) A unique ID for the current test assertion. |
Description: |
[markup: testAssertion/description ] (optional) A plain text description of the current test assertion. At minimum expressing the TA predicate. |
Comments: |
[markup: testAssertion/comments ] (optional) A plain text comment about the TA script and how well it covers the profile requirement. Explanation material for users, and developers (what could be improved, etc.). |
Target: |
[markup: testAssertion/target ] (required) The artifacts to be tested, defined by an XPath expression that returns a list of XML nodes from the log file in input. For every artifact (node) selected by the Target expression, there will be a report entry for this TA in the test report, with a result of either:
See the "reporting" item for the meaning of these results. |
Cotarget: |
[markup: testAssertion/cotarget ] (optional) Artifact that is related to the target, and that needs be accessed for the testing. Identified by an XPath expression that may refer to the related target node using the variable '$target'. For example, the target can be a SOAP message and the cotarget the WSDL file that describes this SOAP message. A cotarget must have a @name attribute that identifies it. The value of this attribute can be used as a variable (when prepending '$' to it) by subsequently defined cotargets, prerequisite and predicate. |
Prerequisite: |
[markup: testAssertion/@preReq ] (optional) [markup: testAssertion/prerequisite ] (optional) The pre-condition for evaluating this Test Assertion on this target. If the prerequisite evaluates to "false" then the target does not qualify for this Test Assertion (the test report is "notRelevant") The first part (preReq attribute) is an enumeration of Test Assertion IDs. Each one of the prerequisite TAs must either use the same target (e.g. SOAP Envelope, or WSDL binding, etc.) as this TA, or a target that is of a more general type than the main TA target. The target must "pass" each one of these prerequisite TAs in order to qualify for this TA. (e.g. the target of TA t1 can be a WSDL binding while the target of a TA t2 prerequisite of t1, can be the entire WSDL file). The second part ("prerequisite" element) is an XPath (boolean) expression of the same nature as the predicate. If present, it must evaluate to "true" for the target to qualify. If it fails, the result for the current TA in the report will be "notRelevant". Otherwise, the target can be further evaluated by the predicate of the main TA. The expression may refer to the target explicitly using the variable name "$target", or to any cotarget using its name as variable name ($[name]). |
Predicate: |
[markup: testAssertion/predicate] required element] A logical expression that evaluates whether this target is fulfilling the profile requirement addressed by this test Assertion. By default: - A result of true means the requirement is fulfilled (reported as a "passed" in the test report).- A result of false means the requirement is violated (reported as a "failed" in the test report). However, in some cases and for testability reasons, the predicate may be designed as a partial indicator e.g. only indicates some cases of fulfillment, or some cases of violation. As a result, when "true" indicates fulfillment it may be that "false" is unconclusive, or conversely "false" will indicate violation, but "true" is unconclusive. In such cases, the "Reporting" element specifies the meaning of the predicate result w/r to the profile requirement. The predicate expression implicitly refers to the target (whic is its "XPath context") although it may explicitly refer to it using the variable name "$target". It may refer to any cotarget using its name as variable name ($[name]). |
Prescription: |
[markup: testAssertion/prescription/@level ] (required) Conveys the level of prescription associated with the profile requirement. At least three values may be used:
|
Reporting: |
[markup: testAssertion/reporting ] (optional) For each possible outcome of the predicate (true or false), specifies how it must be interpreted w/r to the profile feature. Two attributes are used that both must be present, when this element is present:
NOTES: the predicate of the TA may be worded in a negative way so that @false='passed' although that is not recommended. The result of a test should not be related to the prescription level, e.g. a "preferred" or "permitted" level should not imply that @false='warning'. Other test results that are automatically generated and not controlled by the "reporting" element are:
|
R3122 In an ENVELOPE, the signature referred to in R3120 MUST be created using the key(s) associated with the security context that protects the applicable Sequence.NOT_TESTABLE
This Profile places additional requirements on the composition of MakeConnection, WS-SecureConversation, and WS-ReliableMessaging.
From a security standpoint, it will be commonly desired that the security context of the message sent on the backchannel established by a MakeConnection and that of the MakeConnection message itself be the same. However, it is important to keep in mind that the WS-MakeConnection protocol is independent of the application protocol(s) flowing over it, thus there will be cases in which the MC-SENDER has no knowledge of the security context (if any) of the backchannel messages. For example, the WS-MakeConnection specification details a scenario in which MakeConnection is used to deliver Notifications from an Event Source. The Event Source may have a variety of different security contexts that it uses depending on the type of Notification being delivered. In this case the MC-SENDER has no way of knowing which security context, if any, should to be used. In such situations, the MC-RECEIVER needs to simply ensure that the MC-SENDER is authenticated. It would still be the MC-SENDER's responsibility to ensure that any message sent on the backchannel has the correct security context - just as would any endpoint receiving a message over a new connection.
Since the value of the wsmc:MessagePending header effects the operation of the MakeConnection protocol, it must be protected to ensure the proper functioning of that protocol.
R3201 If a wsmc:MessagePending element appears as a header block in an ENVELOPE, that element MUST be signed using the key(s) associated with a security context, if any, that protects the SOAP Body of the ENVELOPE.TESTABLE RSP3201
Test Assertion Analysis: | RSP3201 |
---|---|
General Notes: | |
Coverage Assessment: | |
Target Type: | ENVELOPE |
Test Target: | Env contains MessagePending header AND whose Body is being signed (relates to Secured RM Seq) |
Test co-Target(s): | |
Test Prerequisite: | |
Predicate: | (a) is signed, (b) signature covers both the header block and the Body. The [target]'s security Header that indicates the Body is signed also includes a reference to the wsu:Id of the MessagePending Header |
Prescription: | mandatory |
Reporting: | (default) |
Test Control: | Run some secure request/response tests where there are several request messages being processed at the same time (ie. they are not serialized). Also, set the wsa:ReplyTo of the request messages (from a non-addressable endpoint) to an instance of the MC Anonymous URI Template. |
Test Assertion: | RSP3201 |
---|---|
Description: | |
Target: |
|
Predicate: |
|
Reporting: | true=passed, false=failed |
Prescription: | mandatory |
Error Message: | The wsmc:MessagePending header block is not signed with same signature as the Soap Body (based on @wsu:Id references). |
Diagnostic Data: |
|
Test Assertion Part | What it means: |
---|---|
Test Assertion ID: |
[markup: testAssertion/@id] (required) A unique ID for the current test assertion. |
Description: |
[markup: testAssertion/description ] (optional) A plain text description of the current test assertion. At minimum expressing the TA predicate. |
Comments: |
[markup: testAssertion/comments ] (optional) A plain text comment about the TA script and how well it covers the profile requirement. Explanation material for users, and developers (what could be improved, etc.). |
Target: |
[markup: testAssertion/target ] (required) The artifacts to be tested, defined by an XPath expression that returns a list of XML nodes from the log file in input. For every artifact (node) selected by the Target expression, there will be a report entry for this TA in the test report, with a result of either:
See the "reporting" item for the meaning of these results. |
Cotarget: |
[markup: testAssertion/cotarget ] (optional) Artifact that is related to the target, and that needs be accessed for the testing. Identified by an XPath expression that may refer to the related target node using the variable '$target'. For example, the target can be a SOAP message and the cotarget the WSDL file that describes this SOAP message. A cotarget must have a @name attribute that identifies it. The value of this attribute can be used as a variable (when prepending '$' to it) by subsequently defined cotargets, prerequisite and predicate. |
Prerequisite: |
[markup: testAssertion/@preReq ] (optional) [markup: testAssertion/prerequisite ] (optional) The pre-condition for evaluating this Test Assertion on this target. If the prerequisite evaluates to "false" then the target does not qualify for this Test Assertion (the test report is "notRelevant") The first part (preReq attribute) is an enumeration of Test Assertion IDs. Each one of the prerequisite TAs must either use the same target (e.g. SOAP Envelope, or WSDL binding, etc.) as this TA, or a target that is of a more general type than the main TA target. The target must "pass" each one of these prerequisite TAs in order to qualify for this TA. (e.g. the target of TA t1 can be a WSDL binding while the target of a TA t2 prerequisite of t1, can be the entire WSDL file). The second part ("prerequisite" element) is an XPath (boolean) expression of the same nature as the predicate. If present, it must evaluate to "true" for the target to qualify. If it fails, the result for the current TA in the report will be "notRelevant". Otherwise, the target can be further evaluated by the predicate of the main TA. The expression may refer to the target explicitly using the variable name "$target", or to any cotarget using its name as variable name ($[name]). |
Predicate: |
[markup: testAssertion/predicate] required element] A logical expression that evaluates whether this target is fulfilling the profile requirement addressed by this test Assertion. By default: - A result of true means the requirement is fulfilled (reported as a "passed" in the test report).- A result of false means the requirement is violated (reported as a "failed" in the test report). However, in some cases and for testability reasons, the predicate may be designed as a partial indicator e.g. only indicates some cases of fulfillment, or some cases of violation. As a result, when "true" indicates fulfillment it may be that "false" is unconclusive, or conversely "false" will indicate violation, but "true" is unconclusive. In such cases, the "Reporting" element specifies the meaning of the predicate result w/r to the profile requirement. The predicate expression implicitly refers to the target (whic is its "XPath context") although it may explicitly refer to it using the variable name "$target". It may refer to any cotarget using its name as variable name ($[name]). |
Prescription: |
[markup: testAssertion/prescription/@level ] (required) Conveys the level of prescription associated with the profile requirement. At least three values may be used:
|
Reporting: |
[markup: testAssertion/reporting ] (optional) For each possible outcome of the predicate (true or false), specifies how it must be interpreted w/r to the profile feature. Two attributes are used that both must be present, when this element is present:
NOTES: the predicate of the TA may be worded in a negative way so that @false='passed' although that is not recommended. The result of a test should not be related to the prescription level, e.g. a "preferred" or "permitted" level should not imply that @false='warning'. Other test results that are automatically generated and not controlled by the "reporting" element are:
|
As mentioned in Section 5 of WS-ReliableMessaging, there is a potential tension between certain aspects of security and reliable messaging; a security implementation may attempt to detect and prevent message replay attacks, but one of the invariants of the WS-RM protocol is to resend messages until they are acknowledged. Implementations must have the information necessary to distinguish between a valid retransmission of an unacknowledged message and a replayed message.
R3300 In the absence of WS-SecurityPolicy assertions that indicate otherwise, an ENVELOPE in a secure Sequence that contains a wsrm:Sequence header MUST contain a wsu:Timestamp as a sub-element of the wsse:Security header.TESTABLE RSP3300
Test Assertion Analysis: | RSP3300 |
---|---|
General Notes: | |
Coverage Assessment: | Good (should be able to cover all cases) |
Target Type: | ENVELOPE |
Test Target: | A SOAP Envelope that belongs to a Secure Sequence, i.e. with a wsrm:Sequence/wsrm:Identifier element that match the wsrm:CreateSequenceResponse/wsrm:Identifier that is response of a wsrm:CreateSequence element extended with a wsse:SecurityTokenReference element. |
Test co-Target(s): | |
Test Prerequisite: | |
Predicate: | The SOAP Envelope contains a wsse:Security header that has a wsu:Timestamp child element. |
Prescription: | mandatory |
Reporting: | true=passed, false=failed |
Test Control: | No WS-SecurityPolicy assertions will be deployed or published. Initiate a Secure Sequence (wsrm:CreateSequence element has been extended with a wsse:SecurityTokenReference element). Then RMS is sending messages over this sequence. |
Test Assertion: | RSP3300 |
---|---|
Description: | |
Target: |
|
co-Target: mycreateseq |
|
Prerequisite: |
|
Predicate: |
|
Reporting: | true=passed, false=warning |
Prescription: | mandatory |
Error Message: | A SOAP Envelope that belongs to a Secure Sequence does not contain a wsse:Security header that has a wsu:Timestamp child element. |
Diagnostic Data: |
|
Test Assertion Part | What it means: |
---|---|
Test Assertion ID: |
[markup: testAssertion/@id] (required) A unique ID for the current test assertion. |
Description: |
[markup: testAssertion/description ] (optional) A plain text description of the current test assertion. At minimum expressing the TA predicate. |
Comments: |
[markup: testAssertion/comments ] (optional) A plain text comment about the TA script and how well it covers the profile requirement. Explanation material for users, and developers (what could be improved, etc.). |
Target: |
[markup: testAssertion/target ] (required) The artifacts to be tested, defined by an XPath expression that returns a list of XML nodes from the log file in input. For every artifact (node) selected by the Target expression, there will be a report entry for this TA in the test report, with a result of either:
See the "reporting" item for the meaning of these results. |
Cotarget: |
[markup: testAssertion/cotarget ] (optional) Artifact that is related to the target, and that needs be accessed for the testing. Identified by an XPath expression that may refer to the related target node using the variable '$target'. For example, the target can be a SOAP message and the cotarget the WSDL file that describes this SOAP message. A cotarget must have a @name attribute that identifies it. The value of this attribute can be used as a variable (when prepending '$' to it) by subsequently defined cotargets, prerequisite and predicate. |
Prerequisite: |
[markup: testAssertion/@preReq ] (optional) [markup: testAssertion/prerequisite ] (optional) The pre-condition for evaluating this Test Assertion on this target. If the prerequisite evaluates to "false" then the target does not qualify for this Test Assertion (the test report is "notRelevant") The first part (preReq attribute) is an enumeration of Test Assertion IDs. Each one of the prerequisite TAs must either use the same target (e.g. SOAP Envelope, or WSDL binding, etc.) as this TA, or a target that is of a more general type than the main TA target. The target must "pass" each one of these prerequisite TAs in order to qualify for this TA. (e.g. the target of TA t1 can be a WSDL binding while the target of a TA t2 prerequisite of t1, can be the entire WSDL file). The second part ("prerequisite" element) is an XPath (boolean) expression of the same nature as the predicate. If present, it must evaluate to "true" for the target to qualify. If it fails, the result for the current TA in the report will be "notRelevant". Otherwise, the target can be further evaluated by the predicate of the main TA. The expression may refer to the target explicitly using the variable name "$target", or to any cotarget using its name as variable name ($[name]). |
Predicate: |
[markup: testAssertion/predicate] required element] A logical expression that evaluates whether this target is fulfilling the profile requirement addressed by this test Assertion. By default: - A result of true means the requirement is fulfilled (reported as a "passed" in the test report).- A result of false means the requirement is violated (reported as a "failed" in the test report). However, in some cases and for testability reasons, the predicate may be designed as a partial indicator e.g. only indicates some cases of fulfillment, or some cases of violation. As a result, when "true" indicates fulfillment it may be that "false" is unconclusive, or conversely "false" will indicate violation, but "true" is unconclusive. In such cases, the "Reporting" element specifies the meaning of the predicate result w/r to the profile requirement. The predicate expression implicitly refers to the target (whic is its "XPath context") although it may explicitly refer to it using the variable name "$target". It may refer to any cotarget using its name as variable name ($[name]). |
Prescription: |
[markup: testAssertion/prescription/@level ] (required) Conveys the level of prescription associated with the profile requirement. At least three values may be used:
|
Reporting: |
[markup: testAssertion/reporting ] (optional) For each possible outcome of the predicate (true or false), specifies how it must be interpreted w/r to the profile feature. Two attributes are used that both must be present, when this element is present:
NOTES: the predicate of the TA may be worded in a negative way so that @false='passed' although that is not recommended. The result of a test should not be related to the prescription level, e.g. a "preferred" or "permitted" level should not imply that @false='warning'. Other test results that are automatically generated and not controlled by the "reporting" element are:
|
R3301 For any two ENVELOPEs in a particular secure Sequence that contain WS-RM Sequence headers in which the value of their wsrm:MessageNumber elements are equal, it MUST be true that neither of the envelopes contains a wsu:Timestamp as a child element of wsse:Security header, OR that both messages contain a wsu:Timestamp as child elements of their wsse:Security headers and the value of these wsu:Timestamp elements are NOT equal.TESTABLE RSP3301
Test Assertion Analysis: | RSP3301 |
---|---|
General Notes: | This is a more general situation than R3300: a WS-SecurityPolicy assertions may or may not be deployed, that controls the presence of wsu:Timestamp. Although the Rxxxx is considering a pair of Envelopes, the test target (and predicate) focus on a single one at a time. |
Coverage Assessment: | Good (should be able to cover all cases) |
Target Type: | ENVELOPE |
Test Target: | A SOAP Envelope that belongs to a Secure Sequence, (see the filter condition in R3300 for this) |
Test co-Target(s): | |
Test Prerequisite: | |
Predicate: | if the SOAP Envelope contains a wsse:Security/wsu:Timestamp child element, then any previous RM retry SOAP Envelope (same wsrm:Sequence/wsrm:Identifier and same wsrm:Sequence/wsrm:MessageNumber) has a different wsse:Security/wsu:Timestamp, else any previous RM retry SOAP Envelope does NOT have wsu:Timestamp under wsse:Security |
Prescription: | mandatory |
Reporting: | true=passed, false=failed |
Test Control: | Initiate a Secure Sequence (wsrm:CreateSequence element has been extended with a wsse:SecurityTokenReference element). Then RMS is sending messages over this sequence. Manage to cause message resending (block Acks, or set the retry period shorter than the Ack period.) |
Test Assertion: | RSP3301 |
---|---|
Description: | |
Target: |
|
co-Target: mycreateseq |
|
Predicate: |
|
Reporting: | true=passed, false=failed |
Prescription: | mandatory |
Error Message: | Either a SOAP Envelope that belongs to a Secure RM Sequence contains a wsse:Security/wsu:Timestamp child element, but a previous RM retry SOAP Envelope (same wsrm:Sequence/wsrm:Identifier and same wsrm:Sequence/wsrm:MessageNumber) has a same wsse:Security/wsu:Timestamp value, or the SOAP Envelope does not contain a wsse:Security/wsu:Timestamp and yet some previous RM retry SOAP Envelope does contain a wsu:Timestamp. |
Diagnostic Data: |
|
Test Assertion Part | What it means: |
---|---|
Test Assertion ID: |
[markup: testAssertion/@id] (required) A unique ID for the current test assertion. |
Description: |
[markup: testAssertion/description ] (optional) A plain text description of the current test assertion. At minimum expressing the TA predicate. |
Comments: |
[markup: testAssertion/comments ] (optional) A plain text comment about the TA script and how well it covers the profile requirement. Explanation material for users, and developers (what could be improved, etc.). |
Target: |
[markup: testAssertion/target ] (required) The artifacts to be tested, defined by an XPath expression that returns a list of XML nodes from the log file in input. For every artifact (node) selected by the Target expression, there will be a report entry for this TA in the test report, with a result of either:
See the "reporting" item for the meaning of these results. |
Cotarget: |
[markup: testAssertion/cotarget ] (optional) Artifact that is related to the target, and that needs be accessed for the testing. Identified by an XPath expression that may refer to the related target node using the variable '$target'. For example, the target can be a SOAP message and the cotarget the WSDL file that describes this SOAP message. A cotarget must have a @name attribute that identifies it. The value of this attribute can be used as a variable (when prepending '$' to it) by subsequently defined cotargets, prerequisite and predicate. |
Prerequisite: |
[markup: testAssertion/@preReq ] (optional) [markup: testAssertion/prerequisite ] (optional) The pre-condition for evaluating this Test Assertion on this target. If the prerequisite evaluates to "false" then the target does not qualify for this Test Assertion (the test report is "notRelevant") The first part (preReq attribute) is an enumeration of Test Assertion IDs. Each one of the prerequisite TAs must either use the same target (e.g. SOAP Envelope, or WSDL binding, etc.) as this TA, or a target that is of a more general type than the main TA target. The target must "pass" each one of these prerequisite TAs in order to qualify for this TA. (e.g. the target of TA t1 can be a WSDL binding while the target of a TA t2 prerequisite of t1, can be the entire WSDL file). The second part ("prerequisite" element) is an XPath (boolean) expression of the same nature as the predicate. If present, it must evaluate to "true" for the target to qualify. If it fails, the result for the current TA in the report will be "notRelevant". Otherwise, the target can be further evaluated by the predicate of the main TA. The expression may refer to the target explicitly using the variable name "$target", or to any cotarget using its name as variable name ($[name]). |
Predicate: |
[markup: testAssertion/predicate] required element] A logical expression that evaluates whether this target is fulfilling the profile requirement addressed by this test Assertion. By default: - A result of true means the requirement is fulfilled (reported as a "passed" in the test report).- A result of false means the requirement is violated (reported as a "failed" in the test report). However, in some cases and for testability reasons, the predicate may be designed as a partial indicator e.g. only indicates some cases of fulfillment, or some cases of violation. As a result, when "true" indicates fulfillment it may be that "false" is unconclusive, or conversely "false" will indicate violation, but "true" is unconclusive. In such cases, the "Reporting" element specifies the meaning of the predicate result w/r to the profile requirement. The predicate expression implicitly refers to the target (whic is its "XPath context") although it may explicitly refer to it using the variable name "$target". It may refer to any cotarget using its name as variable name ($[name]). |
Prescription: |
[markup: testAssertion/prescription/@level ] (required) Conveys the level of prescription associated with the profile requirement. At least three values may be used:
|
Reporting: |
[markup: testAssertion/reporting ] (optional) For each possible outcome of the predicate (true or false), specifies how it must be interpreted w/r to the profile feature. Two attributes are used that both must be present, when this element is present:
NOTES: the predicate of the TA may be worded in a negative way so that @false='passed' although that is not recommended. The result of a test should not be related to the prescription level, e.g. a "preferred" or "permitted" level should not imply that @false='warning'. Other test results that are automatically generated and not controlled by the "reporting" element are:
|
The following specifications' requirements are incorporated into the Profile by reference, except where superseded by the Profile:
This section identifies extensibility points, as defined in "Scope of the Profile," for the Profile's component specifications.
These mechanisms are out of the scope of the Profile and Profile conformance. An initial, non-exhaustive list of these extensibility points is provided here as their use may affect interoperability. In order to avoid interoperability issues not addressed by the Profile, out-of-band agreement on the use of these extensibility points may be necessary between the parties to a Web service.
In Web Services Reliable Messaging 1.2:
In Web Services Make Connection 1.1:
In addition to all of the profiled specifications listed in Appendix A, the following specifications are normatively referenced:
RFC2119 http://ietf.org/rfc/rfc2119 Key words for use in RFCs to Indicate Requirement Levels, S. Bradner March 1997
Namespaces in XML 1.0 (Second Edition) http://www.w3.org/TR/REC-xml-names/ T. Bray et al August 2006
WS-I Conformance Claim Attachment Mechanisms Version 1.0 http://www.ws-i.org/Profiles/ConformanceClaims-1.0-2004-11-15.html, M. Nottingham et al November 2004
WS-I Basic Profile 1.2 http://www.ws-i.org/Profiles/BasicProfile-1.2.html , G. Pilz et al September 2010
WS-I Basic Profile 2.0 http://www.ws-i.org/Profiles/BasicProfile-2.0.html , G. Pilz et al September 2010
WS-I Basic Security Profile 1.0 http://www.ws-i.org/Profiles/BasicSecurityProfile-1.0-2007-03-30.html , M. McIntosh et al March 2007
WS-I Basic Security Profile 1.1 http://www.ws-i.org/Profiles/BasicSecurityProfile-1.1.html , M. McIntosh et al January 2010
This document is the work of the WS-I Reliable Secure Profile Working Group.
A normative copy of the XML Schema description for this specification can be retrieved from the following address: http://ws-i.org/profiles/rsp/1.0/rsp.xsd . A non-normative copy of the XML schema is listed below for convenience:
For example,
CORRECT:
<xs:schema targetNamespace='http://ws-i.org/profiles/rsp/1.0/' xmlns:xs='http://www.w3.org/2001/XMLSchema' elementFormDefault='qualified' blockDefault='#all'> <xs:element name='Conformant'> <xs:complexType> <xs:sequence> <xs:any namespace='##other' processContents='lax' minOccurs='0' maxOccurs='unbounded'/> </xs:sequence> <xs:anyAttribute namespace='##other' processContents='lax' /> </xs:complexType> </xs:element> </xs:schema>