Reliable Secure Profile Version 1.0
Working Group Approval Draft
2009-09-14
This revision:
Latest revision:
http://mp.ws-i.org/apps/org/workgroup/rspwg/download.php/ReliableSecureProfile-1.0-WGAD.html
Editors:
Jacques Durand, Fujitsu
Gilbert Pilz, Oracle
Administrative contact:
Copyright © 2002-2009 by The Web
Services-Interoperability Organization ( WS-I)
and Certain of its Members. All Rights Reserved.
Abstract
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.
Status of this Document
This document is
a Working Group Approval Draft; it is an intermediate document that has been
approved for publication by the Working Group. It is a work in progress, and
should not be considered as final; other documents may supersede this document.
Notice
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.
Feedback
The Web
Services-Interoperability Organization (WS-I) would like to receive input,
suggestions and other feedback ("Feedback") on this work from a wide
variety of industry participants to improve its quality over time.
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@lists.ws-i.org.
Table of Contents
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. Use
of Extension Elements and Attributes in Messages
3.1.1. Ignore
Unknown Extension Elements
3.2. SOAP
Version Considerations
3.2.1. SOAP
Version Selection for Sequence Lifecycle Messages
3.3. Targeting
Sequence Lifecycle Messages
3.3.1. CreateSequence
Target
3.3.2. Use
of the Offer Element
3.4. Sequence
Identifiers
3.4.1. Duplicate
Identifier in CreateSequenceResponse
3.5. Sequence
Termination
3.5.1. Sequence
Termination from the Destination
3.5.2. Last
Message Number
3.5.3. Sequence
Lifecycle Independence
3.6. Sequence
Faults
3.6.1. Transmission
of Sequence Faults
3.6.2. WS-ReliableMessaging
Faults
3.7. Sequence
Assignment
3.7.1. Sequence
Assignment for Reliable Response Messages
3.7.2. Scope
of an RM Node
3.8. Retransmission
of Messages
3.8.1. Retransmission
of Unacknowledged Messages
3.8.2. Retransmission
of Sequence Lifecycle Messages
3.8.3. Message
Identity
3.9. Piggybacking
3.9.1. Endpoint
Comparison for Piggybacked SequenceAcknowledgment Headers
3.9.2. Treatment
of ReferenceParameters in AcksTo EPRs
3.9.3. Preventing
Piggybacked Acknowledgements
3.9.4. Conflicting
Requirements for wsa:Action
3.9.5. Use
of the mustUnderstand Attribute
4. Secure
Conversation
4.1. Unsupported
Context Tokens
4.1.1. Unrecognized
Extensions in a Security Context Token
4.2. Demonstrating
Proof of Possession
4.2.1. Amending
Contexts
4.2.2. Renewing
Contexts
4.2.3. Cancelling
Contexts
4.3. Claims
Re-Authentication
4.3.1. Re-Authenticating
Claims
4.4. Referencing
Security Context Tokens
4.4.1. Associating
a Security Context
4.4.2. Derived
Token References to Security Contexts
4.5. Addressing
Headers
4.5.1. Protecting
Addressing Headers
5. MakeConnection
5.1. Guidance
On the Use of MakeConnection
5.1.1. Action
Values
5.1.2. Binding
to HTTP
5.1.3. Transmission
of MakeConnection Faults
5.2. MakeConnection
Addressing
5.2.1. Addressing
Variants
5.2.2. MakeConnection
Anonymous URI
5.3. MakeConnection
Fault Behavior
5.3.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
1. Introduction
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.
1.1 Relationships to Other Profiles
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 profile P2 is said to
be composable with a profile P1 if, for any respective pair of conformance
targets (T2, T1) where T1 depends on T2 (see definition below), conformance of
an instance of T2 to P2 does not prevent conformance of the related T1
instance(s) to P1, and vice-versa in case T2 depends on T1.
A target T1 is
said to depend on a target T2 if either:
- T2 and T1 are just different names for the same type of
artifact (e.g. ENVELOPE in RSP and SOAP_ENVELOPE in BSP)
- or T2 is a specialization (or particular instance) of
T1 (e.g. SECURE_ENVELOPE in BSP is a specialization of ENVELOPE in RSP)
- T2 is contained in T1 (e.g. SECURITY_HEADER in BSP is
contained in ENVELOPE in RSP)
- more generally, an instance of T2 will restrict in some
way the possible values - or behaviors - of T1 instances associated with
it.
In order to
conform to this profile (RSP):
- If SOAP 1.1 is being used, all requirements defined in
BP 1.2 must be complied with.
- If SOAP 1.2 is being used, all requirements defined in
BP 2.0 must be complied with.
- Implementations must conform to the WS-Addressing 1.0 -
Core and SOAP Binding specifications, and if WSDL is used, the
WS-Addressing 1.0 - Metadata specification.
1.2 Guiding Principles
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.
No guarantee of interoperability
It is impossible to
completely guarantee the interoperability of a particular service. However, the
Profile does address the most common problems that implementation experience
has revealed to date.
Application semantics
Although communication
of application semantics can be facilitated by the technologies that comprise
the Profile, assuring the common understanding of those semantics is not
addressed by it.
Testability
When possible, the
Profile makes statements that are testable. However, such testability is not
required. Preferably, testing is achieved in a non-intrusive manner (e.g.,
examining artifacts "on the wire").
Strength of requirements
The Profile makes strong
requirements (e.g., MUST, MUST NOT) wherever feasible; if there are legitimate
cases where such a requirement cannot be met, conditional requirements (e.g.,
SHOULD, SHOULD NOT) are used. Optional and conditional requirements introduce
ambiguity and mismatches between implementations.
Restriction vs. relaxation
When amplifying the
requirements of referenced specifications, the Profile may restrict them, but
does not relax them (e.g., change a MUST to a MAY).
Multiple mechanisms
If a referenced
specification allows multiple mechanisms to be used interchangeably, the
Profile selects those that are well-understood, widely implemented and useful.
Extraneous or underspecified mechanisms and extensions introduce complexity and
therefore reduce interoperability.
Future compatibility
When possible, the
Profile aligns its requirements with in-progress revisions to the
specifications it references. This aids implementers by enabling a graceful
transition, and assures that WS-I does not 'fork' from these efforts. When the
Profile cannot address an issue in a specification it references, this
information is communicated to the appropriate body to assure its
consideration.
Compatibility with deployed services
Backwards compatibility
with deployed Web services is not a goal for the Profile, but due consideration
is given to it; the Profile does not introduce a change to the requirements of
a referenced specification unless doing so addresses specific interoperability
issues.
Focus on interoperability
Although there are
potentially a number of inconsistencies and design flaws in the referenced
specifications, the Profile only addresses those that affect interoperability.
Conformance targets
Where possible, the
Profile places requirements on artifacts (e.g., WSDL descriptions, SOAP
messages) rather than the producing or consuming software's behaviors or roles.
Artifacts are concrete, making them easier to verify and therefore making
conformance easier to understand and less error-prone.
Lower-layer interoperability
The Profile speaks to
interoperability at the application layer; it assumes that interoperability of
lower-layer protocols (e.g., TCP, IP, Ethernet) is adequate and
well-understood. Similarly, statements about application-layer substrate
protocols (e.g., SSL/TLS, HTTP) are only made when there is an issue affecting
Web services specifically; WS-I does not attempt to assure the interoperability
of these protocols as a whole. This assures that WS-I's expertise in and focus
on Web services standards is used effectively.
1.3 Test Assertions
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:
|
Note Item: |
|
|
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.examples.org/unknown/nmspace". RSP0400a: this TA is designed to
only detect messages that use an unrecognizable Sequence ID of value :
"http://dummy.examples.org/unknown/nmspace". RSP0400b: this TA is designed to
only detect messages that use an unrecognizable Sequence ID of value :
"http://dummy.examples.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.examples.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. 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. |
1.4 Notational Conventions
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.
Requirement
identifiers 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 by the conformance
URI of the document section it occurs in. If it is qualified, the prefix should
be interpreted according to the namespace mappings in effect, as documented
below.
Some requirements
clarify the referenced specification(s), but do not place additional
constraints upon implementations. For convenience, clarifications are annotated
in the following manner: C
Some requirements
are derived from ongoing standardization work on the referenced
specification(s). For convenience, such forward-derived statements are
annotated in the following manner: xxxx, where "xxxx"
is an identifier for the specification (e.g., "WSDL20" for WSDL
Version 2.0). Note that because such work was not complete when this document was
published, the specification that the requirement is derived from may change;
this information is included only as a convenience to implementers.
As noted above,
some requirements may present compatibility issues (whether forwards or
backwards) with previously published versions of the profile. For convenience,
such requirements are annotated in the following manner: Compat
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.
- soap11
- "http://schemas.xmlsoap.org/soap/envelope/"
- soap12
- "http://www.w3.org/2003/05/soap-envelope"
- xsi
- "http://www.w3.org/2001/XMLSchema-instance"
- xsd
- "http://www.w3.org/2001/XMLSchema"
- wsdl
- "http://schemas.xmlsoap.org/wsdl/"
- soapbind
- "http://schemas.xmlsoap.org/wsdl/soap/"
- wsa
- "http://www.w3.org/2005/08/addressing"
- wsrm
- "http://docs.oasis-open.org/ws-rx/wsrm/200702"
- wsmc
- "http://docs.oasis-open.org/ws-rx/wsmc/200702"
- wssc
- "http://docs.oasis-open.org/ws-sx/ws-secureconversation/200512"
- wst
- "http://docs.oasis-open.org/ws-sx/ws-trust/200512"
- wsse
-
"http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd"
- wsu
- "http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd"
1.5 Profile Identification and Versioning
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.
2 Profile Conformance
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.
2.1 Conformance
Requirements
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; i.e., although this
requirement must be met to maintain conformance in most cases, there are some
situations where there may be valid reasons for it not being met (which are
explained in the requirement itself, or in its accompanying text).
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.
None of the
requirements in the Profile, regardless of their conformance level, should be
interpreted as limiting the ability of an otherwise conforming implementation
to apply security countermeasures in response to a real or perceived threat
(e.g., a denial of service attack).
2.2 Conformance Targets
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:
- MESSAGE
- protocol elements that transport the ENVELOPE (e.g., SOAP/HTTP messages)
(from Basic
Profile 1.1)
- ENVELOPE
- the serialization of the soap:Envelope element and its content (from Basic Profile
1.1)
- DESCRIPTION
- descriptions of types, messages, interfaces and their concrete protocol
and data format bindings, and the network access points associated with
Web services (e.g., WSDL descriptions) (from Basic Profile
1.0)
- INSTANCE
- software that implements a wsdl:port or a uddi:bindingTemplate (from Basic Profile
1.0)
- CONSUMER
- software that invokes an INSTANCE (from Basic Profile
1.0)
- SENDER
- software that generates a message according to the protocol(s) associated
with it (from Basic
Profile 1.0)
- RECEIVER
- software that consumes a message according to the protocol(s) associated
with it (e.g., SOAP processors) (from Basic Profile
1.0)
- MC-SENDER
- software that generates a message containing an EPR that uses the
wsmc:MakeConnection Anonymous URI, and generates a MakeConnection message
as defined by WS-MakeConnection 1.1 (from WS-MakeConnection
1.1)
- MC-RECEIVER
- software that consumes a MakeConnection message as defined by WS-MakeConnection
1.1 (from WS-MakeConnection
1.1)
- RMS
- RM Source as defined by WS-ReliableMessaging 1.2 (from WS-ReliableMessaging
1.2)
- RMD
- RM Destination as defined by WS-ReliableMessaging 1.2 (from WS-ReliableMessaging
1.2)
- RM-NODE
- an instance of either an RM Source or an RM Destination (as defined
above)
2.3 Conformance Scope
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.
2.4 Claiming Conformance
Claims of
conformance to the Profile can be made using the following mechanisms, as
described in Conformance
Claim Attachment Mechanisms, when the applicable Profile requirements
associated with the listed targets have been met:
- WSDL 1.1 Claim Attachment
Mechanism for Web Services Instances
- MESSAGE DESCRIPTION INSTANCE RECEIVER RMS RMD
- WSDL 1.1 Claim Attachment
Mechanism for Description Constructs
- DESCRIPTION
- UDDI Claim Attachment Mechanism
for Web Services Instances - MESSAGE DESCRIPTION INSTANCE
RECEIVER
- UDDI Claim Attachment Mechanism
for Web Services Registrations - REGDATA
The conformance
claim URI for this Profile is "http://ws-i.org/profiles/rsp/1.0" .
3. Reliable Messaging
This section of
the Profile incorporates the following specifications by reference, and defines
extensibility points within them:
- Web
Services Reliable Messaging 1.2
Extensibility points: - E0001
- CreateSequence element and attribute extensions - Extending
CreateSequence, via additional elements or attributes, is the primary
mechanism for negotiating supplemental semantics to be applied to the
requested and/or offered Sequence. Note this extensiblity point does not
cover the pre-defined use of the
/wsrm:CreateSequence/wsse:SecurityTokenReference element.
- E0002
- CreateSequenceResponse element and attribute extensions - Extending
CreateSequenceResponse, via additional elements or attributes, may be
used to signal the acceptance of the supplemental semantics requested by
the use of E0001 or it may be used in its own right to request or signal
additional semantics to be applied to either requested and/or offered
Sequence.
- E0003
- CloseSequence element and attribute extensions - The CloseSequence
element may be extended via additional elements or attributes to indicate
the use of supplemental semantics or options in the closure of the
Sequence.
- E0004
- CloseSequenceResponse element and attribute extensions - The
CloseSequenceResponse element may be extended via additional elements or
attributes to indicate the use of supplemental semantics or options in
the closure of the Sequence.
- E0005
- TerminateSequence element and attribute extensions - The
TerminateSequence element may be extended via additional elements or
attributes to indicate the use of supplemental semantics or options in
the termination of the Sequence.
- E0006
- TerminateSequenceResponse element and attribute extensions - The
TerminateSequenceResponse element may be extended via additional elements
or attributes to indicate the use of supplemental semantics or options in
the termination of the Sequence.
- E0007
- Sequence element and attribute extensions - The Sequence header element
may be extended via additional elements or attributes to convey
supplemental semantics or options that apply to the Sequence identified
by the header.
- E0008
- AckRequested element and attribute extensions - The AckRequest header
element may be extended via additional elements or attributes to convey
supplemental semantics or options that apply to the request.
- E0009
- SequenceAcknowledgment element and attribute extensions - The
SequenceAcknowledgment header element may be extended via additional
elements or attributes to convey supplemental semantics or options that
apply to the acknowledgment.
- E0010
- SequenceFault element and attribute extensions - The SequenceFault
element may be extended via additional elements or attributes to convey
supplemental semantics or options that apply to the fault.
- Internationalized
Resource Identifiers (IRIs)
- Web Services
Addressing 1.0 - SOAP Binding
3.1 Use of Extension
Elements and Attributes in Messages
The protocol
elements defined by WS-ReliableMessaging contain extension points wherein
implementations MAY add child elements and/or attributes.
3.1.1 Ignore Unknown
Extension Elements
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. Any exceptions to this rule are clearly identified
in requirements below or the specifications underlying the profile TESTABLE_SCENARIO_DEPENDENT RSP0001
|
Test Assertion
Analysis: |
|
|
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: |
/wsil:testLog/wsil:messageLog/wsil:message/wsil:messageContents/*:Envelope[
|
|
co-Target: myresponse |
/wsil:testLog/wsil:messageLog/wsil:message[ |
|
Predicate: |
not($myresponse//*:Body/*:Fault) |
|
Reporting: |
true=passed, false=failed |
|
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 |
|
|
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). 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:
The reported outcomes
have the following meaning:
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.
3.2
SOAP Version Considerations
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.
3.2.1 SOAP Version
Selection for 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: |
|
|
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: |
/wsil:testLog/wsil:messageLog/wsil:message/wsil:messageContents/*:Envelope
|
|
Prerequisite: |
RSP8001 |
|
Predicate: |
some $csr in /wsil:testLog/wsil:messageLog//*:Envelope
(($cs/../../@conversation = $csr/../../@conversation) or |
|
Reporting: |
true=passed,
false=failed |
|
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). 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:
The reported outcomes
have the following meaning:
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: |
|
|
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: |
/wsil:testLog/wsil:messageLog/wsil:message/wsil:messageContents/*:Envelope
|
|
Prerequisite: |
RSP8001 |
|
Predicate: |
some $cs in preceding::*:Envelope
|
|
Reporting: |
true=passed,
false=failed |
|
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). 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:
The reported outcomes
have the following meaning:
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:
|
3.3 Targeting Sequence Lifecycle Messages
WS-ReliableMessaging is silent on where certain Sequence Lifecycle
Messages (such as CreateSequence) should be sent.
3.3.1 CreateSequence Target
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: |
|
|
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: |
RSP0800 |
|
Description: |
|
|
Target: |
/wsil:testLog/wsil:messageLog/wsil:message/wsil:messageContents/*:Envelope
|
|
co-Target: mycsr |
/wsil:testLog/wsil:messageLog/wsil:message/wsil:messageContents/*:Envelope
|
|
Predicate: |
some $env in
/wsil:testLog/wsil:messageLog/wsil:message/wsil:messageContents/*:Envelope[*:Header/wsrm:Sequence/wsrm:Identifier
= $mycsr/*:Body/wsrm:CreateSequenceResponse/wsrm:Identifier] satisfies |
|
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). 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:
The reported outcomes
have the following meaning:
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).
3.3.2 Use of the Offer Element
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 interoperatbility 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: |
|
|
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: |
/wsil:testLog/wsil:messageLog/wsil:message/wsil:messageContents/*:Envelope[
|
|
co-Target: myresponse |
/wsil:testLog/wsil:messageLog/wsil:message[
|
|
Predicate: |
not($myresponse//*:Body/*:Fault) |
|
Reporting: |
true=passed,
false=failed |
|
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). 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:
The reported outcomes
have the following meaning:
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: |
|
|
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: |
/wsil:testLog/wsil:messageLog/wsil:message/wsil:messageContents/*:Envelope[*:Body/wsrm:CreateSequence/wsrm:Offer] |
|
co-Target: myresponse |
/wsil:testLog/wsil:messageLog/wsil:message[
|
|
Predicate: |
not($myresponse//*:Body/*:Fault) |
|
Reporting: |
true=passed,
false=failed |
|
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). 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:
The reported outcomes
have the following meaning:
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:
|
3.4 Sequence Identifiers
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.
3.4.1 Duplicate Identifier in
CreateSequenceResponse
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: |
|
|
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). 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:
The reported outcomes
have the following meaning:
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.
3.5
Sequence Termination
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:
3.5.1 Sequence Termination from the Destination
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: |
|
|
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). 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:
The reported outcomes
have the following meaning:
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:
|
3.5.2 Last Message Number
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 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: |
|
|
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: |
//wsil:messageContents/*:Envelope[
|
|
Predicate: |
*:Body/wsrm:*/wsrm:LastMsgNumber |
|
Reporting: |
true=passed,
false=failed |
|
Prescription: |
mandatory |
|
Error Message: |
The soap:envelope in a
wsrm:CloseSequence or a wsrm:TerminateSequence message does not contain a
wsrm:LastMsgNumber element. |
|
Diagnostic Data: |
{SOAP message} |
|
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). 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:
The reported outcomes
have the following meaning:
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.
3.5.3 Sequence Lifecycle Independence
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
3.6 Sequence Faults
This Profile adds the following requirement to the handling of
faults that are generated as the result of processing WS-RM Sequence Lifecycle
messages.
3.6.1 Transmission of Sequence Faults
In Section 4, "Faults"
WS-ReliableMessaging states that a receiver that generates a fault related to a
known sequence SHOULD transmit that fault. However, the WS-I Basic Profile 1.2
states, in requirement R1029, that, under certain circumstances, the receiver
must transmit the fault. Mapping the specifics of the BP 1.2 requirement onto
the details of the WS-RM specification results in the following requirement:
R0400 If a fault
is generated while processing a wsrm:CreateSequence, wsrm:CloseSequence, or
wsrm:TerminateSequence message, or a message containing a wsrm:AckRequested
header, the RECEIVER MUST transmit the fault. TESTABLE_SCENARIO_DEPENDENT RSP0400a RSP0400b
|
Test Assertion
Analysis: |
|
|
General Notes: |
NOTE1: needs artificial traffic generation to stimulate fault;
if then easy, might need to use signature of corruption and correlation to
fault or lack thereof.NOTE2: Test env. can cause a fault situation for one of
the RM protocol mesg, and then we must observe a correlating Fault in the
log. NOTE3: TA will only test some of the faulty cases (partial coverage) |
|
Coverage Assessment: |
partial, due to lack of exhaustive coverage of cases. |
|
Target Type: |
ENVELOPE (of RM protocol message) |
|
Test Target: |
For a faulty RM protocol message above (based on predefined test
control protocol) |
|
Test co-Target(s): |
|
|
Test Prerequisite: |
|
|
Predicate: |
There is a related Fault message in response, in the log. |
|
Prescription: |
mandatory |
|
Reporting: |
true=pass, false=fail |
|
Test Control: |
Generate a faulty RM protocol message, or using MIM corrupt a
correctly generated one. |
|
Test Assertion: |
RSP0400a |
|
Description: |
|
|
Target: |
/wsil:testLog/wsil:messageLog/wsil:message/wsil:messageContents/*:Envelope[
|
|
co-Target: myresponse |
/wsil:testLog/wsil:messageLog/wsil:message[
|
|
Predicate: |
$myresponse//*:Body/*:Fault |
|
Reporting: |
true=passed,
false=failed |
|
Prescription: |
mandatory |
|
Error Message: |
Warning: A fault must
have been generated due to unrecognized RM sequence ID in wsrm:CloseSequence,
wsrm:TerminateSequence or *:Header/wsrm:AckRequested message, but the fault
was not transmitted as 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). 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:
The reported outcomes
have the following meaning:
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: |
|
|
General Notes: |
NOTE1: needs artificial traffic generation to stimulate fault;
if then easy, might need to use signature of corruption and correlation to
fault or lack thereof.NOTE2: Test env. can cause a fault situation for one of
the RM protocol mesg, and then we must observe a correlating Fault in the
log. NOTE3: TA will only test some of the faulty cases (partial coverage) |
|
Coverage Assessment: |
partial, due to lack of exhaustive coverage of cases. |
|
Target Type: |
ENVELOPE (of RM protocol message) |
|
Test Target: |
For a faulty RM protocol message above (based on predefined test
control protocol) |
|
Test co-Target(s): |
|
|
Test Prerequisite: |
|
|
Predicate: |
There is a related Fault message in response, in the log. |
|
Prescription: |
mandatory |
|
Reporting: |
true=pass, false=fail |
|
Test Control: |
Generate a faulty RM protocol message, or using MIM corrupt a
correctly generated one. |
|
Test Assertion: |
RSP0400b |
|
Description: |
|
|
Target: |
/wsil:testLog/wsil:messageLog/wsil:message/wsil:messageContents/*:Envelope[
|
|
co-Target: myresponse |
/wsil:testLog/wsil:messageLog/wsil:message[
|
|
Predicate: |
not($myresponse//*:Body/wsrm:CreateSequenceResponse) and not($myresponse//*:Body/wsrm:TerminateSequenceResponse) and not($myresponse//*:Header/wsrm:SequenceAcknowledgement) |
|
Reporting: |
true=passed,
false=failed |
|
Prescription: |
mandatory |
|
Error Message: |
A legitimate response
- either a wsrm:CreateSequenceResponse or a wsrm:TerminateSequenceResponse or
a wsrm:SequenceAcknowledgement - has been sent back to a lifecycle management
message that contained an unrecognizable sequence 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). 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:
The reported outcomes
have the following meaning:
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:
|
3.6.2 WS-ReliableMessaging Faults
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 RSP0620
|
Test Assertion
Analysis: |
|
|
General Notes: |
This is a simple case of creating an assertion that tests for
the co-occurrence of the elements that the requirement states shouldn’t
occur together. |
|
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=pass, false=fail |
|
Test Control: |
TBD – a scenario that causes either a
wsrm:SequenceTerminated or wsrm:UnknownSequence fault. |
|
Test Assertion: |
RSP0620 |
|
Description: |
|
|
Target: |
/wsil:testLog/wsil:messageLog/wsil:message/wsil:messageContents/*:Envelope
|
|
Predicate: |
not(./*:Header ) or ./*:Header[not (wsrm:Sequence) ] |
|
Reporting: |
true=passed,
false=failed |
|
Prescription: |
mandatory |
|
Error Message: |
A 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). 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:
The reported outcomes
have the following meaning:
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:
|
3.7 Sequence Assignment
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.
3.7.1 Sequence
Assignment for Reliable Response Messages
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 common understanding of the
Sequence assignment mechanism for reliable response messages. Without such an
understanding it is impossible, for example, to implement in-order delivery for
response messages.
R0600 Any two ENVELOPEs that are sent reliably by an RMS in response - either as a
replies or as faults - to two request messages that were sent within the same
Sequence, SHOULD contain the same wsrm:Identifier (that is, share the same
Sequence). TESTABLE RSP0600
|
Test Assertion
Analysis: |
|
|
General Notes: |
NOTE1: only a recommendation. TA will be useful to assess the
behavior of implementations, if not to assess conformance. NOTE2: no
requirement the response sequence is resulting from an offer? |
|
Coverage Assessment: |
Good |
|
Target Type: |
ENVELOPE (with RM header) |
|
Test Target: |
For an Envelope E1b that is sent reliably in response to another
Envelope E1a sent reliably, if there exists an Envelope E2b that is sent
reliably in response to another Envelope E2a sent reliably in the same
sequence as E1a. |
|
Test co-Target(s): |
|
|
Test Prerequisite: |
|
|
Predicate: |
every Envelope E2b matching the context has same wsrm:Identifier
as E1b. |
|
Prescription: |
preferred |
|
Reporting: |
(default) |
|
Test Control: |
|
Test Assertion: |
RSP0600 |
|
Description: |
|
|
Target: |
/wsil:testLog/wsil:messageLog/wsil:message
$req1/preceding::wsil:message[@type = 'request' and ] |
|
co-Target: siblingresp |
/wsil:testLog/wsil:messageLog/wsil:message
some $req1 in
$req2/following::wsil:message[@type = 'request' and
.//*:Header/wsrm:Sequence/wsrm:Identifier = $req2//*:Header/wsrm:Sequence/wsrm:Identifier]
satisfies ] |
|
Predicate: |
$siblingresp//*:Header/wsrm:Sequence/wsrm:Identifier = $target//*:Header/wsrm:Sequence/wsrm:Identifier |
|
Reporting: |
true=passed,
false=failed |
|
Prescription: |
preferred |
|
Error Message: |
Two Message envelopes
E1resp and E2resp were sent reliably (RM) as responses to two other envelopes
E1req and E2req that both belong to the same RM sequence. Yet, E1resp and
E2resp do not belong to teh 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). 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:
The reported outcomes
have the following meaning:
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 the RMS referred to above is a
"server-side RMS" (i.e. the RMS responsible for transmitting response
messages from the producer to the consumer in a reliable fashion).
3.7.2 Scope of an RM Node
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: |
|
|
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: |
RSP0610 |
|
Description: |
|
|
Target: |
/wsil:testLog/wsil:messageLog/wsil:message
some $req1 in /wsil:testLog/wsil:messageLog/wsil:message[@type =
'request' and (@conversation = $resp1/@conversation or .//*:Header/wsa:MessageID
= $resp1//wsa:RelatesTo[@RelationshipType =
'http://www.w3.org/2005/08/addressing/reply' or not (@RelationshipType)]) and
.//*:Header/wsrm:Sequence] satisfies $req1/preceding::wsil:message[@type = 'request' and
(.//*:Header/wsrm:Sequence/wsrm:Identifier =
$req1//*:Header/wsrm:Sequence/wsrm:Identifier) and (
not(.//*:Header/wsa:ReplyTo/wsa:Address =
$req1//*:Header/wsa:ReplyTo/wsa:Address))] ] |
|
co-Target: siblingresp |
/wsil:testLog/wsil:messageLog/wsil:message
($req1/@conversation = $target/@conversation or $req1//*:Header/wsa:MessageID
= $target//wsa:RelatesTo[@RelationshipType =
'http://www.w3.org/2005/08/addressing/reply' or not (@RelationshipType)]) and
not($req2//*:Header/wsa:ReplyTo/wsa:Address =
$req1//*:Header/wsa:ReplyTo/wsa:Address ) and ($req2//wsa:ReplyTo or
$req1//wsa:ReplyTo) ] |
|
Predicate: |
$siblingresp//*:Header/wsrm:Sequence/wsrm:Identifier = $target//*:Header/wsrm:Sequence/wsrm:Identifier |
|
Reporting: |
true=passed,
false=failed |
|
Prescription: |
mandatory |
|
Error Message: |
Warning: Two response
messages sent reliably (RM) and related to two request messages sent over the
same RM sequence, should have been sent over the same RM sequence (according
to R0600) and yet were sent over different sequences. Please verify this is
not because they were sent to two different EPRs. |
|
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). 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:
The reported outcomes
have the following meaning:
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".
3.8 Retransmission of Messages
WS-ReliableMessaging protocol requires retransmission of messages.
The Profile places the following restrictions and refinements on such
retransmissions:
3.8.1 Retransmission of Unacknowledged Messages
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: |
|
|
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=pass, false=fail |
|
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: |
//wsil:messageContents/*:Envelope
$env1/preceding::*:Envelope[*:Header/wsrm:Sequence/wsrm:Identifier
= $seqid and *:Header/wsrm:Sequence/wsrm:MessageNumber =
$env1/*:Header/wsrm:Sequence/wsrm:MessageNumber ] ] |
|
Predicate: |
not ( (./following::*:Envelope[*:Header/wsrm:Sequence/wsrm:Identifier
= $seqid and ) |
|
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). 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:
The reported outcomes
have the following meaning:
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 message until the Sequence is closed
or terminated. TESTABLE RSP0102
|
Test Assertion
Analysis: |
|
|
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: |
/wsil:testLog/wsil:messageLog/wsil:message/wsil:messageContents/*:Envelope
not( some $clseq in
$tgenv/preceding::*:Envelope[*:Body/wsrm:CloseSequence or *:Body/wsrm:TerminateSequence
] satisfies ] |
|
Predicate: |
( some $env in
following::*:Envelope[*:Header/wsrm:SequenceAcknowledgement/wsrm:Identifier =
$target/*:Header/wsrm:Sequence/wsrm:Identifier] satisfies ($ackrange/@Lower le
$target/*:Header/wsrm:Sequence/wsrm:MessageNumber and |
|
Reporting: |
true=passed,
false=failed |
|
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). 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:
The reported outcomes
have the following meaning:
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".
3.8.2 Retransmission of Sequence Lifecycle
Messages
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
3.8.3 Message Identity
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: |
|
|
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: |
/wsil:testLog/wsil:messageLog/wsil:message/wsil:messageContents/*:Envelope[
|
|
Predicate: |
some $curenv in .
satisfies |
|
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). 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:
The reported outcomes
have the following meaning:
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:
|
3.9 Piggybacking
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.
3.9.1 Endpoint
Comparison for Piggybacked SequenceAcknowledgment Headers
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, at a minimum, perform a simple string comparison algorithm,
as indicated in the RFC
3987 section 5.3.1, of the respective wsa:Address IRIs before
piggybacking a SequenceAcknowledgement Header onto another message. NOT_TESTABLE COM0500
|
Test Assertion
Analysis: |
|
|
General Notes: |
very hard to stimulate if at all (a heck of a lot of work) |
|
Coverage Assessment: |
|
|
Target Type: |
|
|
Test Target: |
|
|
Test co-Target(s): |
|
|
Test Prerequisite: |
|
|
Predicate: |
|
|
Prescription: |
mandatory |
|
Reporting: |
|
|
Test Control: |
|
Test Assertion: |
COM0500 |
|
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). 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:
The reported outcomes have the following meaning:
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: |
|
|
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: |
/wsil:testLog/wsil:messageLog/wsil:message[@type =
'response']/wsil:messageContents/*:Envelope |
|
co-Target: myRequestMsg |
/wsil:testLog/wsil:messageLog/wsil:message |
|
Prerequisite: |
not ($myRequestMsg/wsil:messageContents/*:Envelope/*:Body/wsmc:MakeConnection ) |
|
Predicate: |
every $seqack in $target/*:Header/wsrm:SequenceAcknowledgement
satisfies |
|
Reporting: |
true=passed, false=failed |
|
Prescription: |
mandatory |
|
Error Message: |
A sequence acknowledgement message sent back over an HTTP
response and piggybacked over a message is related to a request HTTP message
that does not carry a Sequence header related to the acknowledged 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). 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:
The reported outcomes have the following meaning:
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. Individual RMD implementations may choose to
consider and/or compare additional elements of the EndpointReference (e.g. the
value of any ReferenceParameters elements).
3.9.2 Treatment of ReferenceParameters in AcksTo EPRs
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. NOT_TESTABLE COM0500
|
Test Assertion
Analysis: |
COM0500 |
|
General Notes: |
very hard to stimulate if at all (a heck of a lot of work) |
|
Coverage Assessment: |
|
|
Target Type: |
|
|
Test Target: |
|
|
Test co-Target(s): |
|
|
Test Prerequisite: |
|
|
Predicate: |
|
|
Prescription: |
mandatory |
|
Reporting: |
|
|
Test Control: |
|
Test Assertion: |
COM0500 |
|
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). 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:
The reported outcomes
have the following meaning:
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.
3.9.3 Preventing Piggybacked Acknowledgements
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 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.
3.9.4 Conflicting Requirements for wsa:Action
Points (2) and (3) of Section 3.3 of the
WS-ReliableMessaging state that:
2. When an Endpoint generates an Acknowledgement Message that has
no element content in the SOAP body, then the value of the wsa:Action IRI MUST
be: http://docs.oasis-open.org/ws-rx/wsrm/200702/SequenceAcknowledgement
3. When an Endpoint generates an Acknowledgement Request that has
no element content in the SOAP body, then the value of the wsa:Action IRI MUST
be: http://docs.oasis-open.org/ws-rx/wsrm/200702/AckRequested
However, this text does
not take into account the possibility of piggybacking either of the above RM
headers on messages with empty SOAP Bodys that contain wsa:Action values
necessary to the proper processing of those messages. Such Envelopes could be
the result of a WSDL that contains a doc-literal description where the value of
the parts attribute of soap:body is an empty string. To clarify the expected
behavior of WS-RM nodes under these circumstances, this profile makes the
following requirement:
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 RSP0530
|
Test Assertion
Analysis: |
|
|
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: |
RSP0530 |
|
Description: |
Case of empty Body in
a response with Seq Ack |
|
Target: |
/wsil:testLog/wsil:messageLog/wsil:message/wsil:messageContents/*:Envelope
|
|
co-Target: myOpBind |
//wsil:descriptionFile/wsdl:definitions/wsdl:binding/wsdl:operation
( some $dmsg in
$opb/../../wsdl:message[fn:resolve-QName(xsd:string(wsdl:part[1]/@element),
.) = fn:node-name($target/*:Body/*[1])] satisfies ) ] |
|
Predicate: |
some $op in
//wsil:descriptionFile/wsdl:definitions/wsdl:portType/wsdl:operation[@name =
$myOpBind/@name ] satisfies ($target/*:Header/wsa:Action = 'http://docs.oasis-open.org/ws-rx/wsrm/200702/SequenceAcknowledgement'
and not($op/wsdl:output/@wsam:Action)) or |
|
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 - but with an empty body, does not conform to
Section 3.3 of the WS-ReliableMessaging specification: it does not have the
wsa:Action conforming to wsam:Action in the binding, and does not have the
predefined wsa:Action URI value ending with
"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). 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:
The reported outcomes
have the following meaning:
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:
|
3.9.5 Use of the mustUnderstand Attribute
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: |
|
|
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: |
/wsil:testLog/wsil:messageLog/wsil:message/wsil:messageContents/*:Envelope[(*:Header/wsrm:AckRequested or *:Header/wsrm:SequenceAcknowledgement) and *:Body/*] |
|
Predicate: |
not
(*:Header/wsrm:AckRequested/attribute::*:mustUnderstand = '1') and not
(*:Header/wsrm:AckRequested/attribute::*:mustUnderstand = 'true') and not
(*:Header/wsrm:SequenceAcknowledgement/attribute::*:mustUnderstand = '1') and
not (*:Header/wsrm:SequenceAcknowledgement/attribute::*:mustUnderstand =
'true') |
|
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). 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:
The reported outcomes
have the following meaning:
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:
|
4. Secure Conversation
The Profile includes the use of WS-SecureConversation to request
and issue security tokens and to broker trust relationship.
This section of the Profile incorporates the following
specifications by reference, and defines extensibility points within them:
- WS-SecureConversation 1.4
Extensibility points: - E0011 - SecrutiyContextToken
element and attribute extensions - The SecurityContextToken element may
be extended via additional elements or attributes to indicate the use of
supplemental semantics or options that apply to the security context
identified by the token.
All requirements in Section 4 apply only when WS-Security is used
to secure a message. All requirements in Sections 4.1 through 4.4 apply only
when WS-SecureConversation is used to secure a message.
4.1 Unsupported Context Tokens
4.1.1 Unrecognized
Extensions in a Security Context Token
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. TESTABLE RSP1000
|
Test Assertion
Analysis: |
|
|
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=pass, fail=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). 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:
The reported outcomes
have the following meaning:
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: |
|
|
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.examples.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: |
/wsil:testLog/wsil:messageLog/wsil:message/wsil:messageContents/*:Envelope
|
|
Predicate: |
some $elt in
$target/*:Header//wssc:SecurityContextToken//* satisfies |
|
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.examples.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). 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:
The reported outcomes
have the following meaning:
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.
4.2 Demonstrating Proof of Possession
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.
4.2.1 Amending Contexts
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: |
|
|
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: |
/wsil:testLog/wsil:messageLog/wsil:message/wsil:messageContents/*:Envelope
|
|
Predicate: |
some $dsig in
$target/*:Header/wsse:Security//ds:Signature satisfies ($dsig//ds:Reference[fn:substring-after(@URI, '#') eq
$target/*:Header/@wsu:Id] or and ( $dsig//ds:Reference[fn:substring-after(@URI, '#') eq
$target/*:Body/@wsu:Id] or ) |
|
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). 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:
The reported outcomes
have the following meaning:
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: |
|
|
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). 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:
The reported outcomes
have the following meaning:
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:
|
4.2.2 Renewing Contexts
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: |
|
|
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: |
/wsil:testLog/wsil:messageLog/wsil:message/wsil:messageContents/*:Envelope
|
|
Predicate: |
some $dsig in
$target/*:Header/wsse:Security//ds:Signature satisfies ($dsig//ds:Reference[fn:substring-after(@URI, '#') eq
$target/*:Header/@wsu:Id] or (every $cruxp in $target/*:Header/wsrm:* |
$target/*:Header/wsa:* satisfies and ( $dsig//ds:Reference[fn:substring-after(@URI, '#') eq
$target/*:Body/@wsu:Id] or ) |
|
Reporting: |
true=passed,
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). 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:
The reported outcomes
have the following meaning:
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
4.2.3 Cancelling Contexts
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: |
|
|
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: |
/wsil:testLog/wsil:messageLog/wsil:message/wsil:messageContents/*:Envelope
|
|
Predicate: |
some $dsig in
$target/*:Header/wsse:Security//ds:Signature satisfies ($dsig//ds:Reference[fn:substring-after(@URI, '#') eq
$target/*:Header/@wsu:Id] or and ( $dsig//ds:Reference[fn:substring-after(@URI, '#') eq
$target/*:Body/@wsu:Id] or ) |
|
Reporting: |
true=passed, 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). 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:
The reported outcomes
have the following meaning:
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
4.3 Claims Re-Authentication
4.3.1 Re-Authenticating Claims
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: |
|
|
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: |
/wsil:testLog/wsil:messageLog/wsil:message/wsil:messageContents/*:Envelope[./*:Body//wst:RequestSecurityToken and ./*:Header/wsa:Action eq 'http://docs.oasis-open.org/ws-sx/ws-trust/200512/RST/SCT/Renew'] |
|
co-Target: myOriginalRSTR |
/wsil:testLog/wsil:messageLog/wsil:message/wsil:messageContents/*:Envelope[*:Body//wst:RequestSecurityTokenResponse
and *:Header/wsa:Action eq
'http://docs.oasis-open.org/ws-sx/ws-trust/200512/RSTR/SCT']
[*:Body//wst:RequestSecurityTokenResponse/wssc:SecurityContextToken/wssc:Identifier
=
$target/*:Body//wst:RequestSecurityToken/wst:RenewTarget/wsse:SecurityTokenReference/wsse:Reference/@URI
] |
|
Predicate: |
/wsil:testLog/wsil:messageLog/wsil:message/wsil:messageContents/*:Envelope[*:Body//wst:RequestSecurityToken
and *:Header/wsa:Action eq
'http://docs.oasis-open.org/ws-sx/ws-trust/200512/RST/SCT']
[(../../@conversation = $myOriginalRSTR/../../@conversation) or
($myOriginalRSTR/*:Header/wsa:RelatesTo[not (@RelationshipType) or (
@RelationshipType = 'http://www.w3.org/2005/08/addressing/reply' )] =
./*:Header/wsa:MessageID)
]/*:Header/wsse:Security/ds:Signature/ds:KeyInfo//ds:Reference/@URI =
$target/*:Header/wsse:Security/ds:Signature/ds:KeyInfo//ds:Reference/@URI |
|
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). 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:
The reported outcomes
have the following meaning:
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:
|
4.4
Referencing Security Context Tokens
4.4.1 Associating a Security Context
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. Since
message independent references provide a superset of the functionality of
message dependent references, and it is simpler to support one mechanism for
referencing SCTs than two, this profile includes the following requirement:
R1300 In an ENVELOPE that contains either a wsse:Security header, a
wst:RequestSecurityToken element, or a wst:RequestSecurityTokenReponse element
in which there are references to wssc:SecurityContextToken elements, such
references MUST be message independent (i.e. MUST use a wsse:Reference to the
wssc:Identifier element). TESTABLE RSP1300
|
Test Assertion
Analysis: |
|
|
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: |
/wsil:testLog/wsil:messageLog/wsil:message/wsil:messageContents/*:Envelope[*:Header/wsse:Security//wssc:SecurityContextToken or .//wst:RequestSecurityTokenReponse//wssc:SecurityContextToken or .//wst:RequestSecurityToken//wssc:SecurityContextToken][.//wsse:SecurityTokenReference/wsse:Reference] |
|
Predicate: |
$target//wsse:SecurityTokenReference/wsse:Reference[@URI and not (fn:starts-with(xsd:string(@URI), '#' )) ] |
|
Reporting: |
true=passed,
false=failed |
|
Prescription: |
mandatory |
|
Error Message: |
An Envelope with
wssc:Security or RST or RSTR and with SecurityContextToken references, has a
reference URI that is not relative - does not start with '#'. |
|
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). 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:
The reported outcomes
have the following meaning:
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:
|
4.4.2 Derived Token References to Security Contexts
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: |
|
|
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: |
/wsil:testLog/wsil:messageLog/wsil:message/wsil:messageContents/*:Envelope[*:Header/wsse:Security//wssc:DerivedKeyToken/wsse:SecurityTokenReference] |
|
Predicate: |
some $rstr in
$target/preceding::*:Envelope[*:Body//wst:RequestSecurityTokenResponse and
*:Header/wsa:Action eq
'http://docs.oasis-open.org/ws-sx/ws-trust/200512/RSTR/SCT'] satisfies
$rstr/*:Body//wst:RequestSecurityTokenResponse/wssc:SecurityContextToken/wssc:Identifier
=
$target/*:Header/wsse:Security//wssc:DerivedKeyToken/wsse:SecurityTokenReference/wsse:Reference/@URI
|
|
Reporting: |
true=passed,
false=failed |
|
Prescription: |
mandatory |
|
Error Message: |
an Envelope with
wsc:DerivedKeyToken does not refer (with wsse:SecurityTokenReference) to a
wssc:SecurityContextToken returned in a RequestSecurityTokenResponse 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). 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:
The reported outcomes
have the following meaning:
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.
4.5 Addressing Headers
4.5.1 Protecting Addressing Headers
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: |
|
|
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: |
/wsil:testLog/wsil:messageLog/wsil:message/wsil:messageContents/*:Envelope[
some $tgt in . satisfies some $ref in
*:Header/wsse:Security//ds:Signature//ds:Reference satisfies (fn:substring-after($ref/@URI,
'#') = $tgt/*:Body/@wsu:Id or fn:substring-after($ref/URI, '#') =
$tgt/@wsu:Id )] |
|
Predicate: |
( some $ref in
$target/*:Header/wsse:Security//ds:Signature//ds:Reference satisfies
fn:substring-after($ref/@URI, '#') = $target/*:Header/@wsu:Id or
fn:substring-after($ref/URI, '#') = $target/@wsu:Id ) or ( every $wsah in
$target/*:Header/wsa:* satisfies some $ref in
$target/*:Header/wsse:Security//ds:Signature//ds:Reference satisfies (
fn:substring-after($ref/@URI, '#') = $wsah/@wsu:Id)) |
|
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). 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:
The reported outcomes
have the following meaning:
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: |
|
|
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: |
/wsil:testLog/wsil:messageLog/wsil:message/wsil:messageContents/*:Envelope[*:Header/wsse:Security
and *:Header/wsa:*] |
|
Prerequisite: |
RSP1400 |
|
Predicate: |
( some $ref in
$target/*:Header/wsse:Security//ds:Signature//ds:Reference satisfies
fn:substring-after($ref/URI, '#') = $target/@wsu:Id ) or ( some $ref in
$target/*:Header/wsse:Security//ds:Signature//ds:Reference satisfies (
fn:substring-after($ref/@URI, '#') = $target/*:Body/@wsu:Id and (every $wsah
in $target/*:Header/wsa:* satisfies some $ref2 in $ref/../ds:Reference
satisfies ( fn:substring-after($ref2/@URI, '#') = $wsah/@wsu:Id)) ) ) |
|
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). 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:
The reported outcomes
have the following meaning:
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: |
|
|
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: |
/wsil:testLog/wsil:messageLog/wsil:message/wsil:messageContents/*:Envelope[*:Header/*/@wsa:isReferenceParameter][
some $tgt in . satisfies some $ref in
*:Header/wsse:Security//ds:Signature//ds:Reference satisfies
(fn:substring-after($ref/@URI, '#') = $tgt/*:Body/@wsu:Id or
fn:substring-after($ref/URI, '#') = $tgt/@wsu:Id )] |
|
Predicate: |
( some $ref in
$target/*:Header/wsse:Security//ds:Signature//ds:Reference satisfies
fn:substring-after($ref/@URI, '#') = $target/*:Header/@wsu:Id or
fn:substring-after($ref/URI, '#') = $target/@wsu:Id ) or ( every $rfp in
$target/*:Header/*[@wsa:isReferenceParameter] satisfies some $ref in
$target/*:Header/wsse:Security//ds:Signature//ds:Reference satisfies (
fn:substring-after($ref/@URI, '#') = $rfp/@wsu:Id)) |
|
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). 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:
The reported outcomes
have the following meaning:
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: |
|
|
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: |
/wsil:testLog/wsil:messageLog/wsil:message/wsil:messageContents/*:Envelope[*:Header/wsse:Security
and *:Header/*/@wsa:isReferenceParameter] |
|
Prerequisite: |
RSP1402 |
|
Predicate: |
( some $ref in
$target/*:Header/wsse:Security//ds:Signature//ds:Reference satisfies
fn:substring-after($ref/URI, '#') = $target/@wsu:Id ) or ( some $ref in
$target/*:Header/wsse:Security//ds:Signature//ds:Reference satisfies (
fn:substring-after($ref/@URI, '#') = $target/*:Body/@wsu:Id and (every $rfp
in $target/*:Header/*[@wsa:isReferenceParameter] satisfies some $ref2 in
$ref/../ds:Reference satisfies ( fn:substring-after($ref2/@URI, '#') =
$rfp/@wsu:Id)) ) ) |
|
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). 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:
The reported outcomes
have the following meaning:
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:
|
5. MakeConnection
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:
- Web Services Make Connection
1.1
Extensibility points: - E0012 - MakeConnection element and
attribute extensions - The MakeConnection element may be extended via
additional elements or attributes to indicate the use of supplemental
semantics or options that apply to the request.
- E0013 - Attribute extensions to the
MakeConnection Address - The /wsmc:MakeConnection/wsmc:Address element
may be extended via additional attributes to indicate the use of
supplemental semantics or options that apply to this instance of the
MakeConnection Anonymous URI
- E0014 - MessagePending element and
attribute extensions - The MessagePending header element may be extended
via additional elements or attributes to convey supplemental semantics or
options that apply to the indication of pending messages.
- SOAP Request-Response Message
Exchange Pattern
- WSDL 1.1 Port Types
The requirements and supporting
text in this section make use of the following terms:
- non-addressable
client
- a client deployed on a host that cannot accept incoming connections from
the services to which it transmits requests. Examples inlcude clients that
are deployed on hosts behind a firewall or network address translator
(NAT).
- addressable
client
- a client deployed on a host that is capable of accepting incoming
connections from the services to which it transmits requests.
5.1 Guidance On the Use of MakeConnection
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.
5.1.1 Action Values
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 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: |
|
|
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: |
//wsil:messageContents/*:Envelope
|
|
Predicate: |
*:Header/wsa:Action eq "http://docs.oasis-open.org/ws-rx/wsmc/200702/MakeConnection" |
|
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). 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:
The reported outcomes
have the following meaning:
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: |
|
|
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:testLog/wsil:messageLog/wsil:message
|
|
Predicate: |
(wsil:httpHeaders/wsil:httpHeader[@key = 'SOAPAction']/@value =
'http://docs.oasis-open.org/ws-rx/wsmc/200702/MakeConnection' and (wsil:httpHeaders/wsil:httpHeader[@key = 'SOAPAction']/@quoted =
'true' or |
|
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). 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:
The reported outcomes
have the following meaning:
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: |
|
|
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:message |
|
Predicate: |
wsil:httpHeaders/wsil:contentTypeHeader/wsil:parameter[@key = 'action']/@value = "http://docs.oasis-open.org/ws-rx/wsmc/200702/MakeConnection" |
|
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). 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:
The reported outcomes
have the following meaning:
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:
|
5.1.2 Binding to HTTP
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:
- Through
some mechanism, NA
is provided the EPR for B
.
- NA sends a request message (SOAP
envelope included in the HTTP entity body of the HTTP request) to B . The request
message corresponds to and is described by the input message in the WSDL
request-response operation supported by B
.
- If B chooses not to send
the application response on the current back channel, then B sends an HTTP
response (via the HTTP back channel) with a status code of "202
Accepted". No SOAP envelope is included as part of this HTTP
response.
- NA sends a MakeConnection request
message (SOAP envelope included in the HTTP entity body of the HTTP
request) to B
containing a wsmc:MakeConnection element containing the same
MakeConnection anonymous URI identifying NA as in the wsa:ReplyTo addressing
property contained in the SOAP envelope of the original request message.
- B sends a response message (SOAP
envelope included in the HTTP entity body of the HTTP response) via the
HTTP back channel. The response message corresponds to and is described by
the output message in the WSDL request-response operation supported by B . If the HTTP
response in step 5 does not contain a SOAP envelope, and if there is no
failure, then the HTTP response must not contain an entity body and the
status code must be 202.
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:
- Through
some mechanism, A
is provided an EPR for NB
- this EPR uses an instance of a MakeConnection anonymous URI that identifies
NB , and NB is provided the
EPR for A .
- NB sends a MakeConnection request
message (SOAP envelope included in the HTTP entity body of the HTTP
request) to A
containing a wsmc:MakeConnection element containing the same
MakeConnection anonymous URI identifying NB as in the EPR for NB .
- A sends a response message (SOAP
envelope included in the HTTP entity body of the HTTP response) via the
back channel. The response message corresponds to and is described by the
input message in the WSDL operation supported by NB .
- In the
case of a request-response operation, NB
sends a request message (SOAP envelope included in the HTTP entity body of
the HTTP request) to A
. The request message corresponds to and is described by the output
message in the WSDL request-response operation supported by NB .
- A sends an HTTP response via the
back channel with a status code of 202 Accepted. No SOAP envelope is
included as part of the HTTP response.
Note: In step 3 above, if NB encounters an
infrastructure level fault resulting from the processing the response 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: |
|
|
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=pass, false=fail |
|
Test Control: |
|
Test Assertion: |
RSP2004a |
|
Description: |
|
|
Target: |
/wsil:testLog/wsil:messageLog/wsil:message
(
$req1/wsil:messageContents/*:Envelope[not(*:Body/wsmc:MakeConnection) and
fn:starts-with(xsd:string(./*:Header/wsa:ReplyTo/wsa:Address),
'http://docs.oasis-open.org/ws-rx/wsmc/200702/anonymous?id=') ] and
//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 |
/wsil:testLog/wsil:messageLog/wsil:message
[@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)]) and
not (./wsil:messageContents/*:Envelope/*:Body/wsmc:MakeConnection )] |
|
co-Target: myOpBinding |
//wsil:descriptionFile/wsdl:definitions/wsdl:binding
[.//*[@style = 'rpc']]/wsdl:operation[wsdl:input and
wsdl:output][@name = fn:local-name-from-QName(node-name($myRequestMsg//*:Body/*[1]))] |
|
Predicate: |
$myRequestMsg[@conversation
= $target/@conversation] or (some $req2 in $target/preceding::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 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). 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:
The reported outcomes
have the following meaning:
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: |
|
|
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=pass, false=fail |
|
Test Control: |
|
Test Assertion: |
RSP2004b |
|
Description: |
|
|
Target: |
/wsil:testLog/wsil:messageLog/wsil:message
( $req1/wsil:messageContents/*:Envelope[not(*:Body/wsmc:MakeConnection)
and fn:starts-with(xsd:string(./*:Header/wsa:ReplyTo/wsa:Address),
'http://docs.oasis-open.org/ws-rx/wsmc/200702/anonymous?id=') ] and ] |
|
co-Target: myRequestMsg |
/wsil:testLog/wsil:messageLog/wsil:message
|
|
co-Target: myOpBinding |
/wsil:testLog/wsil:descriptionFiles/wsil:descriptionFile/wsdl:definitions/wsdl:binding
[not(.//*[@style = 'rpc'])]/wsdl:operation 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 ] |
|
Predicate: |
$myRequestMsg[@conversation
= $target/@conversation] or (
$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 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). 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:
The reported outcomes
have the following meaning:
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: |
|
|
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: |
/wsil:testLog/wsil:messageLog/wsil:message/wsil:messageContents/*:Envelope[
|
|
Predicate: |
$target/../../@type = 'request' |
|
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). 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:
The reported outcomes
have the following meaning:
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:
|
5.1.3 Transmission of MakeConnection Faults
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: |
|
|
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=pass, false=fail |
|
Test Control: |
|
Test Assertion: |
RSP2050 |
|
Description: |
|
|
Target: |
/wsil:testLog/wsil:messageLog/wsil:message/wsil:messageContents/*:Envelope
|
|
Predicate: |
some $mc in
/wsil:testLog/wsil:messageLog/wsil:message/wsil:messageContents/*:Envelope[*:Body/wsmc:MakeConnection]
satisfies ($mc/*:Header/wsa:MessageID =
$target/*:Header/wsa:RelatesTo[@RelationshipType =
'http://www.w3.org/2005/08/addressing/reply' or not (@RelationshipType)] and |
|
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). 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:
The reported outcomes
have the following meaning:
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:
|
5.2 MakeConnection Addressing
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.
5.2.1 Addressing Variants
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: |
|
|
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: |
//wsil:messageContents/*:Envelope[*:Body/wsmc:MakeConnection] |
|
Predicate: |
*:Body/wsmc:MakeConnection/wsmc:Address |
|
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). 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:
The reported outcomes
have the following meaning:
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: |
|
|
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: |
//wsil:messageContents/*:Envelope[*:Body/wsmc:MakeConnection] |
|
Predicate: |
not (*:Body/wsmc:MakeConnection/wsrm:Identifier) |
|
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). 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:
The reported outcomes
have the following meaning:
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: |
|
|
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: |
//wsil:messageContents/*:Envelope[*:Body/wsmc:MakeConnection and not(*:Body/wsmc:MakeConnection/wsmc:Address)] |
|
Predicate: |
some $mcfault in
/wsil:testLog/wsil:messageLog/wsil:message/wsil:messageContents/*:Envelope[*:Body/*:Fault//*:Value[node()
= 'wsmc:MissingSelection']] satisfies |
|
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). 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:
The reported outcomes
have the following meaning:
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: |
|
|
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: |
//wsil:messageContents/*:Envelope[*:Body/wsmc:MakeConnection//wsrm:Identifier] |
|
Predicate: |
some $mcfault in /wsil:testLog/wsil:messageLog/wsil:message/wsil:messageContents/*:Envelope[*:Body/*:Fault//*:Value[node()
= 'wsmc:UnsupportedSelection']] satisfies |
|
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). 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:
The reported outcomes
have the following meaning:
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:
|
5.2.2 MakeConnection Anonymous URI
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: |
|
|
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: |
//wsil:messageContents/*:Envelope[*:Body/wsmc:MakeConnection] |
|
Predicate: |
fn:starts-with(xsd:string(*:Body/wsmc:MakeConnection/wsmc:Address), 'http://docs.oasis-open.org/ws-rx/wsmc/200702/anonymous?id=') |
|
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). 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:
The reported outcomes
have the following meaning:
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: |
|
|
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: |
/wsil:testLog/wsil:messageLog/wsil:message[fn:starts-with(xsd:string(.//*:Header/wsa:To), 'http://docs.oasis-open.org/ws-rx/wsmc/200702/anonymous?id=')] |
|
Predicate: |
@type = 'response' |
|
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). 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:
The reported outcomes
have the following meaning:
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: |
|
|
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: |
/wsil:testLog/wsil:messageLog/wsil:message[@type
= 'response' and .//*:Header/wsrm:Sequence][some $resp1 in . satisfies some
$req1 in /wsil:testLog/wsil:messageLog/wsil:message[@type = 'request' and
(@conversation = $resp1/@conversation or .//*:Header/wsa:MessageID =
$resp1//wsa:RelatesTo[@RelationshipType =
'http://www.w3.org/2005/08/addressing/reply' or not (@RelationshipType)]) and
.//*:Header/wsrm:Sequence ] satisfies fn:contains(xsd:string($req1//*:Header/wsa:ReplyTo/wsa:Address),
'anonymous') or not($req1//*:Header/wsa:ReplyTo)] |
|
Predicate: |
fn:starts-with(xsd:string(.//*:Header/wsa:To),
'http://docs.oasis-open.org/ws-rx/wsmc/200702/anonymous?id=') |
|
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). 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:
The reported outcomes
have the following meaning:
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: |
|
|
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: |
/wsil:testLog/wsil:messageLog/wsil:message/wsil:messageContents/*:Envelope
(fn:contains(xsd:string(*:Body/wsrm:CreateSequence/wsrm:Offer/wsrm:Endpoint/*:Address),
'anonymous') or ] |
|
Predicate: |
fn:starts-with(xsd:string(*:Body/wsrm:CreateSequence/wsrm:Offer/wsrm:Endpoint/*:Address), 'http://docs.oasis-open.org/ws-rx/wsmc/200702/anonymous?id=') |
|
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). 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:
The reported outcomes
have the following meaning:
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:
|
5.3 MakeConnection Fault Behavior
Section 4 of WS-MakeConnection describes how to map the properties
of the faults generated by WS-MakeConnection implementations to SOAP 1.2 and
1.1 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.
5.3.1 [Detail] Property Mapping
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: |
|
|
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: |
/wsil:testLog/wsil:messageLog/wsil:message/wsil:messageContents/soap11:Envelope[soap11:Body/soap11:Fault] |
|
Predicate: |
$target/soap11:Body/soap11:Fault/*:detail or not($target/soap11:Body//*:detail) |
|
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). 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:
The reported outcomes
have the following meaning:
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:
|
6. Secure Reliable Messaging
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:
- Web Services Reliable Messaging
1.2
- Web Services Make Connection
1.1
- WS-SecureConversation 1.4
- WS-SecurityPolicy 1.3
6.1 Initiating a Secure Sequence
6.1.1 Secure Context Identification
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.
6.1.2 Security Token References
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: |
|
|
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: |
/wsil:testLog/wsil:messageLog/wsil:message/wsil:messageContents/*:Envelope[*:Body/wsrm:CreateSequence/wsse:SecurityTokenReference]
|
|
Predicate: |
./*:Header/wsrm:UsesSequenceSTR |
|
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). 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:
The reported outcomes
have the following meaning:
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:
|
6.2 Signature Coverage
In a secure Sequence there exists both security and
interoperability issues around the inclusion of SOAP message elements within
signatures.
6.2.1 Single Signature
for Sequence Header and SOAP Body
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 RSP3100
|
Test Assertion
Analysis: |
|
|
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: |
RSP3100 |
|
Description: |
|
|
Target: |
/wsil:testLog/wsil:messageLog/wsil:message/wsil:messageContents/*:Envelope[*:Header/wsse:Security
and *:Header/wsrm:Sequence][ some $tgt in . satisfies some $csr in $tgt/preceding::*:Envelope[$tgt/*:Header/wsrm:Sequence/wsrm:Identifier
= *:Body/wsrm:CreateSequenceResponse/wsrm:Identifier] satisfies some $cs in
$tgt/preceding::*:Envelope[*:Body/wsrm:CreateSequence/wsse:SecurityTokenReference]
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: mysecureseq |
/wsil:testLog/wsil:messageLog/wsil:message/wsil:messageContents/*:Envelope[*:Body/wsrm:CreateSequenceResponse][$target/*:Header/wsrm:Sequence/wsrm:Identifier = *:Body/wsrm:CreateSequenceResponse/wsrm:Identifier and (some $cs in $target/preceding::*:Envelope[*:Body/wsrm:CreateSequence] satisfies (./../../@conversation = $cs/../../@conversation or *:Header/wsa:RelatesTo[@RelationshipType = 'http://www.w3.org/2005/08/addressing/reply' or not (@RelationshipType)] = $cs/*:Header/wsa:MessageID) and $cs/*:Body/wsrm:CreateSequence/wsse:SecurityTokenReference )] |
|
Predicate: |
some $ref in $target/*:Header/wsse:Security//ds:Signature//ds:Reference satisfies (fn:substring-after($ref/@URI, '#') = $target/*:Header/wsrm:Sequence/@wsu:Id or fn:substring-after($ref/@URI, '#') = $target/*:Header/@wsu:Id or fn:substring-after($ref/URI, '#') = $target/@wsu:Id) |
|
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. |
|
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). 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:
The reported outcomes
have the following meaning:
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 RSP3101
|
Test Assertion
Analysis: |
|
|
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: |
RSP3101 |
|
Description: |
|
|
Target: |
/wsil:testLog/wsil:messageLog/wsil:message/wsil:messageContents/*:Envelope[*:Header/wsse:Security
and *:Header/wsrm:Sequence] |
|
Prerequisite: |
RSP3100 |
|
Predicate: |
( some $ref in $target/*:Header/wsse:Security//ds:Signature//ds:Reference
satisfies fn:substring-after($ref/URI, '#') = $target/@wsu:Id ) or ( some
$ref in $target/*:Header/wsse:Security//ds:Signature//ds:Reference satisfies
( fn:substring-after($ref/@URI, '#') = $target/*:Body/@wsu:Id and (some $ref2
in $ref/../ds:Reference satisfies ( fn:substring-after($ref2/@URI, '#') =
$target/*:Header/@wsu:Id or fn:substring-after($ref/@URI, '#') =
$target/*:Header/wsrm:Sequence/@wsu:Id )) )) |
|
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). 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:
The reported outcomes
have the following meaning:
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
6.2.2 Signed Elements
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 RSP3110
|
Test Assertion
Analysis: |
|
|
General Notes: |
|
|
Coverage Assessment: |
|
|
Target Type: |
|
|
Test Target: |
|
|
Test co-Target(s): |
|
|
Test Prerequisite: |
|
|
Predicate: |
|
|
Prescription: |
mandatory |
|
Reporting: |
|
|
Test Control: |
|
Test Assertion: |
RSP3110 |
|
Description: |
|
|
Target: |
/wsil:testLog/wsil:messageLog/wsil:message/wsil:messageContents/*:Envelope[*:Body/wsrm:CloseSequence
or *:Body/wsrm:TerminateSequence or *:Body/wsrm:CreateSequenceResponse or
*:Body/wsrm:TerminateSequenceResponse or *:Body/wsrm:CloseSequenceResponse][
some $tgt in . satisfies some $csr in
/wsil:testLog/wsil:messageLog/wsil:message//*:Envelope[*:Body/wsrm:CreateSequenceResponse][$tgt/*:Body//wsrm:Identifier
= *:Body/wsrm:CreateSequenceResponse/wsrm:Identifier] satisfies some $cs in
$tgt/preceding::*:Envelope[*:Body/wsrm:CreateSequence/wsse:SecurityTokenReference]
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)] |
|
Predicate: |
$target/*:Header/wsse:Security[ some $ref in .//ds:Signature//ds:Reference satisfies (fn:substring-after($ref/@URI, '#') = $target/*:Body/@wsu:Id or fn:substring-after($ref/URI, '#') = $target/@wsu:Id ) ] |
|
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. |
|
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). 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:
The reported outcomes
have the following meaning:
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 RSP3114
|
Test Assertion
Analysis: |
|
|
General Notes: |
|
|
Coverage Assessment: |
|
|
Target Type: |
|
|
Test Target: |
|
|
Test co-Target(s): |
|
|
Test Prerequisite: |
|
|
Predicate: |
|
|
Prescription: |
mandatory |
|
Reporting: |
(default) |
|
Test Control: |
|
Test Assertion: |
RSP3114 |
|
Description: |
|
|
Target: |
/wsil:testLog/wsil:messageLog/wsil:message/wsil:messageContents/*:Envelope[*:Header/wsrm:AckRequested][
some $tgt in . satisfies some $csr in /wsil:testLog/wsil:messageLog/wsil:message//*:Envelope[*:Body/wsrm:CreateSequenceResponse][$tgt/*:Body//wsrm:Identifier
= *:Body/wsrm:CreateSequenceResponse/wsrm:Identifier] satisfies some $cs in
$tgt/preceding::*:Envelope[*:Body/wsrm:CreateSequence/wsse:SecurityTokenReference]
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)] |
|
Prerequisite: |
RSP3110 |
|
Predicate: |
$target/*:Header/wsse:Security[ some $ref in .//ds:Signature//ds:Reference satisfies fn:substring-after($ref/@URI, '#') = $target/*:Header/wsrm:AckRequested/@wsu:Id or fn:substring-after($ref/@URI, '#') = $target/*:Header/@wsu:Id or fn:substring-after($ref/URI, '#') = $target/@wsu:Id ] |
|
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. |
|
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). 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:
The reported outcomes
have the following meaning:
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 RSP3117
|
Test Assertion
Analysis: |
|
|
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: |
RSP3117 |
|
Description: |
|
|
Target: |
/wsil:testLog/wsil:messageLog/wsil:message/wsil:messageContents/soap12:Envelope[soap12:Body/soap12:Fault][ some $tgt in . satisfies some $csr in /wsil:testLog/wsil:messageLog/wsil:message//*:Envelope[*:Body/wsrm:CreateSequenceResponse][$tgt/*:Body/soap12:Fault/soap12:Detail//wsrm:Identifier = *:Body/wsrm:CreateSequenceResponse/wsrm:Identifier] satisfies some $cs in $tgt/preceding::*:Envelope[*:Body/wsrm:CreateSequence/wsse:SecurityTokenReference] 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)] |
|
Predicate: |
$target/*:Header/wsse:Security[ some $ref in .//ds:Signature//ds:Reference satisfies (fn:substring-after($ref/@URI, '#') = $target/soap12:Body/@wsu:Id or fn:substring-after($ref/URI, '#') = $target/@wsu:Id ) ] |
|
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. |
|
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). 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:
The reported outcomes
have the following meaning:
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
6.2.3 Single Signature
for SOAP 1.1 Fault and SequenceFault Header
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 RSP3120
|
Test Assertion
Analysis: |
|
|
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: |
RSP3120 |
|
Description: |
|
|
Target: |
/wsil:testLog/wsil:messageLog/wsil:message/wsil:messageContents/soap11:Envelope[soap11:Header/wsrm:SequenceFault][
some $tgt in . satisfies some $fms in
preceding::soap11:Envelope[./../../@conversation = $tgt/../../@conversation
or $tgt/soap11:Header/wsa:RelatesTo[@RelationshipType =
'http://www.w3.org/2005/08/addressing/reply' or not (@RelationshipType)] =
./soap11:Header/wsa:MessageID] satisfies some $csr in
$fms/preceding::*:Envelope[*:Body/wsrm:CreateSequenceResponse][$fms/soap11:Header/wsrm:Sequence/wsrm:Identifier
= *:Body/wsrm:CreateSequenceResponse/wsrm:Identifier] satisfies some $cs in
$csr/preceding::*:Envelope[*:Body/wsrm:CreateSequence/wsse:SecurityTokenReference]
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)] |
|
Predicate: |
$target/soap11:Header/wsse:Security[ some $ref in .//ds:Signature//ds:Reference satisfies ( fn:substring-after($ref/@URI, '#') = $target/soap11:Header/wsrm:SequenceFault/@wsu:Id or fn:substring-after($ref/@URI, '#') = $target/soap11:Header/@wsu:Id or fn:substring-after($ref/URI, '#') = $target/@wsu:Id ) ] |
|
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). 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:
The reported outcomes
have the following meaning:
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 RSP3121
|
Test Assertion
Analysis: |
|
|
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: |
RSP3121 |
|
Description: |
|
|
Target: |
/wsil:testLog/wsil:messageLog/wsil:message/wsil:messageContents/soap11:Envelope[soap11:Header/wsrm:SequenceFault]
|
|
Prerequisite: |
RSP3120 |
|
Predicate: |
$target/soap11:Header/wsse:Security[ some $ref in .//ds:Signature//ds:Reference satisfies ( ( fn:substring-after($ref/@URI, '#') = $target/soap11:Header/wsrm:SequenceFault/@wsu:Id or fn:substring-after($ref/@URI, '#') = $target/soap11:Header/@wsu:Id or fn:substring-after($ref/URI, '#') = $target/@wsu:Id ) and (some $ref2 in $ref/../ds:Reference satisfies ( fn:substring-after($ref2/@URI, '#') = $target/soap11:Body/@wsu:Id or fn:substring-after($ref2/URI, '#') = $target/@wsu:Id ))) ] |
|
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). 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:
The reported outcomes
have the following meaning:
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
6.3
Secure Use of MakeConnection
This Profile places additional requirements on the composition of
MakeConnection, WS-SecureConversation, and WS-ReliableMessaging.
6.3.1 Security Context for MakeConnection
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.
6.3.2 Signing the MessagePending header
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 security context, if any, that protects
the SOAP Body of the ENVELOPE. TESTABLE RSP3201
|
Test Assertion
Analysis: |
|
|
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: |
/wsil:testLog/wsil:messageLog/wsil:message/wsil:messageContents/*:Envelope[*:Header/wsse:Security
and *:Header/wsmc:MessagePending and (some $tgt in . satisfies some $ref in
*:Header/wsse:Security//ds:Signature//ds:Reference satisfies
(fn:substring-after($ref/@URI, '#') = $tgt/*:Body/@wsu:Id or
fn:substring-after($ref/URI, '#') = $tgt/@wsu:Id ))] |
|
Predicate: |
( some $ref in
$target/*:Header/wsse:Security//ds:Signature//ds:Reference satisfies
fn:substring-after($ref/URI, '#') = $target/@wsu:Id ) or ( some $ref in
$target/*:Header/wsse:Security//ds:Signature//ds:Reference satisfies (
fn:substring-after($ref/@URI, '#') = $target/*:Body/@wsu:Id and (some $ref2
in $ref/../ds:Reference satisfies ( fn:substring-after($ref2/@URI, '#') =
$target/*:Header/wsmc:MessagePending/@wsu:Id))) ) |
|
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). 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:
The reported outcomes
have the following meaning:
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:
|
6.4
Replay Detection
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.
6.4.1 Unique Timestamp Values
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: |
|
|
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: |
/wsil:testLog/wsil:messageLog/wsil:message/wsil:messageContents/*:Envelope[*:Header/wsrm:Sequence][*:Header/wsse:Security] |
|
co-Target: mysecureseq |
/wsil:testLog/wsil:messageLog/wsil:message/wsil:messageContents/*:Envelope[*:Body/wsrm:CreateSequenceResponse][$target/*:Header/wsrm:Sequence/wsrm:Identifier = *:Body/wsrm:CreateSequenceResponse/wsrm:Identifier and (some $cs in /wsil:testLog/wsil:messageLog/wsil:message/wsil:messageContents/*:Envelope[*:Body/wsrm:CreateSequence] satisfies (./../../@conversation = $cs/../../@conversation or *:Header/wsa:RelatesTo[@RelationshipType = 'http://www.w3.org/2005/08/addressing/reply' or not (@RelationshipType)] = $cs/*:Header/wsa:MessageID) and $cs/*:Body/wsrm:CreateSequence/wsse:SecurityTokenReference )] |
|
Predicate: |
$target/*:Header/wsse:Security/wsu:Timestamp |
|
Reporting: |
true=passed,
false=failed |
|
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). 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:
The reported outcomes
have the following meaning:
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: |
|
|
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: |
/wsil:testLog/wsil:messageLog/wsil:message/wsil:messageContents/*:Envelope[*:Header/wsrm:Sequence = preceding::*:Envelope/*:Header/wsrm:Sequence][*:Header/wsse:Security] |
|
co-Target: mysecureseq |
/wsil:testLog/wsil:messageLog/wsil:message/wsil:messageContents/*:Envelope[*:Body/wsrm:CreateSequenceResponse][$target/*:Header/wsrm:Sequence/wsrm:Identifier = *:Body/wsrm:CreateSequenceResponse/wsrm:Identifier and (some $cs in $target/preceding::*:Envelope[*:Body/wsrm:CreateSequence] satisfies (./../../@conversation = $cs/../../@conversation or *:Header/wsa:RelatesTo[@RelationshipType = 'http://www.w3.org/2005/08/addressing/reply' or not (@RelationshipType)] = $cs/*:Header/wsa:MessageID) and $cs/*:Body/wsrm:CreateSequence/wsse:SecurityTokenReference )] |
|
Predicate: |
(not
($target/*:Header/wsse:Security/wsu:Timestamp) and not
(preceding::*:Envelope[*:Header/wsrm:Sequence =
$target/*:Header/wsrm:Sequence][*:Header/wsse:Security/wsu:Timestamp])) or
($target/*:Header/wsse:Security/wsu:Timestamp and not
(preceding::*:Envelope[*:Header/wsrm:Sequence =
$target/*:Header/wsrm:Sequence]/*:Header/wsse:Security/wsu:Timestamp =
$target/*:Header/wsse:Security/wsu:Timestamp )) |
|
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). 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:
The reported outcomes have the following meaning:
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:
|
Appendix A: Referenced Specifications
The following
specifications' requirements are incorporated into the Profile by reference,
except where superseded by the Profile:
- Web
Services Reliable Messaging 1.2
- Internationalized
Resource Identifiers (IRIs)
- Web Services
Addressing 1.0 - SOAP Binding
- WS-SecureConversation
1.4
- Web
Services Make Connection 1.1
- SOAP
Request-Response Message Exchange Pattern
- WSDL 1.1
Port Types
- WS-SecurityPolicy
1.3
Appendix B: Extensibility Points
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; their use may affect interoperability, and
may require private agreement between the parties to a Web service.
In Web
Services Reliable Messaging 1.2:
- E0001
- CreateSequence
element and attribute extensions - Extending
CreateSequence, via additional elements or attributes, is the primary
mechanism for negotiating supplemental semantics to be applied to the
requested and/or offered Sequence. Note this extensiblity point does not
cover the pre-defined use of the
/wsrm:CreateSequence/wsse:SecurityTokenReference element.
- E0002
- CreateSequenceResponse
element and attribute extensions - Extending
CreateSequenceResponse, via additional elements or attributes, may be used
to signal the acceptance of the supplemental semantics requested by the
use of E0001 or it may be used in its own right to request or signal
additional semantics to be applied to either requested and/or offered
Sequence.
- E0003
- CloseSequence
element and attribute extensions - The CloseSequence
element may be extended via additional elements or attributes to indicate
the use of supplemental semantics or options in the closure of the
Sequence.
- E0004
- CloseSequenceResponse
element and attribute extensions - The
CloseSequenceResponse element may be extended via additional elements or
attributes to indicate the use of supplemental semantics or options in the
closure of the Sequence.
- E0005
- TerminateSequence
element and attribute extensions - The TerminateSequence
element may be extended via additional elements or attributes to indicate
the use of supplemental semantics or options in the termination of the
Sequence.
- E0006
- TerminateSequenceResponse
element and attribute extensions - The
TerminateSequenceResponse element may be extended via additional elements
or attributes to indicate the use of supplemental semantics or options in
the termination of the Sequence.
- E0007
- Sequence element
and attribute extensions - The Sequence header element may
be extended via additional elements or attributes to convey supplemental
semantics or options that apply to the Sequence identified by the header.
- E0008
- AckRequested
element and attribute extensions - The AckRequest header
element may be extended via additional elements or attributes to convey
supplemental semantics or options that apply to the request.
- E0009
- SequenceAcknowledgment
element and attribute extensions - The
SequenceAcknowledgment header element may be extended via additional
elements or attributes to convey supplemental semantics or options that
apply to the acknowledgment.
- E0010
- SequenceFault
element and attribute extensions - The SequenceFault
element may be extended via additional elements or attributes to convey
supplemental semantics or options that apply to the fault.
- E0011
- SecrutiyContextToken
element and attribute extensions - The
SecurityContextToken element may be extended via additional elements or
attributes to indicate the use of supplemental semantics or options that
apply to the security context identified by the token.
In Web
Services Make Connection 1.1:
- E0012
- MakeConnection
element and attribute extensions - The MakeConnection
element may be extended via additional elements or attributes to indicate
the use of supplemental semantics or options that apply to the request.
- E0013
- Attribute
extensions to the MakeConnection Address - The
/wsmc:MakeConnection/wsmc:Address element may be extended via additional
attributes to indicate the use of supplemental semantics or options that
apply to this instance of the MakeConnection Anonymous URI
- E0014
- MessagePending
element and attribute extensions - The MessagePending
header element may be extended via additional elements or attributes to
convey supplemental semantics or options that apply to the indication of
pending messages.
Appendix C: Normative
References
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
WS-I Basic
Profile 1.0 http://www.ws-i.org/Profiles/BasicProfile-1.0-2004-04-16.html,
K. Ballinger et al April 2004
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
Appendix D: Acknowledgements
This document is
the work of the WS-I Reliable Secure Profile Working Group.