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 Draft; it has been accepted by the Working Group as
reflecting the current state of discussions. It is a work in
progress, and should not be considered authoritative or 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.2.
MakeConnection Addressing
5.2.1.
Addressing Variants
5.2.2.
MakeConnection Anonymous URI
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:
TESTING-RELEASE-NOTES
Note Item: |
Release Notes : 2009-07-03
|
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" or "NOT TESTABLE XPATH".
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.
A subsequent version may cover those 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 work 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". 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 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:- 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.
Conformance to the Profile is defined by adherence to the
set of
requirements defined for a specific
target, within the
scope of the
Profile. This section explains these terms and describes how
conformance is defined and used.
Requirements state the criteria for conformance to the
Profile. They typically refer to an existing specification and
embody refinements, amplifications, interpretations and
clarifications to it in order to improve interoperability. All
requirements in the Profile are considered normative, and those
in the specifications it references that are in-scope (see
"Conformance Scope") should likewise be considered normative.
When requirements in the Profile and its referenced
specifications contradict each other, the Profile's
requirements take precedence for purposes of Profile
conformance.
Requirement levels, using
RFC2119 language (e.g.,
MUST, MAY, SHOULD) indicate the nature of the requirement and its
impact on conformance. Each requirement is individually identified
(e.g., R9999) for convenience.
For example;
R9999 Any
WIDGET SHOULD be round in shape.
This requirement is identified by "R9999", applies to the
target WIDGET (see below), and places a conditional
requirement upon widgets; 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).
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)
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.
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
RSP0001
Test Assertion Analysis: |
RSP0001
|
General Notes: |
NOTE1:
the actual test target is the observable artifact under test. NOTE2:
given partial coverage, probably better to test for the negative case:
predicate=true means failure. Inthe error message (or warning message):
mention what to look for NOTE3: need to finalize the expected
fault-message correlation. NOTE4: test env alignment: use same
unrecognizable extension. |
Coverage Assessment: |
partial (only some extension cases, and some messages types to be tested, and also can't sort out the real cause of the Fault) |
Target Type: |
ENVELOPE |
Test Target: |
for a soap:Envelope (not just wsrm:CreateSequence) with a special extension that is known to be NOT understood |
Test co-Target(s): |
|
Test Prerequisite: |
|
Predicate: |
there is a Fault in response to the message with extension. |
Prescription: |
mandatory |
Reporting: |
true=warning, false=undetermined |
Test Control: |
Align
with unrecognizable extension expected in the TA. Generate a
wsrm:CreateSequence message that makes use of the unrecognizable
extension. Require response for anonymous URI. |
Test Assertion: |
RSP0001
|
Description: |
|
Target: |
/wsil:testLog/wsil:messageLog/wsil:message/wsil:messageContents/*:Envelope[
some $elt in .//* satisfies
string(fn:namespace-uri-from-QName(node-name($elt))) = 'http://dummy.examples.org/unknown/nmspace'
] |
co-Target:
myresponse |
/wsil:testLog/wsil:messageLog/wsil:message[
(@type = 'response' and @conversation = $target/../../@conversation) or
(.//*:Envelope/*:Header/wsa:RelatesTo[@RelationshipType =
'http://www.w3.org/2005/08/addressing/reply' or not
(@RelationshipType)] = $target/*:Header/wsa:MessageID) ]
/wsil:messageContents/*:Envelope |
Predicate: |
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: |
|
HELP - GLOSSARY
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:
passedfailedwarningnotApplicablenotRelevantmissingInputundeterminedSee
the "reporting" item for the meaning of these results. |
Cotarget:
|
[markup:
testAssertion/cotarget ] (optional)Artifact that is related to the
target, and that needs be accessed for the testing. Identified by an
XPath expression that may refer to the related target node using the
variable '$target'. For example, the target can be a SOAP message and
the cotarget the WSDL file that describes this SOAP message.A cotarget
must have a @name attribute that identifies it. The value of this
attribute can be used as a variable (when prepending '$' to it) by
subsequently defined cotargets, prerequisite and predicate. |
Prerequisite:
|
[markup:
testAssertion/@preReq ] (optional)[markup: testAssertion/prerequisite ]
(optional)The pre-condition for evaluating this Test Assertion on this
target. If the prerequisite evaluates to "false" then the target does
not qualify for this Test Assertion (the test report is
"notRelevant")The first part (preReq attribute) is an enumeration of
Test Assertion IDs. Each one of the prerequisite TAs must either use
the same target (e.g. SOAP Envelope, or WSDL binding, etc.) as this TA,
or a target that is of a more general type than the main TA target. The
target must "pass" each one of these prerequisite TAs in order to
qualify for this TA.(e.g. the target of TA t1 can be a WSDL binding
while the target of a TA t2 prerequisite of t1, can be the entire WSDL
file).The second part ("prerequisite" element) is an XPath (boolean)
expression of the same nature as the predicate. If present, it must
evaluate to "true" for the target to qualify. If it fails, the result
for the current TA in the report will be "notRelevant". Otherwise, the
target can be further evaluated by the predicate of the main TA. The
expression may refer to the target explicitly using the variable name
"$target", or to any cotarget using its name as variable name ($[name]). |
Predicate:
|
[markup:
testAssertion/predicate] required element]A logical expression that
evaluates whether this target is fulfilling the profile requirement
addressed by this test Assertion. By default: - A result of true means
the requirement is fulfilled (reported as a "passed" in the test
report). - A result of false means the requirement is violated
(reported as a "failed" in the test report). However, in some cases and
for testability reasons, the predicate may be designed as a partial
indicator e.g. only indicates some cases of fulfillment, or some cases
of violation. As a result, when "true" indicates fulfillment it may be
that "false" is unconclusive, or conversely "false" will indicate
violation, but "true" is unconclusive. In such cases, the "Reporting"
element specifies the meaning of the predicate result w/r to the
profile requirement.The predicate expression implicitly refers to the
target (whic is its "XPath context") although it may explicitly refer
to it using the variable name "$target". It may refer to any cotarget
using its name as variable name ($[name]). |
Prescription:
|
[markup: testAssertion/prescription/@level ] (required)
Conveys the level of prescription associated with the profile requirement.
At least three values may be used:
mandatory: maps to RFC2119 keywords MUST, MUST NOT, SHALL,
SHALL NOT, REQUIRED (and sometimes MAY NOT) preferred: maps to RFC2119 keywords SHOULD, SHOULD NOT,
RECOMMENDED, NOT RECOMMENDED permitted: maps to RFC2119 keywords MAY, OPTIONAL. |
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: @true attribute: may take values among
{passed, failed, warning, undetermined} (default is 'passed') @false
attribute: may take values among {passed, failed, warning,
undetermined} (default is 'failed') The reported outcomes have the
following meaning:passed: the target passes the test and can be
considered as fulfilling the profile feature.failed: the target fails
the test and can be considered as violating (or not exhibiting) the
profile feature.warning: the test result is inconclusive. There is a
possibility of profile requirement violation, that deserved further
investigation.undetermined: the test result is inconclusive for this
predicate value.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:notRelevant: the
target failed the prerequisite condition and therefore does not qualify
for further testing (i.e. the predicate expression is NOT evaluated on
it).missingInput: a cotarget expression returned an empty node
set.notApplicable: this target was not even selected by the target
XPath expression, while being of the same general artifact type (e.g.
message type). |
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: |
RSP0900
|
General Notes: |
When
passing around EPRs (that do not have embedded WSDL) it is not clear
which version of SOAP should be used when talking to that EPR. This
requirement tries to answer this question at least with respect to RM
Acks / AcksTo EPR by requiring the RMD to use the same SOAP version
that was used in the originating CS message. This means that the RMD
needs to save this information, where before this was not required |
Coverage Assessment: |
Good |
Target Type: |
ENVELOPE |
Test Target: |
A SOAP Envelope with a SeqAck Header |
Test co-Target(s): |
|
Test Prerequisite: |
|
Predicate: |
The
[target] has the same SeqID value and SOAP Envelope namespace as the
previous message that contains a CreateSequence or
CreateSequenceResponse. |
Prescription: |
mandatory |
Reporting: |
true=warning, false=passed |
Test Control: |
Run
a reliable request/response application message exchange. Create a
sequence using a CreateSequence that includes an Offer element. This
will ensure that the messages carrying the Acks in both directions are
using the correct SOAP namespace. |
Test Assertion: |
RSP0900
|
Description: |
This
test assertion takes as prerequisite RSP8001, a "base TA" that does
match any particular Rxxxx requirement, but matches fundamental
requirements from RSP: namely that an Envelope is either under SOAP 1.2
or SOAP 1.1 namespace. |
Target: |
/wsil:testLog/wsil:messageLog/wsil:message/wsil:messageContents/*:Envelope
[(*:Header/wsrm:SequenceAcknowledgement/wsrm:Identifier =
preceding::*:Envelope/*:Body/wsrm:CreateSequenceResponse/wsrm:Identifier)
or (*:Body/wsrm:CloseSequenceResponse/wsrm:Identifier =
preceding::*:Envelope/*:Body/wsrm:CreateSequenceResponse/wsrm:Identifier)
or (*:Body/wsrm:TerminateSequenceResponse/wsrm:Identifier =
preceding::*:Envelope/*:Body/wsrm:CreateSequenceResponse/wsrm:Identifier)
or (*:Body/wsrm:CreateSequenceResponse)] |
Prerequisite: |
RSP8001; |
Predicate: |
some $csr in /wsil:testLog/wsil:messageLog//*:Envelope
[*:Body/wsrm:CreateSequenceResponse/wsrm:Identifier = $target/*:Header/wsrm:SequenceAcknowledgement/wsrm:Identifier or
(*:Body/wsrm:CreateSequenceResponse/wsrm:Identifier = $target/*:Body/wsrm:*/wsrm:Identifier)]
satisfies
some $cs in $csr/preceding::*:Envelope[*:Body/wsrm:CreateSequence] satisfies
(($cs/../../@conversation = $csr/../../@conversation) or
($csr/*:Header/wsa:RelatesTo[@RelationshipType = 'http://www.w3.org/2005/08/addressing/reply' or
not (@RelationshipType)] = $cs/*:Header/wsa:MessageID)) and
fn:namespace-uri-from-QName(fn:node-name($target)) = fn:namespace-uri-from-QName(fn:node-name($cs)) |
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: |
|
HELP - GLOSSARY
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:
passedfailedwarningnotApplicablenotRelevantmissingInputundeterminedSee
the "reporting" item for the meaning of these results. |
Cotarget:
|
[markup:
testAssertion/cotarget ] (optional)Artifact that is related to the
target, and that needs be accessed for the testing. Identified by an
XPath expression that may refer to the related target node using the
variable '$target'. For example, the target can be a SOAP message and
the cotarget the WSDL file that describes this SOAP message.A cotarget
must have a @name attribute that identifies it. The value of this
attribute can be used as a variable (when prepending '$' to it) by
subsequently defined cotargets, prerequisite and predicate. |
Prerequisite:
|
[markup:
testAssertion/@preReq ] (optional)[markup: testAssertion/prerequisite ]
(optional)The pre-condition for evaluating this Test Assertion on this
target. If the prerequisite evaluates to "false" then the target does
not qualify for this Test Assertion (the test report is
"notRelevant")The first part (preReq attribute) is an enumeration of
Test Assertion IDs. Each one of the prerequisite TAs must either use
the same target (e.g. SOAP Envelope, or WSDL binding, etc.) as this TA,
or a target that is of a more general type than the main TA target. The
target must "pass" each one of these prerequisite TAs in order to
qualify for this TA.(e.g. the target of TA t1 can be a WSDL binding
while the target of a TA t2 prerequisite of t1, can be the entire WSDL
file).The second part ("prerequisite" element) is an XPath (boolean)
expression of the same nature as the predicate. If present, it must
evaluate to "true" for the target to qualify. If it fails, the result
for the current TA in the report will be "notRelevant". Otherwise, the
target can be further evaluated by the predicate of the main TA. The
expression may refer to the target explicitly using the variable name
"$target", or to any cotarget using its name as variable name ($[name]). |
Predicate:
|
[markup:
testAssertion/predicate] required element]A logical expression that
evaluates whether this target is fulfilling the profile requirement
addressed by this test Assertion. By default: - A result of true means
the requirement is fulfilled (reported as a "passed" in the test
report). - A result of false means the requirement is violated
(reported as a "failed" in the test report). However, in some cases and
for testability reasons, the predicate may be designed as a partial
indicator e.g. only indicates some cases of fulfillment, or some cases
of violation. As a result, when "true" indicates fulfillment it may be
that "false" is unconclusive, or conversely "false" will indicate
violation, but "true" is unconclusive. In such cases, the "Reporting"
element specifies the meaning of the predicate result w/r to the
profile requirement.The predicate expression implicitly refers to the
target (whic is its "XPath context") although it may explicitly refer
to it using the variable name "$target". It may refer to any cotarget
using its name as variable name ($[name]). |
Prescription:
|
[markup: testAssertion/prescription/@level ] (required)
Conveys the level of prescription associated with the profile requirement.
At least three values may be used:
mandatory: maps to RFC2119 keywords MUST, MUST NOT, SHALL,
SHALL NOT, REQUIRED (and sometimes MAY NOT) preferred: maps to RFC2119 keywords SHOULD, SHOULD NOT,
RECOMMENDED, NOT RECOMMENDED permitted: maps to RFC2119 keywords MAY, OPTIONAL. |
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: @true attribute: may take values among
{passed, failed, warning, undetermined} (default is 'passed') @false
attribute: may take values among {passed, failed, warning,
undetermined} (default is 'failed') The reported outcomes have the
following meaning:passed: the target passes the test and can be
considered as fulfilling the profile feature.failed: the target fails
the test and can be considered as violating (or not exhibiting) the
profile feature.warning: the test result is inconclusive. There is a
possibility of profile requirement violation, that deserved further
investigation.undetermined: the test result is inconclusive for this
predicate value.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:notRelevant: the
target failed the prerequisite condition and therefore does not qualify
for further testing (i.e. the predicate expression is NOT evaluated on
it).missingInput: a cotarget expression returned an empty node
set.notApplicable: this target was not even selected by the target
XPath expression, while being of the same general artifact type (e.g.
message type). |
R0901
Unless otherwise specified (e.g. through some WSDL or WS-Policy designator), the
RMS
of an Offered Sequence MUST send Sequence Lifecycle Messages destined
to the CreateSequence/Offer/Endpoint EPR with the same SOAP version
that was used in the CreateSequence message. TESTABLE
RSP0901
Test Assertion Analysis: |
RSP0901
|
General Notes: |
The
possible lifecycle messages covered by this requirement are:
CloseSequence and TerminateSequence. Similar to R0900, its not clear
what version of SOAP should be used when sending messages to the
CS/Offer/Endpoint EPR. This requirement would require an RMD to save
the SOAP version of the CS and use that same version of any Close or
Terminate Sequence messages sent to the CS/Offer/Endpoint EPR |
Coverage Assessment: |
Good(should be able to cover all cases) |
Target Type: |
ENVELOPE |
Test Target: |
A CloseSequence or TerminateSequence message |
Test co-Target(s): |
|
Test Prerequisite: |
|
Predicate: |
For
any message that contains a CloseSequence or TerminateSequence element
in the Body, extract the SeqID value and find (in a previous message) a
CreateSequence, or CreateSequenceResponse, that references this SeqID.
The namespace of the SOAP Envelope elements of these messages MUST be
the same |
Prescription: |
mandatory |
Reporting: |
true=passed, false=failed |
Test Control: |
Run
a reliable request/response application message exchange. Create a
sequence using a CreateSequence that includes an Offer element. To
ensure the CloseSequence message is tested we could make sure there's a
gap in the request sequence then have the RMS send a Close. This should
cause the service to close the response sequence before it terminates
it. Question: is there a RSP requirement that covers the non-Offered
case? Seems like there should be but I can't find it |
Test Assertion: |
RSP0901
|
Description: |
This
test assertion takes as prerequisite RSP8001, a "base TA" that does
match any particular Rxxxx requirement, but matches fundamental
requirements from RSP: namely that an Envelope is either under SOAP 1.2
or SOAP 1.1 namespace. |
Target: |
/wsil:testLog/wsil:messageLog/wsil:message/wsil:messageContents/*:Envelope
[(*:Header/wsrm:AckRequested/wsrm:Identifier =
preceding::*:Envelope/*:Body/wsrm:CreateSequence/wsrm:Offer/wsrm:Identifier)
or (*:Body/wsrm:CloseSequence/wsrm:Identifier =
preceding::*:Envelope/*:Body/wsrm:CreateSequence/wsrm:Offer/wsrm:Identifier)
or (*:Body/wsrm:TerminateSequence/wsrm:Identifier =
preceding::*:Envelope/*:Body/wsrm:CreateSequence/wsrm:Offer/wsrm:Identifier)
] |
Prerequisite: |
RSP8001; |
Predicate: |
some $cs in preceding::*:Envelope
[*:Body/wsrm:CreateSequence/wsrm:Offer/wsrm:Identifier = $target/*:Header/wsrm:AckRequested/wsrm:Identifier or
(*:Body/wsrm:CreateSequence/wsrm:Offer/wsrm:Identifier = $target/*:Body/wsrm:*/wsrm:Identifier)]
satisfies
fn:namespace-uri-from-QName(fn:node-name($target)) = fn:namespace-uri-from-QName(fn:node-name($cs))
|
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: |
|
HELP - GLOSSARY
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:
passedfailedwarningnotApplicablenotRelevantmissingInputundeterminedSee
the "reporting" item for the meaning of these results. |
Cotarget:
|
[markup:
testAssertion/cotarget ] (optional)Artifact that is related to the
target, and that needs be accessed for the testing. Identified by an
XPath expression that may refer to the related target node using the
variable '$target'. For example, the target can be a SOAP message and
the cotarget the WSDL file that describes this SOAP message.A cotarget
must have a @name attribute that identifies it. The value of this
attribute can be used as a variable (when prepending '$' to it) by
subsequently defined cotargets, prerequisite and predicate. |
Prerequisite:
|
[markup:
testAssertion/@preReq ] (optional)[markup: testAssertion/prerequisite ]
(optional)The pre-condition for evaluating this Test Assertion on this
target. If the prerequisite evaluates to "false" then the target does
not qualify for this Test Assertion (the test report is
"notRelevant")The first part (preReq attribute) is an enumeration of
Test Assertion IDs. Each one of the prerequisite TAs must either use
the same target (e.g. SOAP Envelope, or WSDL binding, etc.) as this TA,
or a target that is of a more general type than the main TA target. The
target must "pass" each one of these prerequisite TAs in order to
qualify for this TA.(e.g. the target of TA t1 can be a WSDL binding
while the target of a TA t2 prerequisite of t1, can be the entire WSDL
file).The second part ("prerequisite" element) is an XPath (boolean)
expression of the same nature as the predicate. If present, it must
evaluate to "true" for the target to qualify. If it fails, the result
for the current TA in the report will be "notRelevant". Otherwise, the
target can be further evaluated by the predicate of the main TA. The
expression may refer to the target explicitly using the variable name
"$target", or to any cotarget using its name as variable name ($[name]). |
Predicate:
|
[markup:
testAssertion/predicate] required element]A logical expression that
evaluates whether this target is fulfilling the profile requirement
addressed by this test Assertion. By default: - A result of true means
the requirement is fulfilled (reported as a "passed" in the test
report). - A result of false means the requirement is violated
(reported as a "failed" in the test report). However, in some cases and
for testability reasons, the predicate may be designed as a partial
indicator e.g. only indicates some cases of fulfillment, or some cases
of violation. As a result, when "true" indicates fulfillment it may be
that "false" is unconclusive, or conversely "false" will indicate
violation, but "true" is unconclusive. In such cases, the "Reporting"
element specifies the meaning of the predicate result w/r to the
profile requirement.The predicate expression implicitly refers to the
target (whic is its "XPath context") although it may explicitly refer
to it using the variable name "$target". It may refer to any cotarget
using its name as variable name ($[name]). |
Prescription:
|
[markup: testAssertion/prescription/@level ] (required)
Conveys the level of prescription associated with the profile requirement.
At least three values may be used:
mandatory: maps to RFC2119 keywords MUST, MUST NOT, SHALL,
SHALL NOT, REQUIRED (and sometimes MAY NOT) preferred: maps to RFC2119 keywords SHOULD, SHOULD NOT,
RECOMMENDED, NOT RECOMMENDED permitted: maps to RFC2119 keywords MAY, OPTIONAL. |
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: @true attribute: may take values among
{passed, failed, warning, undetermined} (default is 'passed') @false
attribute: may take values among {passed, failed, warning,
undetermined} (default is 'failed') The reported outcomes have the
following meaning:passed: the target passes the test and can be
considered as fulfilling the profile feature.failed: the target fails
the test and can be considered as violating (or not exhibiting) the
profile feature.warning: the test result is inconclusive. There is a
possibility of profile requirement violation, that deserved further
investigation.undetermined: the test result is inconclusive for this
predicate value.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:notRelevant: the
target failed the prerequisite condition and therefore does not qualify
for further testing (i.e. the predicate expression is NOT evaluated on
it).missingInput: a cotarget expression returned an empty node
set.notApplicable: this target was not even selected by the target
XPath expression, while being of the same general artifact type (e.g.
message type). |
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: |
RSP0800
|
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
[*:Body/wsrm:CreateSequence] |
co-Target:
mycsr |
$target/following::*:Envelope
[*:Body/wsrm:CreateSequenceResponse] [(./../../@conversation =
$target/../../@conversation) or
(*:Header/wsa:RelatesTo[@RelationshipType =
'http://www.w3.org/2005/08/addressing/reply' or not
(@RelationshipType)] = $target/*:Header/wsa:MessageID)] |
Predicate: |
some $env in
$target/following::*:Envelope[*:Header/wsrm:Sequence/wsrm:Identifier =
$mycsr/*:Body/wsrm:CreateSequenceResponse/wsrm:Identifier] satisfies
($env/*:Header/wsa:To = $target/*:Header/wsa:To) |
Reporting: |
true=passed, false=failed |
Prescription: |
mandatory |
Error Message: |
None
of the messages sent in a reliable sequence, has been sent to the same
destination endpoint as the CreateSequence message (at least one should
be). |
Diagnostic Data: |
|
HELP - GLOSSARY
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:
passedfailedwarningnotApplicablenotRelevantmissingInputundeterminedSee
the "reporting" item for the meaning of these results. |
Cotarget:
|
[markup:
testAssertion/cotarget ] (optional)Artifact that is related to the
target, and that needs be accessed for the testing. Identified by an
XPath expression that may refer to the related target node using the
variable '$target'. For example, the target can be a SOAP message and
the cotarget the WSDL file that describes this SOAP message.A cotarget
must have a @name attribute that identifies it. The value of this
attribute can be used as a variable (when prepending '$' to it) by
subsequently defined cotargets, prerequisite and predicate. |
Prerequisite:
|
[markup:
testAssertion/@preReq ] (optional)[markup: testAssertion/prerequisite ]
(optional)The pre-condition for evaluating this Test Assertion on this
target. If the prerequisite evaluates to "false" then the target does
not qualify for this Test Assertion (the test report is
"notRelevant")The first part (preReq attribute) is an enumeration of
Test Assertion IDs. Each one of the prerequisite TAs must either use
the same target (e.g. SOAP Envelope, or WSDL binding, etc.) as this TA,
or a target that is of a more general type than the main TA target. The
target must "pass" each one of these prerequisite TAs in order to
qualify for this TA.(e.g. the target of TA t1 can be a WSDL binding
while the target of a TA t2 prerequisite of t1, can be the entire WSDL
file).The second part ("prerequisite" element) is an XPath (boolean)
expression of the same nature as the predicate. If present, it must
evaluate to "true" for the target to qualify. If it fails, the result
for the current TA in the report will be "notRelevant". Otherwise, the
target can be further evaluated by the predicate of the main TA. The
expression may refer to the target explicitly using the variable name
"$target", or to any cotarget using its name as variable name ($[name]). |
Predicate:
|
[markup:
testAssertion/predicate] required element]A logical expression that
evaluates whether this target is fulfilling the profile requirement
addressed by this test Assertion. By default: - A result of true means
the requirement is fulfilled (reported as a "passed" in the test
report). - A result of false means the requirement is violated
(reported as a "failed" in the test report). However, in some cases and
for testability reasons, the predicate may be designed as a partial
indicator e.g. only indicates some cases of fulfillment, or some cases
of violation. As a result, when "true" indicates fulfillment it may be
that "false" is unconclusive, or conversely "false" will indicate
violation, but "true" is unconclusive. In such cases, the "Reporting"
element specifies the meaning of the predicate result w/r to the
profile requirement.The predicate expression implicitly refers to the
target (whic is its "XPath context") although it may explicitly refer
to it using the variable name "$target". It may refer to any cotarget
using its name as variable name ($[name]). |
Prescription:
|
[markup: testAssertion/prescription/@level ] (required)
Conveys the level of prescription associated with the profile requirement.
At least three values may be used:
mandatory: maps to RFC2119 keywords MUST, MUST NOT, SHALL,
SHALL NOT, REQUIRED (and sometimes MAY NOT) preferred: maps to RFC2119 keywords SHOULD, SHOULD NOT,
RECOMMENDED, NOT RECOMMENDED permitted: maps to RFC2119 keywords MAY, OPTIONAL. |
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: @true attribute: may take values among
{passed, failed, warning, undetermined} (default is 'passed') @false
attribute: may take values among {passed, failed, warning,
undetermined} (default is 'failed') The reported outcomes have the
following meaning:passed: the target passes the test and can be
considered as fulfilling the profile feature.failed: the target fails
the test and can be considered as violating (or not exhibiting) the
profile feature.warning: the test result is inconclusive. There is a
possibility of profile requirement violation, that deserved further
investigation.undetermined: the test result is inconclusive for this
predicate value.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:notRelevant: the
target failed the prerequisite condition and therefore does not qualify
for further testing (i.e. the predicate expression is NOT evaluated on
it).missingInput: a cotarget expression returned an empty node
set.notApplicable: this target was not even selected by the target
XPath expression, while being of the same general artifact type (e.g.
message type). |
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: |
RSP0010
|
General Notes: |
|
Coverage Assessment: |
partial |
Target Type: |
|
Test Target: |
|
Test co-Target(s): |
|
Test Prerequisite: |
|
Predicate: |
No fault is sent back by the CS receiver. |
Prescription: |
mandatory |
Reporting: |
true=warning, false=undetermined |
Test Control: |
Warning: apparent failure. Verify if the Fault has not other causes. |
Test Assertion: |
RSP0010
|
Description: |
|
Target: |
/wsil:testLog/wsil:messageLog/wsil:message/wsil:messageContents/*:Envelope[
*:Body/wsrm:CreateSequence[not(wsrm:Offer)]] |
co-Target:
myresponse |
/wsil:testLog/wsil:messageLog/wsil:message[
(@type = 'response' and @conversation = $target/../../@conversation) or
(.//*:Envelope/*:Header/wsa:RelatesTo[@RelationshipType =
'http://www.w3.org/2005/08/addressing/reply' or not
(@RelationshipType)] = $target/*:Header/wsa:MessageID) ]
/wsil:messageContents/*:Envelope |
Predicate: |
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: |
|
HELP - GLOSSARY
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:
passedfailedwarningnotApplicablenotRelevantmissingInputundeterminedSee
the "reporting" item for the meaning of these results. |
Cotarget:
|
[markup:
testAssertion/cotarget ] (optional)Artifact that is related to the
target, and that needs be accessed for the testing. Identified by an
XPath expression that may refer to the related target node using the
variable '$target'. For example, the target can be a SOAP message and
the cotarget the WSDL file that describes this SOAP message.A cotarget
must have a @name attribute that identifies it. The value of this
attribute can be used as a variable (when prepending '$' to it) by
subsequently defined cotargets, prerequisite and predicate. |
Prerequisite:
|
[markup:
testAssertion/@preReq ] (optional)[markup: testAssertion/prerequisite ]
(optional)The pre-condition for evaluating this Test Assertion on this
target. If the prerequisite evaluates to "false" then the target does
not qualify for this Test Assertion (the test report is
"notRelevant")The first part (preReq attribute) is an enumeration of
Test Assertion IDs. Each one of the prerequisite TAs must either use
the same target (e.g. SOAP Envelope, or WSDL binding, etc.) as this TA,
or a target that is of a more general type than the main TA target. The
target must "pass" each one of these prerequisite TAs in order to
qualify for this TA.(e.g. the target of TA t1 can be a WSDL binding
while the target of a TA t2 prerequisite of t1, can be the entire WSDL
file).The second part ("prerequisite" element) is an XPath (boolean)
expression of the same nature as the predicate. If present, it must
evaluate to "true" for the target to qualify. If it fails, the result
for the current TA in the report will be "notRelevant". Otherwise, the
target can be further evaluated by the predicate of the main TA. The
expression may refer to the target explicitly using the variable name
"$target", or to any cotarget using its name as variable name ($[name]). |
Predicate:
|
[markup:
testAssertion/predicate] required element]A logical expression that
evaluates whether this target is fulfilling the profile requirement
addressed by this test Assertion. By default: - A result of true means
the requirement is fulfilled (reported as a "passed" in the test
report). - A result of false means the requirement is violated
(reported as a "failed" in the test report). However, in some cases and
for testability reasons, the predicate may be designed as a partial
indicator e.g. only indicates some cases of fulfillment, or some cases
of violation. As a result, when "true" indicates fulfillment it may be
that "false" is unconclusive, or conversely "false" will indicate
violation, but "true" is unconclusive. In such cases, the "Reporting"
element specifies the meaning of the predicate result w/r to the
profile requirement.The predicate expression implicitly refers to the
target (whic is its "XPath context") although it may explicitly refer
to it using the variable name "$target". It may refer to any cotarget
using its name as variable name ($[name]). |
Prescription:
|
[markup: testAssertion/prescription/@level ] (required)
Conveys the level of prescription associated with the profile requirement.
At least three values may be used:
mandatory: maps to RFC2119 keywords MUST, MUST NOT, SHALL,
SHALL NOT, REQUIRED (and sometimes MAY NOT) preferred: maps to RFC2119 keywords SHOULD, SHOULD NOT,
RECOMMENDED, NOT RECOMMENDED permitted: maps to RFC2119 keywords MAY, OPTIONAL. |
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: @true attribute: may take values among
{passed, failed, warning, undetermined} (default is 'passed') @false
attribute: may take values among {passed, failed, warning,
undetermined} (default is 'failed') The reported outcomes have the
following meaning:passed: the target passes the test and can be
considered as fulfilling the profile feature.failed: the target fails
the test and can be considered as violating (or not exhibiting) the
profile feature.warning: the test result is inconclusive. There is a
possibility of profile requirement violation, that deserved further
investigation.undetermined: the test result is inconclusive for this
predicate value.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:notRelevant: the
target failed the prerequisite condition and therefore does not qualify
for further testing (i.e. the predicate expression is NOT evaluated on
it).missingInput: a cotarget expression returned an empty node
set.notApplicable: this target was not even selected by the target
XPath expression, while being of the same general artifact type (e.g.
message type). |
R0011
An
RMD MUST NOT fault a CreateSequence due to the presence of the Offer element.
TESTABLE
RSP0011
Test Assertion Analysis: |
RSP0011
|
General Notes: |
|
Coverage Assessment: |
partial |
Target Type: |
|
Test Target: |
|
Test co-Target(s): |
|
Test Prerequisite: |
|
Predicate: |
No fault is sent back by the CS receiver. |
Prescription: |
mandatory |
Reporting: |
true=warning, false=undetermined |
Test Control: |
Warning: apparent failure. Verify if the Fault has not other causes. |
Test Assertion: |
RSP0011
|
Description: |
|
Target: |
/wsil:testLog/wsil:messageLog/wsil:message/wsil:messageContents/*:Envelope[*:Body/wsrm:CreateSequence/wsrm:Offer] |
co-Target:
myresponse |
/wsil:testLog/wsil:messageLog/wsil:message[
(@type = 'response' and @conversation = $target/../../@conversation) or
(.//*:Envelope/*:Header/wsa:RelatesTo[not (@RelationshipType) or (
@RelationshipType = 'http://www.w3.org/2005/08/addressing/reply' ) ] =
$target/*:Header/wsa:MessageID) ]/wsil:messageContents/*:Envelope |
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: |
|
HELP - GLOSSARY
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:
passedfailedwarningnotApplicablenotRelevantmissingInputundeterminedSee
the "reporting" item for the meaning of these results. |
Cotarget:
|
[markup:
testAssertion/cotarget ] (optional)Artifact that is related to the
target, and that needs be accessed for the testing. Identified by an
XPath expression that may refer to the related target node using the
variable '$target'. For example, the target can be a SOAP message and
the cotarget the WSDL file that describes this SOAP message.A cotarget
must have a @name attribute that identifies it. The value of this
attribute can be used as a variable (when prepending '$' to it) by
subsequently defined cotargets, prerequisite and predicate. |
Prerequisite:
|
[markup:
testAssertion/@preReq ] (optional)[markup: testAssertion/prerequisite ]
(optional)The pre-condition for evaluating this Test Assertion on this
target. If the prerequisite evaluates to "false" then the target does
not qualify for this Test Assertion (the test report is
"notRelevant")The first part (preReq attribute) is an enumeration of
Test Assertion IDs. Each one of the prerequisite TAs must either use
the same target (e.g. SOAP Envelope, or WSDL binding, etc.) as this TA,
or a target that is of a more general type than the main TA target. The
target must "pass" each one of these prerequisite TAs in order to
qualify for this TA.(e.g. the target of TA t1 can be a WSDL binding
while the target of a TA t2 prerequisite of t1, can be the entire WSDL
file).The second part ("prerequisite" element) is an XPath (boolean)
expression of the same nature as the predicate. If present, it must
evaluate to "true" for the target to qualify. If it fails, the result
for the current TA in the report will be "notRelevant". Otherwise, the
target can be further evaluated by the predicate of the main TA. The
expression may refer to the target explicitly using the variable name
"$target", or to any cotarget using its name as variable name ($[name]). |
Predicate:
|
[markup:
testAssertion/predicate] required element]A logical expression that
evaluates whether this target is fulfilling the profile requirement
addressed by this test Assertion. By default: - A result of true means
the requirement is fulfilled (reported as a "passed" in the test
report). - A result of false means the requirement is violated
(reported as a "failed" in the test report). However, in some cases and
for testability reasons, the predicate may be designed as a partial
indicator e.g. only indicates some cases of fulfillment, or some cases
of violation. As a result, when "true" indicates fulfillment it may be
that "false" is unconclusive, or conversely "false" will indicate
violation, but "true" is unconclusive. In such cases, the "Reporting"
element specifies the meaning of the predicate result w/r to the
profile requirement.The predicate expression implicitly refers to the
target (whic is its "XPath context") although it may explicitly refer
to it using the variable name "$target". It may refer to any cotarget
using its name as variable name ($[name]). |
Prescription:
|
[markup: testAssertion/prescription/@level ] (required)
Conveys the level of prescription associated with the profile requirement.
At least three values may be used:
mandatory: maps to RFC2119 keywords MUST, MUST NOT, SHALL,
SHALL NOT, REQUIRED (and sometimes MAY NOT) preferred: maps to RFC2119 keywords SHOULD, SHOULD NOT,
RECOMMENDED, NOT RECOMMENDED permitted: maps to RFC2119 keywords MAY, OPTIONAL. |
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: @true attribute: may take values among
{passed, failed, warning, undetermined} (default is 'passed') @false
attribute: may take values among {passed, failed, warning,
undetermined} (default is 'failed') The reported outcomes have the
following meaning:passed: the target passes the test and can be
considered as fulfilling the profile feature.failed: the target fails
the test and can be considered as violating (or not exhibiting) the
profile feature.warning: the test result is inconclusive. There is a
possibility of profile requirement violation, that deserved further
investigation.undetermined: the test result is inconclusive for this
predicate value.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:notRelevant: the
target failed the prerequisite condition and therefore does not qualify
for further testing (i.e. the predicate expression is NOT evaluated on
it).missingInput: a cotarget expression returned an empty node
set.notApplicable: this target was not even selected by the target
XPath expression, while being of the same general artifact type (e.g.
message type). |
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: |
COM0700
|
General Notes: |
not testable since generated faults may not be visible or if testable will never fail |
Coverage Assessment: |
|
Target Type: |
|
Test Target: |
|
Test co-Target(s): |
|
Test Prerequisite: |
|
Predicate: |
|
Prescription: |
mandatory |
Reporting: |
|
Test Control: |
|
Test Assertion: |
COM0700
|
Description: |
|
Target: |
|
Predicate: |
|
Reporting: |
true=passed, false=failed |
Prescription: |
mandatory |
Error Message: |
|
Diagnostic Data: |
|
HELP - GLOSSARY
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:
passedfailedwarningnotApplicablenotRelevantmissingInputundeterminedSee
the "reporting" item for the meaning of these results. |
Cotarget:
|
[markup:
testAssertion/cotarget ] (optional)Artifact that is related to the
target, and that needs be accessed for the testing. Identified by an
XPath expression that may refer to the related target node using the
variable '$target'. For example, the target can be a SOAP message and
the cotarget the WSDL file that describes this SOAP message.A cotarget
must have a @name attribute that identifies it. The value of this
attribute can be used as a variable (when prepending '$' to it) by
subsequently defined cotargets, prerequisite and predicate. |
Prerequisite:
|
[markup:
testAssertion/@preReq ] (optional)[markup: testAssertion/prerequisite ]
(optional)The pre-condition for evaluating this Test Assertion on this
target. If the prerequisite evaluates to "false" then the target does
not qualify for this Test Assertion (the test report is
"notRelevant")The first part (preReq attribute) is an enumeration of
Test Assertion IDs. Each one of the prerequisite TAs must either use
the same target (e.g. SOAP Envelope, or WSDL binding, etc.) as this TA,
or a target that is of a more general type than the main TA target. The
target must "pass" each one of these prerequisite TAs in order to
qualify for this TA.(e.g. the target of TA t1 can be a WSDL binding
while the target of a TA t2 prerequisite of t1, can be the entire WSDL
file).The second part ("prerequisite" element) is an XPath (boolean)
expression of the same nature as the predicate. If present, it must
evaluate to "true" for the target to qualify. If it fails, the result
for the current TA in the report will be "notRelevant". Otherwise, the
target can be further evaluated by the predicate of the main TA. The
expression may refer to the target explicitly using the variable name
"$target", or to any cotarget using its name as variable name ($[name]). |
Predicate:
|
[markup:
testAssertion/predicate] required element]A logical expression that
evaluates whether this target is fulfilling the profile requirement
addressed by this test Assertion. By default: - A result of true means
the requirement is fulfilled (reported as a "passed" in the test
report). - A result of false means the requirement is violated
(reported as a "failed" in the test report). However, in some cases and
for testability reasons, the predicate may be designed as a partial
indicator e.g. only indicates some cases of fulfillment, or some cases
of violation. As a result, when "true" indicates fulfillment it may be
that "false" is unconclusive, or conversely "false" will indicate
violation, but "true" is unconclusive. In such cases, the "Reporting"
element specifies the meaning of the predicate result w/r to the
profile requirement.The predicate expression implicitly refers to the
target (whic is its "XPath context") although it may explicitly refer
to it using the variable name "$target". It may refer to any cotarget
using its name as variable name ($[name]). |
Prescription:
|
[markup: testAssertion/prescription/@level ] (required)
Conveys the level of prescription associated with the profile requirement.
At least three values may be used:
mandatory: maps to RFC2119 keywords MUST, MUST NOT, SHALL,
SHALL NOT, REQUIRED (and sometimes MAY NOT) preferred: maps to RFC2119 keywords SHOULD, SHOULD NOT,
RECOMMENDED, NOT RECOMMENDED permitted: maps to RFC2119 keywords MAY, OPTIONAL. |
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: @true attribute: may take values among
{passed, failed, warning, undetermined} (default is 'passed') @false
attribute: may take values among {passed, failed, warning,
undetermined} (default is 'failed') The reported outcomes have the
following meaning:passed: the target passes the test and can be
considered as fulfilling the profile feature.failed: the target fails
the test and can be considered as violating (or not exhibiting) the
profile feature.warning: the test result is inconclusive. There is a
possibility of profile requirement violation, that deserved further
investigation.undetermined: the test result is inconclusive for this
predicate value.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:notRelevant: the
target failed the prerequisite condition and therefore does not qualify
for further testing (i.e. the predicate expression is NOT evaluated on
it).missingInput: a cotarget expression returned an empty node
set.notApplicable: this target was not even selected by the target
XPath expression, while being of the same general artifact type (e.g.
message type). |
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: |
COM0200
|
General Notes: |
untestable without ESP, hard to simulate an rmd autonomous decision to discontinue a sequence hard to impossible. |
Coverage Assessment: |
|
Target Type: |
|
Test Target: |
|
Test co-Target(s): |
|
Test Prerequisite: |
|
Predicate: |
|
Prescription: |
mandatory |
Reporting: |
|
Test Control: |
|
Test Assertion: |
COM0200
|
Description: |
|
Target: |
|
Predicate: |
|
Reporting: |
true=passed, false=failed |
Prescription: |
mandatory |
Error Message: |
|
Diagnostic Data: |
|
HELP - GLOSSARY
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:
passedfailedwarningnotApplicablenotRelevantmissingInputundeterminedSee
the "reporting" item for the meaning of these results. |
Cotarget:
|
[markup:
testAssertion/cotarget ] (optional)Artifact that is related to the
target, and that needs be accessed for the testing. Identified by an
XPath expression that may refer to the related target node using the
variable '$target'. For example, the target can be a SOAP message and
the cotarget the WSDL file that describes this SOAP message.A cotarget
must have a @name attribute that identifies it. The value of this
attribute can be used as a variable (when prepending '$' to it) by
subsequently defined cotargets, prerequisite and predicate. |
Prerequisite:
|
[markup:
testAssertion/@preReq ] (optional)[markup: testAssertion/prerequisite ]
(optional)The pre-condition for evaluating this Test Assertion on this
target. If the prerequisite evaluates to "false" then the target does
not qualify for this Test Assertion (the test report is
"notRelevant")The first part (preReq attribute) is an enumeration of
Test Assertion IDs. Each one of the prerequisite TAs must either use
the same target (e.g. SOAP Envelope, or WSDL binding, etc.) as this TA,
or a target that is of a more general type than the main TA target. The
target must "pass" each one of these prerequisite TAs in order to
qualify for this TA.(e.g. the target of TA t1 can be a WSDL binding
while the target of a TA t2 prerequisite of t1, can be the entire WSDL
file).The second part ("prerequisite" element) is an XPath (boolean)
expression of the same nature as the predicate. If present, it must
evaluate to "true" for the target to qualify. If it fails, the result
for the current TA in the report will be "notRelevant". Otherwise, the
target can be further evaluated by the predicate of the main TA. The
expression may refer to the target explicitly using the variable name
"$target", or to any cotarget using its name as variable name ($[name]). |
Predicate:
|
[markup:
testAssertion/predicate] required element]A logical expression that
evaluates whether this target is fulfilling the profile requirement
addressed by this test Assertion. By default: - A result of true means
the requirement is fulfilled (reported as a "passed" in the test
report). - A result of false means the requirement is violated
(reported as a "failed" in the test report). However, in some cases and
for testability reasons, the predicate may be designed as a partial
indicator e.g. only indicates some cases of fulfillment, or some cases
of violation. As a result, when "true" indicates fulfillment it may be
that "false" is unconclusive, or conversely "false" will indicate
violation, but "true" is unconclusive. In such cases, the "Reporting"
element specifies the meaning of the predicate result w/r to the
profile requirement.The predicate expression implicitly refers to the
target (whic is its "XPath context") although it may explicitly refer
to it using the variable name "$target". It may refer to any cotarget
using its name as variable name ($[name]). |
Prescription:
|
[markup: testAssertion/prescription/@level ] (required)
Conveys the level of prescription associated with the profile requirement.
At least three values may be used:
mandatory: maps to RFC2119 keywords MUST, MUST NOT, SHALL,
SHALL NOT, REQUIRED (and sometimes MAY NOT) preferred: maps to RFC2119 keywords SHOULD, SHOULD NOT,
RECOMMENDED, NOT RECOMMENDED permitted: maps to RFC2119 keywords MAY, OPTIONAL. |
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: @true attribute: may take values among
{passed, failed, warning, undetermined} (default is 'passed') @false
attribute: may take values among {passed, failed, warning,
undetermined} (default is 'failed') The reported outcomes have the
following meaning:passed: the target passes the test and can be
considered as fulfilling the profile feature.failed: the target fails
the test and can be considered as violating (or not exhibiting) the
profile feature.warning: the test result is inconclusive. There is a
possibility of profile requirement violation, that deserved further
investigation.undetermined: the test result is inconclusive for this
predicate value.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:notRelevant: the
target failed the prerequisite condition and therefore does not qualify
for further testing (i.e. the predicate expression is NOT evaluated on
it).missingInput: a cotarget expression returned an empty node
set.notApplicable: this target was not even selected by the target
XPath expression, while being of the same general artifact type (e.g.
message type). |
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: |
RSP0210
|
General Notes: |
|
Coverage Assessment: |
Good |
Target Type: |
ENVELOPE (either CS or TS) |
Test Target: |
For a soap:Envelope with either a wsrm:CloseSequence or a wsrm:TerminateSequence element in the soap:Body |
Test co-Target(s): |
|
Test Prerequisite: |
|
Predicate: |
the Envelope also contains wsrm:LastMsgNumber: proposed XPath= se:Body/wsrm:*/wsrm:LastMsgNumber |
Prescription: |
mandatory |
Reporting: |
true=pass, false=fail |
Test Control: |
Generate either a wsrm:CloseSequence message, or a wsrm:TerminateSequence |
Test Assertion: |
RSP0210
|
Description: |
The
soap:envelope in the message also contains a wsrm:LastMsgNumber element
if it has a wsrm:CloseSequence or a wsrm:TerminateSequence element. |
Target: |
//wsil:messageContents/*:Envelope[
*:Body/wsrm:CloseSequence or *:Body/wsrm:TerminateSequence
] |
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} |
HELP - GLOSSARY
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:
passedfailedwarningnotApplicablenotRelevantmissingInputundeterminedSee
the "reporting" item for the meaning of these results. |
Cotarget:
|
[markup:
testAssertion/cotarget ] (optional)Artifact that is related to the
target, and that needs be accessed for the testing. Identified by an
XPath expression that may refer to the related target node using the
variable '$target'. For example, the target can be a SOAP message and
the cotarget the WSDL file that describes this SOAP message.A cotarget
must have a @name attribute that identifies it. The value of this
attribute can be used as a variable (when prepending '$' to it) by
subsequently defined cotargets, prerequisite and predicate. |
Prerequisite:
|
[markup:
testAssertion/@preReq ] (optional)[markup: testAssertion/prerequisite ]
(optional)The pre-condition for evaluating this Test Assertion on this
target. If the prerequisite evaluates to "false" then the target does
not qualify for this Test Assertion (the test report is
"notRelevant")The first part (preReq attribute) is an enumeration of
Test Assertion IDs. Each one of the prerequisite TAs must either use
the same target (e.g. SOAP Envelope, or WSDL binding, etc.) as this TA,
or a target that is of a more general type than the main TA target. The
target must "pass" each one of these prerequisite TAs in order to
qualify for this TA.(e.g. the target of TA t1 can be a WSDL binding
while the target of a TA t2 prerequisite of t1, can be the entire WSDL
file).The second part ("prerequisite" element) is an XPath (boolean)
expression of the same nature as the predicate. If present, it must
evaluate to "true" for the target to qualify. If it fails, the result
for the current TA in the report will be "notRelevant". Otherwise, the
target can be further evaluated by the predicate of the main TA. The
expression may refer to the target explicitly using the variable name
"$target", or to any cotarget using its name as variable name ($[name]). |
Predicate:
|
[markup:
testAssertion/predicate] required element]A logical expression that
evaluates whether this target is fulfilling the profile requirement
addressed by this test Assertion. By default: - A result of true means
the requirement is fulfilled (reported as a "passed" in the test
report). - A result of false means the requirement is violated
(reported as a "failed" in the test report). However, in some cases and
for testability reasons, the predicate may be designed as a partial
indicator e.g. only indicates some cases of fulfillment, or some cases
of violation. As a result, when "true" indicates fulfillment it may be
that "false" is unconclusive, or conversely "false" will indicate
violation, but "true" is unconclusive. In such cases, the "Reporting"
element specifies the meaning of the predicate result w/r to the
profile requirement.The predicate expression implicitly refers to the
target (whic is its "XPath context") although it may explicitly refer
to it using the variable name "$target". It may refer to any cotarget
using its name as variable name ($[name]). |
Prescription:
|
[markup: testAssertion/prescription/@level ] (required)
Conveys the level of prescription associated with the profile requirement.
At least three values may be used:
mandatory: maps to RFC2119 keywords MUST, MUST NOT, SHALL,
SHALL NOT, REQUIRED (and sometimes MAY NOT) preferred: maps to RFC2119 keywords SHOULD, SHOULD NOT,
RECOMMENDED, NOT RECOMMENDED permitted: maps to RFC2119 keywords MAY, OPTIONAL. |
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: @true attribute: may take values among
{passed, failed, warning, undetermined} (default is 'passed') @false
attribute: may take values among {passed, failed, warning,
undetermined} (default is 'failed') The reported outcomes have the
following meaning:passed: the target passes the test and can be
considered as fulfilling the profile feature.failed: the target fails
the test and can be considered as violating (or not exhibiting) the
profile feature.warning: the test result is inconclusive. There is a
possibility of profile requirement violation, that deserved further
investigation.undetermined: the test result is inconclusive for this
predicate value.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:notRelevant: the
target failed the prerequisite condition and therefore does not qualify
for further testing (i.e. the predicate expression is NOT evaluated on
it).missingInput: a cotarget expression returned an empty node
set.notApplicable: this target was not even selected by the target
XPath expression, while being of the same general artifact type (e.g.
message type). |
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. TBD
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
RSP0400a
RSP0400b
Test Assertion Analysis: |
RSP0400a
|
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[
*:Body/wsrm:CloseSequence or
*:Body/wsrm:TerminateSequence or
*:Header/wsrm:AckRequested]
[.//wsrm:Identifier = 'http://dummy.examples.org/unknown/nmspace'] |
co-Target:
myresponse |
/wsil:testLog/wsil:messageLog/wsil:message[
(@type = 'response' and @conversation = $target/../../@conversation) or
(.//*:Envelope/*:Header/wsa:RelatesTo[@RelationshipType =
'http://www.w3.org/2005/08/addressing/reply' or not
(@RelationshipType)] = $target/*:Header/wsa:MessageID) ]
/wsil:messageContents/*:Envelope |
Predicate: |
$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: |
|
HELP - GLOSSARY
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:
passedfailedwarningnotApplicablenotRelevantmissingInputundeterminedSee
the "reporting" item for the meaning of these results. |
Cotarget:
|
[markup:
testAssertion/cotarget ] (optional)Artifact that is related to the
target, and that needs be accessed for the testing. Identified by an
XPath expression that may refer to the related target node using the
variable '$target'. For example, the target can be a SOAP message and
the cotarget the WSDL file that describes this SOAP message.A cotarget
must have a @name attribute that identifies it. The value of this
attribute can be used as a variable (when prepending '$' to it) by
subsequently defined cotargets, prerequisite and predicate. |
Prerequisite:
|
[markup:
testAssertion/@preReq ] (optional)[markup: testAssertion/prerequisite ]
(optional)The pre-condition for evaluating this Test Assertion on this
target. If the prerequisite evaluates to "false" then the target does
not qualify for this Test Assertion (the test report is
"notRelevant")The first part (preReq attribute) is an enumeration of
Test Assertion IDs. Each one of the prerequisite TAs must either use
the same target (e.g. SOAP Envelope, or WSDL binding, etc.) as this TA,
or a target that is of a more general type than the main TA target. The
target must "pass" each one of these prerequisite TAs in order to
qualify for this TA.(e.g. the target of TA t1 can be a WSDL binding
while the target of a TA t2 prerequisite of t1, can be the entire WSDL
file).The second part ("prerequisite" element) is an XPath (boolean)
expression of the same nature as the predicate. If present, it must
evaluate to "true" for the target to qualify. If it fails, the result
for the current TA in the report will be "notRelevant". Otherwise, the
target can be further evaluated by the predicate of the main TA. The
expression may refer to the target explicitly using the variable name
"$target", or to any cotarget using its name as variable name ($[name]). |
Predicate:
|
[markup:
testAssertion/predicate] required element]A logical expression that
evaluates whether this target is fulfilling the profile requirement
addressed by this test Assertion. By default: - A result of true means
the requirement is fulfilled (reported as a "passed" in the test
report). - A result of false means the requirement is violated
(reported as a "failed" in the test report). However, in some cases and
for testability reasons, the predicate may be designed as a partial
indicator e.g. only indicates some cases of fulfillment, or some cases
of violation. As a result, when "true" indicates fulfillment it may be
that "false" is unconclusive, or conversely "false" will indicate
violation, but "true" is unconclusive. In such cases, the "Reporting"
element specifies the meaning of the predicate result w/r to the
profile requirement.The predicate expression implicitly refers to the
target (whic is its "XPath context") although it may explicitly refer
to it using the variable name "$target". It may refer to any cotarget
using its name as variable name ($[name]). |
Prescription:
|
[markup: testAssertion/prescription/@level ] (required)
Conveys the level of prescription associated with the profile requirement.
At least three values may be used:
mandatory: maps to RFC2119 keywords MUST, MUST NOT, SHALL,
SHALL NOT, REQUIRED (and sometimes MAY NOT) preferred: maps to RFC2119 keywords SHOULD, SHOULD NOT,
RECOMMENDED, NOT RECOMMENDED permitted: maps to RFC2119 keywords MAY, OPTIONAL. |
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: @true attribute: may take values among
{passed, failed, warning, undetermined} (default is 'passed') @false
attribute: may take values among {passed, failed, warning,
undetermined} (default is 'failed') The reported outcomes have the
following meaning:passed: the target passes the test and can be
considered as fulfilling the profile feature.failed: the target fails
the test and can be considered as violating (or not exhibiting) the
profile feature.warning: the test result is inconclusive. There is a
possibility of profile requirement violation, that deserved further
investigation.undetermined: the test result is inconclusive for this
predicate value.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:notRelevant: the
target failed the prerequisite condition and therefore does not qualify
for further testing (i.e. the predicate expression is NOT evaluated on
it).missingInput: a cotarget expression returned an empty node
set.notApplicable: this target was not even selected by the target
XPath expression, while being of the same general artifact type (e.g.
message type). |
Test Assertion Analysis: |
RSP0400b
|
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[
*:Body/wsrm:CloseSequence or
*:Body/wsrm:TerminateSequence or
*:Header/wsrm:AckRequested]
[.//wsrm:Identifier = 'http://dummy.examples.org/unknown/nmspace'] |
co-Target:
myresponse |
/wsil:testLog/wsil:messageLog/wsil:message[
(@type = 'response' and @conversation = $target/../../@conversation) or
(.//*:Envelope/*:Header/wsa:RelatesTo[@RelationshipType =
'http://www.w3.org/2005/08/addressing/reply' or not
(@RelationshipType)] = $target/*:Header/wsa:MessageID) ]
/wsil:messageContents/*:Envelope |
Predicate: |
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: |
|
HELP - GLOSSARY
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:
passedfailedwarningnotApplicablenotRelevantmissingInputundeterminedSee
the "reporting" item for the meaning of these results. |
Cotarget:
|
[markup:
testAssertion/cotarget ] (optional)Artifact that is related to the
target, and that needs be accessed for the testing. Identified by an
XPath expression that may refer to the related target node using the
variable '$target'. For example, the target can be a SOAP message and
the cotarget the WSDL file that describes this SOAP message.A cotarget
must have a @name attribute that identifies it. The value of this
attribute can be used as a variable (when prepending '$' to it) by
subsequently defined cotargets, prerequisite and predicate. |
Prerequisite:
|
[markup:
testAssertion/@preReq ] (optional)[markup: testAssertion/prerequisite ]
(optional)The pre-condition for evaluating this Test Assertion on this
target. If the prerequisite evaluates to "false" then the target does
not qualify for this Test Assertion (the test report is
"notRelevant")The first part (preReq attribute) is an enumeration of
Test Assertion IDs. Each one of the prerequisite TAs must either use
the same target (e.g. SOAP Envelope, or WSDL binding, etc.) as this TA,
or a target that is of a more general type than the main TA target. The
target must "pass" each one of these prerequisite TAs in order to
qualify for this TA.(e.g. the target of TA t1 can be a WSDL binding
while the target of a TA t2 prerequisite of t1, can be the entire WSDL
file).The second part ("prerequisite" element) is an XPath (boolean)
expression of the same nature as the predicate. If present, it must
evaluate to "true" for the target to qualify. If it fails, the result
for the current TA in the report will be "notRelevant". Otherwise, the
target can be further evaluated by the predicate of the main TA. The
expression may refer to the target explicitly using the variable name
"$target", or to any cotarget using its name as variable name ($[name]). |
Predicate:
|
[markup:
testAssertion/predicate] required element]A logical expression that
evaluates whether this target is fulfilling the profile requirement
addressed by this test Assertion. By default: - A result of true means
the requirement is fulfilled (reported as a "passed" in the test
report). - A result of false means the requirement is violated
(reported as a "failed" in the test report). However, in some cases and
for testability reasons, the predicate may be designed as a partial
indicator e.g. only indicates some cases of fulfillment, or some cases
of violation. As a result, when "true" indicates fulfillment it may be
that "false" is unconclusive, or conversely "false" will indicate
violation, but "true" is unconclusive. In such cases, the "Reporting"
element specifies the meaning of the predicate result w/r to the
profile requirement.The predicate expression implicitly refers to the
target (whic is its "XPath context") although it may explicitly refer
to it using the variable name "$target". It may refer to any cotarget
using its name as variable name ($[name]). |
Prescription:
|
[markup: testAssertion/prescription/@level ] (required)
Conveys the level of prescription associated with the profile requirement.
At least three values may be used:
mandatory: maps to RFC2119 keywords MUST, MUST NOT, SHALL,
SHALL NOT, REQUIRED (and sometimes MAY NOT) preferred: maps to RFC2119 keywords SHOULD, SHOULD NOT,
RECOMMENDED, NOT RECOMMENDED permitted: maps to RFC2119 keywords MAY, OPTIONAL. |
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: @true attribute: may take values among
{passed, failed, warning, undetermined} (default is 'passed') @false
attribute: may take values among {passed, failed, warning,
undetermined} (default is 'failed') The reported outcomes have the
following meaning:passed: the target passes the test and can be
considered as fulfilling the profile feature.failed: the target fails
the test and can be considered as violating (or not exhibiting) the
profile feature.warning: the test result is inconclusive. There is a
possibility of profile requirement violation, that deserved further
investigation.undetermined: the test result is inconclusive for this
predicate value.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:notRelevant: the
target failed the prerequisite condition and therefore does not qualify
for further testing (i.e. the predicate expression is NOT evaluated on
it).missingInput: a cotarget expression returned an empty node
set.notApplicable: this target was not even selected by the target
XPath expression, while being of the same general artifact type (e.g.
message type). |
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: |
RSP0620
|
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
[*:Body/*:Fault//*:Value[node() = 'wsrm:SequenceTerminated' or
node() = 'wsrm:UnknownSequence' or
node() = 'wsrm:InvalidAcknowledgement' or
node() = 'wsrm:MessageNumberRollover' or
node() = 'wsrm:CreateSequenceRefused' or
node() = 'wsrm:SequenceClosed' or
node() = 'wsrm:WSRMRequired']] |
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: |
|
HELP - GLOSSARY
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:
passedfailedwarningnotApplicablenotRelevantmissingInputundeterminedSee
the "reporting" item for the meaning of these results. |
Cotarget:
|
[markup:
testAssertion/cotarget ] (optional)Artifact that is related to the
target, and that needs be accessed for the testing. Identified by an
XPath expression that may refer to the related target node using the
variable '$target'. For example, the target can be a SOAP message and
the cotarget the WSDL file that describes this SOAP message.A cotarget
must have a @name attribute that identifies it. The value of this
attribute can be used as a variable (when prepending '$' to it) by
subsequently defined cotargets, prerequisite and predicate. |
Prerequisite:
|
[markup:
testAssertion/@preReq ] (optional)[markup: testAssertion/prerequisite ]
(optional)The pre-condition for evaluating this Test Assertion on this
target. If the prerequisite evaluates to "false" then the target does
not qualify for this Test Assertion (the test report is
"notRelevant")The first part (preReq attribute) is an enumeration of
Test Assertion IDs. Each one of the prerequisite TAs must either use
the same target (e.g. SOAP Envelope, or WSDL binding, etc.) as this TA,
or a target that is of a more general type than the main TA target. The
target must "pass" each one of these prerequisite TAs in order to
qualify for this TA.(e.g. the target of TA t1 can be a WSDL binding
while the target of a TA t2 prerequisite of t1, can be the entire WSDL
file).The second part ("prerequisite" element) is an XPath (boolean)
expression of the same nature as the predicate. If present, it must
evaluate to "true" for the target to qualify. If it fails, the result
for the current TA in the report will be "notRelevant". Otherwise, the
target can be further evaluated by the predicate of the main TA. The
expression may refer to the target explicitly using the variable name
"$target", or to any cotarget using its name as variable name ($[name]). |
Predicate:
|
[markup:
testAssertion/predicate] required element]A logical expression that
evaluates whether this target is fulfilling the profile requirement
addressed by this test Assertion. By default: - A result of true means
the requirement is fulfilled (reported as a "passed" in the test
report). - A result of false means the requirement is violated
(reported as a "failed" in the test report). However, in some cases and
for testability reasons, the predicate may be designed as a partial
indicator e.g. only indicates some cases of fulfillment, or some cases
of violation. As a result, when "true" indicates fulfillment it may be
that "false" is unconclusive, or conversely "false" will indicate
violation, but "true" is unconclusive. In such cases, the "Reporting"
element specifies the meaning of the predicate result w/r to the
profile requirement.The predicate expression implicitly refers to the
target (whic is its "XPath context") although it may explicitly refer
to it using the variable name "$target". It may refer to any cotarget
using its name as variable name ($[name]). |
Prescription:
|
[markup: testAssertion/prescription/@level ] (required)
Conveys the level of prescription associated with the profile requirement.
At least three values may be used:
mandatory: maps to RFC2119 keywords MUST, MUST NOT, SHALL,
SHALL NOT, REQUIRED (and sometimes MAY NOT) preferred: maps to RFC2119 keywords SHOULD, SHOULD NOT,
RECOMMENDED, NOT RECOMMENDED permitted: maps to RFC2119 keywords MAY, OPTIONAL. |
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: @true attribute: may take values among
{passed, failed, warning, undetermined} (default is 'passed') @false
attribute: may take values among {passed, failed, warning,
undetermined} (default is 'failed') The reported outcomes have the
following meaning:passed: the target passes the test and can be
considered as fulfilling the profile feature.failed: the target fails
the test and can be considered as violating (or not exhibiting) the
profile feature.warning: the test result is inconclusive. There is a
possibility of profile requirement violation, that deserved further
investigation.undetermined: the test result is inconclusive for this
predicate value.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:notRelevant: the
target failed the prerequisite condition and therefore does not qualify
for further testing (i.e. the predicate expression is NOT evaluated on
it).missingInput: a cotarget expression returned an empty node
set.notApplicable: this target was not even selected by the target
XPath expression, while being of the same general artifact type (e.g.
message type). |
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: |
RSP0600
|
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
[@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
$req1/preceding::wsil:message[@type = 'request' and
(.//*:Header/wsrm:Sequence/wsrm:Identifier =
$req1//*:Header/wsrm:Sequence/wsrm:Identifier) and
(.//*:Header/wsa:ReplyTo/wsa:Address =
$req1//*:Header/wsa:ReplyTo//wsa:Address or
(not(.//*:Header/wsa:ReplyTo) and not($req1//*:Header/wsa:ReplyTo)) )]
] |
co-Target:
siblingresp |
$target/preceding::wsil:message
[@type = 'response'] [ some $resp2 in . satisfies some $req2 in
./preceding::wsil:message[@type = 'request' and (@conversation =
$resp2/@conversation or .//*:Header/wsa:MessageID =
$resp2//wsa:RelatesTo[@RelationshipType =
'http://www.w3.org/2005/08/addressing/reply' or not
(@RelationshipType)] )] satisfies some $req1 in
$req2/following::wsil:message[@type = 'request' and
.//*:Header/wsrm:Sequence/wsrm:Identifier =
$req2//*:Header/wsrm:Sequence/wsrm:Identifier] satisfies
($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 ($req2//*:Header/wsa:ReplyTo/wsa:Address =
$req1//*:Header/wsa:ReplyTo/wsa:Address or (not($req2//wsa:ReplyTo) and
not($req1//wsa:ReplyTo))) ] [fn:last()] |
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: |
|
HELP - GLOSSARY
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:
passedfailedwarningnotApplicablenotRelevantmissingInputundeterminedSee
the "reporting" item for the meaning of these results. |
Cotarget:
|
[markup:
testAssertion/cotarget ] (optional)Artifact that is related to the
target, and that needs be accessed for the testing. Identified by an
XPath expression that may refer to the related target node using the
variable '$target'. For example, the target can be a SOAP message and
the cotarget the WSDL file that describes this SOAP message.A cotarget
must have a @name attribute that identifies it. The value of this
attribute can be used as a variable (when prepending '$' to it) by
subsequently defined cotargets, prerequisite and predicate. |
Prerequisite:
|
[markup:
testAssertion/@preReq ] (optional)[markup: testAssertion/prerequisite ]
(optional)The pre-condition for evaluating this Test Assertion on this
target. If the prerequisite evaluates to "false" then the target does
not qualify for this Test Assertion (the test report is
"notRelevant")The first part (preReq attribute) is an enumeration of
Test Assertion IDs. Each one of the prerequisite TAs must either use
the same target (e.g. SOAP Envelope, or WSDL binding, etc.) as this TA,
or a target that is of a more general type than the main TA target. The
target must "pass" each one of these prerequisite TAs in order to
qualify for this TA.(e.g. the target of TA t1 can be a WSDL binding
while the target of a TA t2 prerequisite of t1, can be the entire WSDL
file).The second part ("prerequisite" element) is an XPath (boolean)
expression of the same nature as the predicate. If present, it must
evaluate to "true" for the target to qualify. If it fails, the result
for the current TA in the report will be "notRelevant". Otherwise, the
target can be further evaluated by the predicate of the main TA. The
expression may refer to the target explicitly using the variable name
"$target", or to any cotarget using its name as variable name ($[name]). |
Predicate:
|
[markup:
testAssertion/predicate] required element]A logical expression that
evaluates whether this target is fulfilling the profile requirement
addressed by this test Assertion. By default: - A result of true means
the requirement is fulfilled (reported as a "passed" in the test
report). - A result of false means the requirement is violated
(reported as a "failed" in the test report). However, in some cases and
for testability reasons, the predicate may be designed as a partial
indicator e.g. only indicates some cases of fulfillment, or some cases
of violation. As a result, when "true" indicates fulfillment it may be
that "false" is unconclusive, or conversely "false" will indicate
violation, but "true" is unconclusive. In such cases, the "Reporting"
element specifies the meaning of the predicate result w/r to the
profile requirement.The predicate expression implicitly refers to the
target (whic is its "XPath context") although it may explicitly refer
to it using the variable name "$target". It may refer to any cotarget
using its name as variable name ($[name]). |
Prescription:
|
[markup: testAssertion/prescription/@level ] (required)
Conveys the level of prescription associated with the profile requirement.
At least three values may be used:
mandatory: maps to RFC2119 keywords MUST, MUST NOT, SHALL,
SHALL NOT, REQUIRED (and sometimes MAY NOT) preferred: maps to RFC2119 keywords SHOULD, SHOULD NOT,
RECOMMENDED, NOT RECOMMENDED permitted: maps to RFC2119 keywords MAY, OPTIONAL. |
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: @true attribute: may take values among
{passed, failed, warning, undetermined} (default is 'passed') @false
attribute: may take values among {passed, failed, warning,
undetermined} (default is 'failed') The reported outcomes have the
following meaning:passed: the target passes the test and can be
considered as fulfilling the profile feature.failed: the target fails
the test and can be considered as violating (or not exhibiting) the
profile feature.warning: the test result is inconclusive. There is a
possibility of profile requirement violation, that deserved further
investigation.undetermined: the test result is inconclusive for this
predicate value.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:notRelevant: the
target failed the prerequisite condition and therefore does not qualify
for further testing (i.e. the predicate expression is NOT evaluated on
it).missingInput: a cotarget expression returned an empty node
set.notApplicable: this target was not even selected by the target
XPath expression, while being of the same general artifact type (e.g.
message type). |
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: |
RSP0610
|
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
[@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
$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 |
$target/preceding::wsil:message
[@type = 'response'] [ some $resp2 in . satisfies some $req2 in
./preceding::wsil:message[@type = 'request' and (@conversation =
$resp2/@conversation or .//*:Header/wsa:MessageID =
$resp2//wsa:RelatesTo[@RelationshipType =
'http://www.w3.org/2005/08/addressing/reply' or not
(@RelationshipType)] )] satisfies some $req1 in
$req2/following::wsil:message[@type = 'request' and
.//*:Header/wsrm:Sequence/wsrm:Identifier =
$req2//*:Header/wsrm:Sequence/wsrm:Identifier] satisfies
($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) ] [fn:last()] |
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: |
|
HELP - GLOSSARY
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:
passedfailedwarningnotApplicablenotRelevantmissingInputundeterminedSee
the "reporting" item for the meaning of these results. |
Cotarget:
|
[markup:
testAssertion/cotarget ] (optional)Artifact that is related to the
target, and that needs be accessed for the testing. Identified by an
XPath expression that may refer to the related target node using the
variable '$target'. For example, the target can be a SOAP message and
the cotarget the WSDL file that describes this SOAP message.A cotarget
must have a @name attribute that identifies it. The value of this
attribute can be used as a variable (when prepending '$' to it) by
subsequently defined cotargets, prerequisite and predicate. |
Prerequisite:
|
[markup:
testAssertion/@preReq ] (optional)[markup: testAssertion/prerequisite ]
(optional)The pre-condition for evaluating this Test Assertion on this
target. If the prerequisite evaluates to "false" then the target does
not qualify for this Test Assertion (the test report is
"notRelevant")The first part (preReq attribute) is an enumeration of
Test Assertion IDs. Each one of the prerequisite TAs must either use
the same target (e.g. SOAP Envelope, or WSDL binding, etc.) as this TA,
or a target that is of a more general type than the main TA target. The
target must "pass" each one of these prerequisite TAs in order to
qualify for this TA.(e.g. the target of TA t1 can be a WSDL binding
while the target of a TA t2 prerequisite of t1, can be the entire WSDL
file).The second part ("prerequisite" element) is an XPath (boolean)
expression of the same nature as the predicate. If present, it must
evaluate to "true" for the target to qualify. If it fails, the result
for the current TA in the report will be "notRelevant". Otherwise, the
target can be further evaluated by the predicate of the main TA. The
expression may refer to the target explicitly using the variable name
"$target", or to any cotarget using its name as variable name ($[name]). |
Predicate:
|
[markup:
testAssertion/predicate] required element]A logical expression that
evaluates whether this target is fulfilling the profile requirement
addressed by this test Assertion. By default: - A result of true means
the requirement is fulfilled (reported as a "passed" in the test
report). - A result of false means the requirement is violated
(reported as a "failed" in the test report). However, in some cases and
for testability reasons, the predicate may be designed as a partial
indicator e.g. only indicates some cases of fulfillment, or some cases
of violation. As a result, when "true" indicates fulfillment it may be
that "false" is unconclusive, or conversely "false" will indicate
violation, but "true" is unconclusive. In such cases, the "Reporting"
element specifies the meaning of the predicate result w/r to the
profile requirement.The predicate expression implicitly refers to the
target (whic is its "XPath context") although it may explicitly refer
to it using the variable name "$target". It may refer to any cotarget
using its name as variable name ($[name]). |
Prescription:
|
[markup: testAssertion/prescription/@level ] (required)
Conveys the level of prescription associated with the profile requirement.
At least three values may be used:
mandatory: maps to RFC2119 keywords MUST, MUST NOT, SHALL,
SHALL NOT, REQUIRED (and sometimes MAY NOT) preferred: maps to RFC2119 keywords SHOULD, SHOULD NOT,
RECOMMENDED, NOT RECOMMENDED permitted: maps to RFC2119 keywords MAY, OPTIONAL. |
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: @true attribute: may take values among
{passed, failed, warning, undetermined} (default is 'passed') @false
attribute: may take values among {passed, failed, warning,
undetermined} (default is 'failed') The reported outcomes have the
following meaning:passed: the target passes the test and can be
considered as fulfilling the profile feature.failed: the target fails
the test and can be considered as violating (or not exhibiting) the
profile feature.warning: the test result is inconclusive. There is a
possibility of profile requirement violation, that deserved further
investigation.undetermined: the test result is inconclusive for this
predicate value.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:notRelevant: the
target failed the prerequisite condition and therefore does not qualify
for further testing (i.e. the predicate expression is NOT evaluated on
it).missingInput: a cotarget expression returned an empty node
set.notApplicable: this target was not even selected by the target
XPath expression, while being of the same general artifact type (e.g.
message type). |
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: |
RSP0101
|
General Notes: |
NOTE1:The
TA should only apply when there is evidence of message resending.
NOTE2: "continuation of resending" is hard to evaluate. |
Coverage Assessment: |
Partial |
Target Type: |
ENVELOPE(CS or CSR) |
Test Target: |
For
either a CloseSequence message or a CloseSequenceResponse message sent
by RMS, and if there is evidence of resending for a message sent before
this CloseSequence[Response], over this sequence. |
Test co-Target(s): |
|
Test Prerequisite: |
|
Predicate: |
The same message is NOT resent after the CloseSequence[Response] was sent. |
Prescription: |
mandatory |
Reporting: |
true=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
[*:Body/wsrm:CloseSequence or *:Body/wsrm:TerminateSequence] [some
$seqid in *:Body//wsrm:Identifier satisfies some $env1 in
./preceding::*:Envelope[*:Header/wsrm:Sequence/wsrm:Identifier =
$seqid] satisfies
$env1/preceding::*:Envelope[*:Header/wsrm:Sequence/wsrm:Identifier =
$seqid and *:Header/wsrm:Sequence/wsrm:MessageNumber =
$env1/*:Header/wsrm:Sequence/wsrm:MessageNumber ] ] |
Predicate: |
not (
some $seqid in ./*:Body//wsrm:Identifier satisfies
(some $env1 in ./preceding::*:Envelope[*:Header/wsrm:Sequence/wsrm:Identifier = $seqid ] satisfies
(./following::*:Envelope[*:Header/wsrm:Sequence/wsrm:Identifier = $seqid and
*:Header/wsrm:Sequence/wsrm:MessageNumber = $env1/*:Header/wsrm:Sequence/wsrm:MessageNumber ]))
)
|
Reporting: |
true=passed, false=failed |
Prescription: |
mandatory |
Error Message: |
A
CloseSequence message or a TerminateSequence message was sent by RMS
for a sequence that contains messages that have been resent. But the
resending has not stopped after these terminating messages have been
logged. |
Diagnostic Data: |
|
HELP - GLOSSARY
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:
passedfailedwarningnotApplicablenotRelevantmissingInputundeterminedSee
the "reporting" item for the meaning of these results. |
Cotarget:
|
[markup:
testAssertion/cotarget ] (optional)Artifact that is related to the
target, and that needs be accessed for the testing. Identified by an
XPath expression that may refer to the related target node using the
variable '$target'. For example, the target can be a SOAP message and
the cotarget the WSDL file that describes this SOAP message.A cotarget
must have a @name attribute that identifies it. The value of this
attribute can be used as a variable (when prepending '$' to it) by
subsequently defined cotargets, prerequisite and predicate. |
Prerequisite:
|
[markup:
testAssertion/@preReq ] (optional)[markup: testAssertion/prerequisite ]
(optional)The pre-condition for evaluating this Test Assertion on this
target. If the prerequisite evaluates to "false" then the target does
not qualify for this Test Assertion (the test report is
"notRelevant")The first part (preReq attribute) is an enumeration of
Test Assertion IDs. Each one of the prerequisite TAs must either use
the same target (e.g. SOAP Envelope, or WSDL binding, etc.) as this TA,
or a target that is of a more general type than the main TA target. The
target must "pass" each one of these prerequisite TAs in order to
qualify for this TA.(e.g. the target of TA t1 can be a WSDL binding
while the target of a TA t2 prerequisite of t1, can be the entire WSDL
file).The second part ("prerequisite" element) is an XPath (boolean)
expression of the same nature as the predicate. If present, it must
evaluate to "true" for the target to qualify. If it fails, the result
for the current TA in the report will be "notRelevant". Otherwise, the
target can be further evaluated by the predicate of the main TA. The
expression may refer to the target explicitly using the variable name
"$target", or to any cotarget using its name as variable name ($[name]). |
Predicate:
|
[markup:
testAssertion/predicate] required element]A logical expression that
evaluates whether this target is fulfilling the profile requirement
addressed by this test Assertion. By default: - A result of true means
the requirement is fulfilled (reported as a "passed" in the test
report). - A result of false means the requirement is violated
(reported as a "failed" in the test report). However, in some cases and
for testability reasons, the predicate may be designed as a partial
indicator e.g. only indicates some cases of fulfillment, or some cases
of violation. As a result, when "true" indicates fulfillment it may be
that "false" is unconclusive, or conversely "false" will indicate
violation, but "true" is unconclusive. In such cases, the "Reporting"
element specifies the meaning of the predicate result w/r to the
profile requirement.The predicate expression implicitly refers to the
target (whic is its "XPath context") although it may explicitly refer
to it using the variable name "$target". It may refer to any cotarget
using its name as variable name ($[name]). |
Prescription:
|
[markup: testAssertion/prescription/@level ] (required)
Conveys the level of prescription associated with the profile requirement.
At least three values may be used:
mandatory: maps to RFC2119 keywords MUST, MUST NOT, SHALL,
SHALL NOT, REQUIRED (and sometimes MAY NOT) preferred: maps to RFC2119 keywords SHOULD, SHOULD NOT,
RECOMMENDED, NOT RECOMMENDED permitted: maps to RFC2119 keywords MAY, OPTIONAL. |
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: @true attribute: may take values among
{passed, failed, warning, undetermined} (default is 'passed') @false
attribute: may take values among {passed, failed, warning,
undetermined} (default is 'failed') The reported outcomes have the
following meaning:passed: the target passes the test and can be
considered as fulfilling the profile feature.failed: the target fails
the test and can be considered as violating (or not exhibiting) the
profile feature.warning: the test result is inconclusive. There is a
possibility of profile requirement violation, that deserved further
investigation.undetermined: the test result is inconclusive for this
predicate value.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:notRelevant: the
target failed the prerequisite condition and therefore does not qualify
for further testing (i.e. the predicate expression is NOT evaluated on
it).missingInput: a cotarget expression returned an empty node
set.notApplicable: this target was not even selected by the target
XPath expression, while being of the same general artifact type (e.g.
message type). |
R0102
An
RMD MUST accept unacknowledged message until the Sequence is closed or terminated.
TESTABLE
RSP0102
Test Assertion Analysis: |
RSP0102
|
General Notes: |
NOTE1:
a message should be intercepted, causing a gap in the Ack ranges.
Regardless of how long the delay before resending , the message must
finally be acknowledged if sequence not closed. |
Coverage Assessment: |
Good |
Target Type: |
ENVELOPE(with RM header) |
Test Target: |
For a message that is a resend, in a RM sequence that is not closed or terminated yet. |
Test co-Target(s): |
|
Test Prerequisite: |
|
Predicate: |
The message is not faulted by the RMD, AND the next acknowledgement shows it has been acknowledged. |
Prescription: |
mandatory |
Reporting: |
(default) |
Test Control: |
MIM to block messages, to cause significant delay in resending. |
Test Assertion: |
RSP0102
|
Description: |
|
Target: |
/wsil:testLog/wsil:messageLog/wsil:message/wsil:messageContents/*:Envelope
[*:Header/wsrm:Sequence = preceding::*:Envelope/*:Header/wsrm:Sequence]
[some $tgenv in . satisfies
not( some $clseq in $tgenv/preceding::*:Envelope[*:Body/wsrm:CloseSequence or *:Body/wsrm:TerminateSequence ] satisfies
$clseq/*:Body//wsrm:Identifier = $tgenv/*:Header/wsrm:Sequence/wsrm:Identifier
) ] |
Predicate: |
(
some $env in
following::*:Envelope[*:Header/wsrm:SequenceAcknowledgement/wsrm:Identifier
= $target/*:Header/wsrm:Sequence/wsrm:Identifier] satisfies some
$ackrange in
$env/*:Header/wsrm:SequenceAcknowledgement/wsrm:AcknowledgementRange
satisfies ($ackrange/@Lower le
$target/*:Header/wsrm:Sequence/wsrm:MessageNumber and $ackrange/@Upper
ge $target/*:Header/wsrm:Sequence/wsrm:MessageNumber) ) and not
(/wsil:testLog/wsil:messageLog/wsil:message[ (@type = 'response' and
@conversation = $target/../../@conversation) or
(.//*:Envelope/*:Header/wsa:RelatesTo[not (@RelationshipType) or (
@RelationshipType = 'http://www.w3.org/2005/08/addressing/reply' ) ] =
$target/*:Header/wsa:MessageID)]
/wsil:messageContents/*:Envelope/*:Body/*:Fault ) |
Reporting: |
true=passed, false=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: |
|
HELP - GLOSSARY
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:
passedfailedwarningnotApplicablenotRelevantmissingInputundeterminedSee
the "reporting" item for the meaning of these results. |
Cotarget:
|
[markup:
testAssertion/cotarget ] (optional)Artifact that is related to the
target, and that needs be accessed for the testing. Identified by an
XPath expression that may refer to the related target node using the
variable '$target'. For example, the target can be a SOAP message and
the cotarget the WSDL file that describes this SOAP message.A cotarget
must have a @name attribute that identifies it. The value of this
attribute can be used as a variable (when prepending '$' to it) by
subsequently defined cotargets, prerequisite and predicate. |
Prerequisite:
|
[markup:
testAssertion/@preReq ] (optional)[markup: testAssertion/prerequisite ]
(optional)The pre-condition for evaluating this Test Assertion on this
target. If the prerequisite evaluates to "false" then the target does
not qualify for this Test Assertion (the test report is
"notRelevant")The first part (preReq attribute) is an enumeration of
Test Assertion IDs. Each one of the prerequisite TAs must either use
the same target (e.g. SOAP Envelope, or WSDL binding, etc.) as this TA,
or a target that is of a more general type than the main TA target. The
target must "pass" each one of these prerequisite TAs in order to
qualify for this TA.(e.g. the target of TA t1 can be a WSDL binding
while the target of a TA t2 prerequisite of t1, can be the entire WSDL
file).The second part ("prerequisite" element) is an XPath (boolean)
expression of the same nature as the predicate. If present, it must
evaluate to "true" for the target to qualify. If it fails, the result
for the current TA in the report will be "notRelevant". Otherwise, the
target can be further evaluated by the predicate of the main TA. The
expression may refer to the target explicitly using the variable name
"$target", or to any cotarget using its name as variable name ($[name]). |
Predicate:
|
[markup:
testAssertion/predicate] required element]A logical expression that
evaluates whether this target is fulfilling the profile requirement
addressed by this test Assertion. By default: - A result of true means
the requirement is fulfilled (reported as a "passed" in the test
report). - A result of false means the requirement is violated
(reported as a "failed" in the test report). However, in some cases and
for testability reasons, the predicate may be designed as a partial
indicator e.g. only indicates some cases of fulfillment, or some cases
of violation. As a result, when "true" indicates fulfillment it may be
that "false" is unconclusive, or conversely "false" will indicate
violation, but "true" is unconclusive. In such cases, the "Reporting"
element specifies the meaning of the predicate result w/r to the
profile requirement.The predicate expression implicitly refers to the
target (whic is its "XPath context") although it may explicitly refer
to it using the variable name "$target". It may refer to any cotarget
using its name as variable name ($[name]). |
Prescription:
|
[markup: testAssertion/prescription/@level ] (required)
Conveys the level of prescription associated with the profile requirement.
At least three values may be used:
mandatory: maps to RFC2119 keywords MUST, MUST NOT, SHALL,
SHALL NOT, REQUIRED (and sometimes MAY NOT) preferred: maps to RFC2119 keywords SHOULD, SHOULD NOT,
RECOMMENDED, NOT RECOMMENDED permitted: maps to RFC2119 keywords MAY, OPTIONAL. |
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: @true attribute: may take values among
{passed, failed, warning, undetermined} (default is 'passed') @false
attribute: may take values among {passed, failed, warning,
undetermined} (default is 'failed') The reported outcomes have the
following meaning:passed: the target passes the test and can be
considered as fulfilling the profile feature.failed: the target fails
the test and can be considered as violating (or not exhibiting) the
profile feature.warning: the test result is inconclusive. There is a
possibility of profile requirement violation, that deserved further
investigation.undetermined: the test result is inconclusive for this
predicate value.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:notRelevant: the
target failed the prerequisite condition and therefore does not qualify
for further testing (i.e. the predicate expression is NOT evaluated on
it).missingInput: a cotarget expression returned an empty node
set.notApplicable: this target was not even selected by the target
XPath expression, while being of the same general artifact type (e.g.
message type). |
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. TBD
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: |
RSP0120
|
General Notes: |
|
Coverage Assessment: |
Good |
Target Type: |
ENVELOPE (with RM header) |
Test Target: |
For
any envelope with RM header, for which there exists at least one
preceeding envelope in the log with RM header featuring same
wsrm:Identifier and wsrm:MessageNumber elements, |
Test co-Target(s): |
|
Test Prerequisite: |
|
Predicate: |
either
the target envelope has no wsa:MessageID and every sibling envelope
does not have one, or the target envelope has wsa:MessageID and every
sibling envelope has the same. |
Prescription: |
mandatory |
Reporting: |
(default: true=pass, false=fail) |
Test Control: |
MIM config: Generate message resending - e.g. by blocking Acks, or blocking the regular messages. |
Test Assertion: |
RSP0120
|
Description: |
|
Target: |
/wsil:testLog/wsil:messageLog/wsil:message/wsil:messageContents/*:Envelope[
*:Header/wsrm:Sequence = preceding::*:Envelope/*:Header/wsrm:Sequence] |
Predicate: |
some $curenv in . satisfies
every $prevenv in preceding::*:Envelope[*:Header/wsrm:Sequence = $curenv/*:Header/wsrm:Sequence] satisfies
((not($prevenv/*:Header/wsa:MessageID) and not($curenv/*:Header/wsa:MessageID))
or
$prevenv/*:Header/wsa:MessageID = $curenv/*:Header/wsa:MessageID ) |
Reporting: |
true=passed, false=failed |
Prescription: |
mandatory |
Error Message: |
A
message has been resent (by an RMS), yet it had an wsa:MessageId
different from the previous sending, or the wsa:MessageId header was
present in one but not in the other. |
Diagnostic Data: |
|
HELP - GLOSSARY
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:
passedfailedwarningnotApplicablenotRelevantmissingInputundeterminedSee
the "reporting" item for the meaning of these results. |
Cotarget:
|
[markup:
testAssertion/cotarget ] (optional)Artifact that is related to the
target, and that needs be accessed for the testing. Identified by an
XPath expression that may refer to the related target node using the
variable '$target'. For example, the target can be a SOAP message and
the cotarget the WSDL file that describes this SOAP message.A cotarget
must have a @name attribute that identifies it. The value of this
attribute can be used as a variable (when prepending '$' to it) by
subsequently defined cotargets, prerequisite and predicate. |
Prerequisite:
|
[markup:
testAssertion/@preReq ] (optional)[markup: testAssertion/prerequisite ]
(optional)The pre-condition for evaluating this Test Assertion on this
target. If the prerequisite evaluates to "false" then the target does
not qualify for this Test Assertion (the test report is
"notRelevant")The first part (preReq attribute) is an enumeration of
Test Assertion IDs. Each one of the prerequisite TAs must either use
the same target (e.g. SOAP Envelope, or WSDL binding, etc.) as this TA,
or a target that is of a more general type than the main TA target. The
target must "pass" each one of these prerequisite TAs in order to
qualify for this TA.(e.g. the target of TA t1 can be a WSDL binding
while the target of a TA t2 prerequisite of t1, can be the entire WSDL
file).The second part ("prerequisite" element) is an XPath (boolean)
expression of the same nature as the predicate. If present, it must
evaluate to "true" for the target to qualify. If it fails, the result
for the current TA in the report will be "notRelevant". Otherwise, the
target can be further evaluated by the predicate of the main TA. The
expression may refer to the target explicitly using the variable name
"$target", or to any cotarget using its name as variable name ($[name]). |
Predicate:
|
[markup:
testAssertion/predicate] required element]A logical expression that
evaluates whether this target is fulfilling the profile requirement
addressed by this test Assertion. By default: - A result of true means
the requirement is fulfilled (reported as a "passed" in the test
report). - A result of false means the requirement is violated
(reported as a "failed" in the test report). However, in some cases and
for testability reasons, the predicate may be designed as a partial
indicator e.g. only indicates some cases of fulfillment, or some cases
of violation. As a result, when "true" indicates fulfillment it may be
that "false" is unconclusive, or conversely "false" will indicate
violation, but "true" is unconclusive. In such cases, the "Reporting"
element specifies the meaning of the predicate result w/r to the
profile requirement.The predicate expression implicitly refers to the
target (whic is its "XPath context") although it may explicitly refer
to it using the variable name "$target". It may refer to any cotarget
using its name as variable name ($[name]). |
Prescription:
|
[markup: testAssertion/prescription/@level ] (required)
Conveys the level of prescription associated with the profile requirement.
At least three values may be used:
mandatory: maps to RFC2119 keywords MUST, MUST NOT, SHALL,
SHALL NOT, REQUIRED (and sometimes MAY NOT) preferred: maps to RFC2119 keywords SHOULD, SHOULD NOT,
RECOMMENDED, NOT RECOMMENDED permitted: maps to RFC2119 keywords MAY, OPTIONAL. |
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: @true attribute: may take values among
{passed, failed, warning, undetermined} (default is 'passed') @false
attribute: may take values among {passed, failed, warning,
undetermined} (default is 'failed') The reported outcomes have the
following meaning:passed: the target passes the test and can be
considered as fulfilling the profile feature.failed: the target fails
the test and can be considered as violating (or not exhibiting) the
profile feature.warning: the test result is inconclusive. There is a
possibility of profile requirement violation, that deserved further
investigation.undetermined: the test result is inconclusive for this
predicate value.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:notRelevant: the
target failed the prerequisite condition and therefore does not qualify
for further testing (i.e. the predicate expression is NOT evaluated on
it).missingInput: a cotarget expression returned an empty node
set.notApplicable: this target was not even selected by the target
XPath expression, while being of the same general artifact type (e.g.
message type). |
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.
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: |
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: |
|
HELP - GLOSSARY
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:
passedfailedwarningnotApplicablenotRelevantmissingInputundeterminedSee
the "reporting" item for the meaning of these results. |
Cotarget:
|
[markup:
testAssertion/cotarget ] (optional)Artifact that is related to the
target, and that needs be accessed for the testing. Identified by an
XPath expression that may refer to the related target node using the
variable '$target'. For example, the target can be a SOAP message and
the cotarget the WSDL file that describes this SOAP message.A cotarget
must have a @name attribute that identifies it. The value of this
attribute can be used as a variable (when prepending '$' to it) by
subsequently defined cotargets, prerequisite and predicate. |
Prerequisite:
|
[markup:
testAssertion/@preReq ] (optional)[markup: testAssertion/prerequisite ]
(optional)The pre-condition for evaluating this Test Assertion on this
target. If the prerequisite evaluates to "false" then the target does
not qualify for this Test Assertion (the test report is
"notRelevant")The first part (preReq attribute) is an enumeration of
Test Assertion IDs. Each one of the prerequisite TAs must either use
the same target (e.g. SOAP Envelope, or WSDL binding, etc.) as this TA,
or a target that is of a more general type than the main TA target. The
target must "pass" each one of these prerequisite TAs in order to
qualify for this TA.(e.g. the target of TA t1 can be a WSDL binding
while the target of a TA t2 prerequisite of t1, can be the entire WSDL
file).The second part ("prerequisite" element) is an XPath (boolean)
expression of the same nature as the predicate. If present, it must
evaluate to "true" for the target to qualify. If it fails, the result
for the current TA in the report will be "notRelevant". Otherwise, the
target can be further evaluated by the predicate of the main TA. The
expression may refer to the target explicitly using the variable name
"$target", or to any cotarget using its name as variable name ($[name]). |
Predicate:
|
[markup:
testAssertion/predicate] required element]A logical expression that
evaluates whether this target is fulfilling the profile requirement
addressed by this test Assertion. By default: - A result of true means
the requirement is fulfilled (reported as a "passed" in the test
report). - A result of false means the requirement is violated
(reported as a "failed" in the test report). However, in some cases and
for testability reasons, the predicate may be designed as a partial
indicator e.g. only indicates some cases of fulfillment, or some cases
of violation. As a result, when "true" indicates fulfillment it may be
that "false" is unconclusive, or conversely "false" will indicate
violation, but "true" is unconclusive. In such cases, the "Reporting"
element specifies the meaning of the predicate result w/r to the
profile requirement.The predicate expression implicitly refers to the
target (whic is its "XPath context") although it may explicitly refer
to it using the variable name "$target". It may refer to any cotarget
using its name as variable name ($[name]). |
Prescription:
|
[markup: testAssertion/prescription/@level ] (required)
Conveys the level of prescription associated with the profile requirement.
At least three values may be used:
mandatory: maps to RFC2119 keywords MUST, MUST NOT, SHALL,
SHALL NOT, REQUIRED (and sometimes MAY NOT) preferred: maps to RFC2119 keywords SHOULD, SHOULD NOT,
RECOMMENDED, NOT RECOMMENDED permitted: maps to RFC2119 keywords MAY, OPTIONAL. |
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: @true attribute: may take values among
{passed, failed, warning, undetermined} (default is 'passed') @false
attribute: may take values among {passed, failed, warning,
undetermined} (default is 'failed') The reported outcomes have the
following meaning:passed: the target passes the test and can be
considered as fulfilling the profile feature.failed: the target fails
the test and can be considered as violating (or not exhibiting) the
profile feature.warning: the test result is inconclusive. There is a
possibility of profile requirement violation, that deserved further
investigation.undetermined: the test result is inconclusive for this
predicate value.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:notRelevant: the
target failed the prerequisite condition and therefore does not qualify
for further testing (i.e. the predicate expression is NOT evaluated on
it).missingInput: a cotarget expression returned an empty node
set.notApplicable: this target was not even selected by the target
XPath expression, while being of the same general artifact type (e.g.
message type). |
R0501
In cases where the AcksTo EPR of a Sequence has an Address value equal to the WS-Addressing 1.0 Anonymous URI, the
RMD MUST also limit piggybacking as described in section 3.9 of the WS-ReliableMessaging specification.
TESTABLE
RSP0501
Test Assertion Analysis: |
RSP0501
|
General Notes: |
Section
3.9 of WS-RM says that, when AcksTo is anonymous, the only way to
transmit acknowledgments is over the back-channel created by an STM
that is within the sequence to which the ack applies. The text in WS-RM
applies to all acknowledgements. This requirement highlights
piggybacked acknowledgments as a special case of this general rule.
Crafting an assertion that checks for violation of this requirement
should be fairly straightforward. However, to have any meaningful
coverage, we need test scenarios that create an environment capable of
stimulating the incorrect behavior. Essentially we need scenarios in
which a single client/RMS creates two or more sequences with a single
server/RMS using anonymous AcksTos in all the sequences and sends a
either a series of one-way message or a series of request-response
messages. To keep things simple, this later variation should not
include reliability for the response messages |
Coverage Assessment: |
Partial (piggybacking difficult to stimulate). |
Target Type: |
ENVELOPE |
Test Target: |
A SOAP Envelope in which:
a. One or more SequenceAcknowledgment headers appear.
b. The Body is not empty.
c. The value of wsa:To is http://www.w3.org/2005/08/addressing/anonymous or in which wsa:To is absent.
d. Transmitted in the body of an HTTP Response. |
Test co-Target(s): |
|
Test Prerequisite: |
|
Predicate: |
The
value of each /wsrm:SequenceAcknowledgment/wsrm:Identifier element in
the [target] matches the value of the /wsrm:Sequence/wsrm:Identifier in
the message contained in the corresponding HTTP Request. |
Prescription: |
mandatory |
Reporting: |
|
Test Control: |
Scenario:
x.x.x Reliable_One_Way_Requests_Anon_AcksTo_Multiple_Sequences The
client creates two sequences to the service in the identical way; the
CreateSequence message contains an anonymous AcksTo and there is no
Offer. The service supports a one-way message. The client reliably
sends a number of messages to the service, alternating the sequence for
each message. Scenario: x.x.x
Reliable_Requests_Unreliable_Response_Anon_AcksTo_Multiple_Sequences
The client creates two sequences to the service in the identical way;
the CreateSequence message contains an anonymous AcksTo and there is no
Offer. The service is configured to support
reliable-request/non-reliable response. The client reliably sends a
number of messages to the service, alternating the sequence for each
message. |
Test Assertion: |
RSP0501
|
Description: |
|
Target: |
/wsil:testLog/wsil:messageLog/wsil:message[@type = 'response']/wsil:messageContents/*:Envelope
[*:Header/wsrm:SequenceAcknowledgement and
(*:Header/wsa:To = 'http://www.w3.org/2005/08/addressing/anonymous' or
not(*:Header/wsa:To) ) and
*:Body/*] |
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)]) ] |
Prerequisite: |
;not ($myRequestMsg/wsil:messageContents/*:Envelope/*:Body/wsmc:MakeConnection ) |
Predicate: |
every $seqack in $target/*:Header/wsrm:SequenceAcknowledgement satisfies
($seqack/wsrm:Identifier = $myRequestMsg//*:Envelope/*:Header/wsrm:Sequence/wsrm:Identifier) |
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: |
|
HELP - GLOSSARY
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:
passedfailedwarningnotApplicablenotRelevantmissingInputundeterminedSee
the "reporting" item for the meaning of these results. |
Cotarget:
|
[markup:
testAssertion/cotarget ] (optional)Artifact that is related to the
target, and that needs be accessed for the testing. Identified by an
XPath expression that may refer to the related target node using the
variable '$target'. For example, the target can be a SOAP message and
the cotarget the WSDL file that describes this SOAP message.A cotarget
must have a @name attribute that identifies it. The value of this
attribute can be used as a variable (when prepending '$' to it) by
subsequently defined cotargets, prerequisite and predicate. |
Prerequisite:
|
[markup:
testAssertion/@preReq ] (optional)[markup: testAssertion/prerequisite ]
(optional)The pre-condition for evaluating this Test Assertion on this
target. If the prerequisite evaluates to "false" then the target does
not qualify for this Test Assertion (the test report is
"notRelevant")The first part (preReq attribute) is an enumeration of
Test Assertion IDs. Each one of the prerequisite TAs must either use
the same target (e.g. SOAP Envelope, or WSDL binding, etc.) as this TA,
or a target that is of a more general type than the main TA target. The
target must "pass" each one of these prerequisite TAs in order to
qualify for this TA.(e.g. the target of TA t1 can be a WSDL binding
while the target of a TA t2 prerequisite of t1, can be the entire WSDL
file).The second part ("prerequisite" element) is an XPath (boolean)
expression of the same nature as the predicate. If present, it must
evaluate to "true" for the target to qualify. If it fails, the result
for the current TA in the report will be "notRelevant". Otherwise, the
target can be further evaluated by the predicate of the main TA. The
expression may refer to the target explicitly using the variable name
"$target", or to any cotarget using its name as variable name ($[name]). |
Predicate:
|
[markup:
testAssertion/predicate] required element]A logical expression that
evaluates whether this target is fulfilling the profile requirement
addressed by this test Assertion. By default: - A result of true means
the requirement is fulfilled (reported as a "passed" in the test
report). - A result of false means the requirement is violated
(reported as a "failed" in the test report). However, in some cases and
for testability reasons, the predicate may be designed as a partial
indicator e.g. only indicates some cases of fulfillment, or some cases
of violation. As a result, when "true" indicates fulfillment it may be
that "false" is unconclusive, or conversely "false" will indicate
violation, but "true" is unconclusive. In such cases, the "Reporting"
element specifies the meaning of the predicate result w/r to the
profile requirement.The predicate expression implicitly refers to the
target (whic is its "XPath context") although it may explicitly refer
to it using the variable name "$target". It may refer to any cotarget
using its name as variable name ($[name]). |
Prescription:
|
[markup: testAssertion/prescription/@level ] (required)
Conveys the level of prescription associated with the profile requirement.
At least three values may be used:
mandatory: maps to RFC2119 keywords MUST, MUST NOT, SHALL,
SHALL NOT, REQUIRED (and sometimes MAY NOT) preferred: maps to RFC2119 keywords SHOULD, SHOULD NOT,
RECOMMENDED, NOT RECOMMENDED permitted: maps to RFC2119 keywords MAY, OPTIONAL. |
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: @true attribute: may take values among
{passed, failed, warning, undetermined} (default is 'passed') @false
attribute: may take values among {passed, failed, warning,
undetermined} (default is 'failed') The reported outcomes have the
following meaning:passed: the target passes the test and can be
considered as fulfilling the profile feature.failed: the target fails
the test and can be considered as violating (or not exhibiting) the
profile feature.warning: the test result is inconclusive. There is a
possibility of profile requirement violation, that deserved further
investigation.undetermined: the test result is inconclusive for this
predicate value.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:notRelevant: the
target failed the prerequisite condition and therefore does not qualify
for further testing (i.e. the predicate expression is NOT evaluated on
it).missingInput: a cotarget expression returned an empty node
set.notApplicable: this target was not even selected by the target
XPath expression, while being of the same general artifact type (e.g.
message type). |
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: |
|
HELP - GLOSSARY
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:
passedfailedwarningnotApplicablenotRelevantmissingInputundeterminedSee
the "reporting" item for the meaning of these results. |
Cotarget:
|
[markup:
testAssertion/cotarget ] (optional)Artifact that is related to the
target, and that needs be accessed for the testing. Identified by an
XPath expression that may refer to the related target node using the
variable '$target'. For example, the target can be a SOAP message and
the cotarget the WSDL file that describes this SOAP message.A cotarget
must have a @name attribute that identifies it. The value of this
attribute can be used as a variable (when prepending '$' to it) by
subsequently defined cotargets, prerequisite and predicate. |
Prerequisite:
|
[markup:
testAssertion/@preReq ] (optional)[markup: testAssertion/prerequisite ]
(optional)The pre-condition for evaluating this Test Assertion on this
target. If the prerequisite evaluates to "false" then the target does
not qualify for this Test Assertion (the test report is
"notRelevant")The first part (preReq attribute) is an enumeration of
Test Assertion IDs. Each one of the prerequisite TAs must either use
the same target (e.g. SOAP Envelope, or WSDL binding, etc.) as this TA,
or a target that is of a more general type than the main TA target. The
target must "pass" each one of these prerequisite TAs in order to
qualify for this TA.(e.g. the target of TA t1 can be a WSDL binding
while the target of a TA t2 prerequisite of t1, can be the entire WSDL
file).The second part ("prerequisite" element) is an XPath (boolean)
expression of the same nature as the predicate. If present, it must
evaluate to "true" for the target to qualify. If it fails, the result
for the current TA in the report will be "notRelevant". Otherwise, the
target can be further evaluated by the predicate of the main TA. The
expression may refer to the target explicitly using the variable name
"$target", or to any cotarget using its name as variable name ($[name]). |
Predicate:
|
[markup:
testAssertion/predicate] required element]A logical expression that
evaluates whether this target is fulfilling the profile requirement
addressed by this test Assertion. By default: - A result of true means
the requirement is fulfilled (reported as a "passed" in the test
report). - A result of false means the requirement is violated
(reported as a "failed" in the test report). However, in some cases and
for testability reasons, the predicate may be designed as a partial
indicator e.g. only indicates some cases of fulfillment, or some cases
of violation. As a result, when "true" indicates fulfillment it may be
that "false" is unconclusive, or conversely "false" will indicate
violation, but "true" is unconclusive. In such cases, the "Reporting"
element specifies the meaning of the predicate result w/r to the
profile requirement.The predicate expression implicitly refers to the
target (whic is its "XPath context") although it may explicitly refer
to it using the variable name "$target". It may refer to any cotarget
using its name as variable name ($[name]). |
Prescription:
|
[markup: testAssertion/prescription/@level ] (required)
Conveys the level of prescription associated with the profile requirement.
At least three values may be used:
mandatory: maps to RFC2119 keywords MUST, MUST NOT, SHALL,
SHALL NOT, REQUIRED (and sometimes MAY NOT) preferred: maps to RFC2119 keywords SHOULD, SHOULD NOT,
RECOMMENDED, NOT RECOMMENDED permitted: maps to RFC2119 keywords MAY, OPTIONAL. |
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: @true attribute: may take values among
{passed, failed, warning, undetermined} (default is 'passed') @false
attribute: may take values among {passed, failed, warning,
undetermined} (default is 'failed') The reported outcomes have the
following meaning:passed: the target passes the test and can be
considered as fulfilling the profile feature.failed: the target fails
the test and can be considered as violating (or not exhibiting) the
profile feature.warning: the test result is inconclusive. There is a
possibility of profile requirement violation, that deserved further
investigation.undetermined: the test result is inconclusive for this
predicate value.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:notRelevant: the
target failed the prerequisite condition and therefore does not qualify
for further testing (i.e. the predicate expression is NOT evaluated on
it).missingInput: a cotarget expression returned an empty node
set.notApplicable: this target was not even selected by the target
XPath expression, while being of the same general artifact type (e.g.
message type). |
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: |
RSP0530
|
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
[ *:Header/wsrm:SequenceAcknowledgement and not(*:Body/* ) and (
*:Header/wsa:RelatesTo[@RelationshipType =
'http://www.w3.org/2005/08/addressing/reply' or not
(@RelationshipType)] = ./preceding::*:Envelope/*:Header/wsa:MessageID
or ../../@type = 'response') ] |
co-Target:
myOpBind |
//wsil:descriptionFile/wsdl:definitions/wsdl:binding/wsdl:operation
[ some $opb in . satisfies some $req in
$target/preceding::wsil:message/wsil:messageContents/*:Envelope[
*:Header/wsa:ReplyTo or ./../../@type = 'request' ] satisfies (
($target/*:Header/wsa:RelatesTo[@RelationshipType =
'http://www.w3.org/2005/08/addressing/reply' or not
(@RelationshipType)] = $req/*:Header/wsa:MessageID) or
($target/../../@type = 'response' and $target/../../@conversation =
$req/../../@conversation) ) and ( $opb/@name =
local-name-from-QName(node-name($req/*:Body/*[1])) or (some $pop in
$opb/../../wsdl:portType/wsdl:operation[@name = $opb/@name] satisfies
some $dmsg in
$opb/../../wsdl:message[fn:resolve-QName(xsd:string(wsdl:part[1]/@element),
.) = fn:node-name($target/*:Body/*[1])] satisfies
fn:ends-with($pop/wsdl:output/@message, $dmsg/@name)) ) ] |
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 ($target/*:Header/wsa:Action
= $op/wsdl:output/@wsam:Action) |
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: |
|
HELP - GLOSSARY
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:
passedfailedwarningnotApplicablenotRelevantmissingInputundeterminedSee
the "reporting" item for the meaning of these results. |
Cotarget:
|
[markup:
testAssertion/cotarget ] (optional)Artifact that is related to the
target, and that needs be accessed for the testing. Identified by an
XPath expression that may refer to the related target node using the
variable '$target'. For example, the target can be a SOAP message and
the cotarget the WSDL file that describes this SOAP message.A cotarget
must have a @name attribute that identifies it. The value of this
attribute can be used as a variable (when prepending '$' to it) by
subsequently defined cotargets, prerequisite and predicate. |
Prerequisite:
|
[markup:
testAssertion/@preReq ] (optional)[markup: testAssertion/prerequisite ]
(optional)The pre-condition for evaluating this Test Assertion on this
target. If the prerequisite evaluates to "false" then the target does
not qualify for this Test Assertion (the test report is
"notRelevant")The first part (preReq attribute) is an enumeration of
Test Assertion IDs. Each one of the prerequisite TAs must either use
the same target (e.g. SOAP Envelope, or WSDL binding, etc.) as this TA,
or a target that is of a more general type than the main TA target. The
target must "pass" each one of these prerequisite TAs in order to
qualify for this TA.(e.g. the target of TA t1 can be a WSDL binding
while the target of a TA t2 prerequisite of t1, can be the entire WSDL
file).The second part ("prerequisite" element) is an XPath (boolean)
expression of the same nature as the predicate. If present, it must
evaluate to "true" for the target to qualify. If it fails, the result
for the current TA in the report will be "notRelevant". Otherwise, the
target can be further evaluated by the predicate of the main TA. The
expression may refer to the target explicitly using the variable name
"$target", or to any cotarget using its name as variable name ($[name]). |
Predicate:
|
[markup:
testAssertion/predicate] required element]A logical expression that
evaluates whether this target is fulfilling the profile requirement
addressed by this test Assertion. By default: - A result of true means
the requirement is fulfilled (reported as a "passed" in the test
report). - A result of false means the requirement is violated
(reported as a "failed" in the test report). However, in some cases and
for testability reasons, the predicate may be designed as a partial
indicator e.g. only indicates some cases of fulfillment, or some cases
of violation. As a result, when "true" indicates fulfillment it may be
that "false" is unconclusive, or conversely "false" will indicate
violation, but "true" is unconclusive. In such cases, the "Reporting"
element specifies the meaning of the predicate result w/r to the
profile requirement.The predicate expression implicitly refers to the
target (whic is its "XPath context") although it may explicitly refer
to it using the variable name "$target". It may refer to any cotarget
using its name as variable name ($[name]). |
Prescription:
|
[markup: testAssertion/prescription/@level ] (required)
Conveys the level of prescription associated with the profile requirement.
At least three values may be used:
mandatory: maps to RFC2119 keywords MUST, MUST NOT, SHALL,
SHALL NOT, REQUIRED (and sometimes MAY NOT) preferred: maps to RFC2119 keywords SHOULD, SHOULD NOT,
RECOMMENDED, NOT RECOMMENDED permitted: maps to RFC2119 keywords MAY, OPTIONAL. |
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: @true attribute: may take values among
{passed, failed, warning, undetermined} (default is 'passed') @false
attribute: may take values among {passed, failed, warning,
undetermined} (default is 'failed') The reported outcomes have the
following meaning:passed: the target passes the test and can be
considered as fulfilling the profile feature.failed: the target fails
the test and can be considered as violating (or not exhibiting) the
profile feature.warning: the test result is inconclusive. There is a
possibility of profile requirement violation, that deserved further
investigation.undetermined: the test result is inconclusive for this
predicate value.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:notRelevant: the
target failed the prerequisite condition and therefore does not qualify
for further testing (i.e. the predicate expression is NOT evaluated on
it).missingInput: a cotarget expression returned an empty node
set.notApplicable: this target was not even selected by the target
XPath expression, while being of the same general artifact type (e.g.
message type). |
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. TBD
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: |
RSP1000
|
General Notes: |
NOTE1:
We are not sure how to stimulate this fault. we might be able to send a
particular token that we do not expect any service to (willingly)
support. or we could send all of the type of well known tokens and
report those that are not supported by a particular implementation
report this specific fault. can test only those tokens we make up or
know about (cannot test all potential custom tokens) |
Coverage Assessment: |
Partial |
Target Type: |
ENVELOPE (Fault) |
Test Target: |
fault returned instead of response to unknown RST, (correlation done with wsa) |
Test co-Target(s): |
|
Test Prerequisite: |
|
Predicate: |
Exists a Fault message that correlates, with faultcode=stated in requirement |
Prescription: |
mandatory |
Reporting: |
true=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: |
|
HELP - GLOSSARY
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:
passedfailedwarningnotApplicablenotRelevantmissingInputundeterminedSee
the "reporting" item for the meaning of these results. |
Cotarget:
|
[markup:
testAssertion/cotarget ] (optional)Artifact that is related to the
target, and that needs be accessed for the testing. Identified by an
XPath expression that may refer to the related target node using the
variable '$target'. For example, the target can be a SOAP message and
the cotarget the WSDL file that describes this SOAP message.A cotarget
must have a @name attribute that identifies it. The value of this
attribute can be used as a variable (when prepending '$' to it) by
subsequently defined cotargets, prerequisite and predicate. |
Prerequisite:
|
[markup:
testAssertion/@preReq ] (optional)[markup: testAssertion/prerequisite ]
(optional)The pre-condition for evaluating this Test Assertion on this
target. If the prerequisite evaluates to "false" then the target does
not qualify for this Test Assertion (the test report is
"notRelevant")The first part (preReq attribute) is an enumeration of
Test Assertion IDs. Each one of the prerequisite TAs must either use
the same target (e.g. SOAP Envelope, or WSDL binding, etc.) as this TA,
or a target that is of a more general type than the main TA target. The
target must "pass" each one of these prerequisite TAs in order to
qualify for this TA.(e.g. the target of TA t1 can be a WSDL binding
while the target of a TA t2 prerequisite of t1, can be the entire WSDL
file).The second part ("prerequisite" element) is an XPath (boolean)
expression of the same nature as the predicate. If present, it must
evaluate to "true" for the target to qualify. If it fails, the result
for the current TA in the report will be "notRelevant". Otherwise, the
target can be further evaluated by the predicate of the main TA. The
expression may refer to the target explicitly using the variable name
"$target", or to any cotarget using its name as variable name ($[name]). |
Predicate:
|
[markup:
testAssertion/predicate] required element]A logical expression that
evaluates whether this target is fulfilling the profile requirement
addressed by this test Assertion. By default: - A result of true means
the requirement is fulfilled (reported as a "passed" in the test
report). - A result of false means the requirement is violated
(reported as a "failed" in the test report). However, in some cases and
for testability reasons, the predicate may be designed as a partial
indicator e.g. only indicates some cases of fulfillment, or some cases
of violation. As a result, when "true" indicates fulfillment it may be
that "false" is unconclusive, or conversely "false" will indicate
violation, but "true" is unconclusive. In such cases, the "Reporting"
element specifies the meaning of the predicate result w/r to the
profile requirement.The predicate expression implicitly refers to the
target (whic is its "XPath context") although it may explicitly refer
to it using the variable name "$target". It may refer to any cotarget
using its name as variable name ($[name]). |
Prescription:
|
[markup: testAssertion/prescription/@level ] (required)
Conveys the level of prescription associated with the profile requirement.
At least three values may be used:
mandatory: maps to RFC2119 keywords MUST, MUST NOT, SHALL,
SHALL NOT, REQUIRED (and sometimes MAY NOT) preferred: maps to RFC2119 keywords SHOULD, SHOULD NOT,
RECOMMENDED, NOT RECOMMENDED permitted: maps to RFC2119 keywords MAY, OPTIONAL. |
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: @true attribute: may take values among
{passed, failed, warning, undetermined} (default is 'passed') @false
attribute: may take values among {passed, failed, warning,
undetermined} (default is 'failed') The reported outcomes have the
following meaning:passed: the target passes the test and can be
considered as fulfilling the profile feature.failed: the target fails
the test and can be considered as violating (or not exhibiting) the
profile feature.warning: the test result is inconclusive. There is a
possibility of profile requirement violation, that deserved further
investigation.undetermined: the test result is inconclusive for this
predicate value.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:notRelevant: the
target failed the prerequisite condition and therefore does not qualify
for further testing (i.e. the predicate expression is NOT evaluated on
it).missingInput: a cotarget expression returned an empty node
set.notApplicable: this target was not even selected by the target
XPath expression, while being of the same general artifact type (e.g.
message type). |
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. TBD
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: |
RSP1100
|
General Notes: |
NOTE1: the predicate is weaker than the profile req, hence true=undetermined, but false= a sure failure. |
Coverage Assessment: |
Partial |
Target Type: |
ENVELOPE (with wst:RST) |
Test Target: |
For an Envelope with RST and action URI=.... |
Test co-Target(s): |
|
Test Prerequisite: |
|
Predicate: |
It has Security header that references SOAP body. |
Prescription: |
mandatory |
Reporting: |
true=undetermined, false=fail |
Test Control: |
Text env: must implement RMS->scenario to generate the TA context |
Test Assertion: |
RSP1100
|
Description: |
|
Target: |
/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/Amend'] |
Predicate: |
some $dsig in $target/*:Header/wsse:Security//ds:Signature satisfies
($dsig//ds:Reference[fn:substring-after(@URI, '#') eq $target/@wsu:Id])
or (
($dsig//ds:Reference[fn:substring-after(@URI, '#') eq $target/*:Header/@wsu:Id] or
(every $cruxp in $target/*:Header/wsrm:* | $target/*:Header/wsa:* satisfies
some $ref in $dsig//ds:Reference satisfies
fn:substring-after($ref/@URI, '#') = $cruxp/@wsu:Id))
and (
$dsig//ds:Reference[fn:substring-after(@URI, '#') eq $target/*:Body/@wsu:Id] or
(every $cruxp in $target/*:Body/* satisfies
some $ref in $dsig//ds:Reference satisfies
fn:substring-after($ref/@URI, '#') = $cruxp/@wsu:Id ))
)
|
Reporting: |
true=passed, false=failed |
Prescription: |
mandatory |
Error Message: |
An
ENVELOPE containing a wst:RequestSecurityToken for amending a Security
Context, does not contain a Signature element in a wsse header that
references both the SOAP body (using @wsu:Id) and crucial wsrm or wsa
headers. |
Diagnostic Data: |
|
HELP - GLOSSARY
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:
passedfailedwarningnotApplicablenotRelevantmissingInputundeterminedSee
the "reporting" item for the meaning of these results. |
Cotarget:
|
[markup:
testAssertion/cotarget ] (optional)Artifact that is related to the
target, and that needs be accessed for the testing. Identified by an
XPath expression that may refer to the related target node using the
variable '$target'. For example, the target can be a SOAP message and
the cotarget the WSDL file that describes this SOAP message.A cotarget
must have a @name attribute that identifies it. The value of this
attribute can be used as a variable (when prepending '$' to it) by
subsequently defined cotargets, prerequisite and predicate. |
Prerequisite:
|
[markup:
testAssertion/@preReq ] (optional)[markup: testAssertion/prerequisite ]
(optional)The pre-condition for evaluating this Test Assertion on this
target. If the prerequisite evaluates to "false" then the target does
not qualify for this Test Assertion (the test report is
"notRelevant")The first part (preReq attribute) is an enumeration of
Test Assertion IDs. Each one of the prerequisite TAs must either use
the same target (e.g. SOAP Envelope, or WSDL binding, etc.) as this TA,
or a target that is of a more general type than the main TA target. The
target must "pass" each one of these prerequisite TAs in order to
qualify for this TA.(e.g. the target of TA t1 can be a WSDL binding
while the target of a TA t2 prerequisite of t1, can be the entire WSDL
file).The second part ("prerequisite" element) is an XPath (boolean)
expression of the same nature as the predicate. If present, it must
evaluate to "true" for the target to qualify. If it fails, the result
for the current TA in the report will be "notRelevant". Otherwise, the
target can be further evaluated by the predicate of the main TA. The
expression may refer to the target explicitly using the variable name
"$target", or to any cotarget using its name as variable name ($[name]). |
Predicate:
|
[markup:
testAssertion/predicate] required element]A logical expression that
evaluates whether this target is fulfilling the profile requirement
addressed by this test Assertion. By default: - A result of true means
the requirement is fulfilled (reported as a "passed" in the test
report). - A result of false means the requirement is violated
(reported as a "failed" in the test report). However, in some cases and
for testability reasons, the predicate may be designed as a partial
indicator e.g. only indicates some cases of fulfillment, or some cases
of violation. As a result, when "true" indicates fulfillment it may be
that "false" is unconclusive, or conversely "false" will indicate
violation, but "true" is unconclusive. In such cases, the "Reporting"
element specifies the meaning of the predicate result w/r to the
profile requirement.The predicate expression implicitly refers to the
target (whic is its "XPath context") although it may explicitly refer
to it using the variable name "$target". It may refer to any cotarget
using its name as variable name ($[name]). |
Prescription:
|
[markup: testAssertion/prescription/@level ] (required)
Conveys the level of prescription associated with the profile requirement.
At least three values may be used:
mandatory: maps to RFC2119 keywords MUST, MUST NOT, SHALL,
SHALL NOT, REQUIRED (and sometimes MAY NOT) preferred: maps to RFC2119 keywords SHOULD, SHOULD NOT,
RECOMMENDED, NOT RECOMMENDED permitted: maps to RFC2119 keywords MAY, OPTIONAL. |
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: @true attribute: may take values among
{passed, failed, warning, undetermined} (default is 'passed') @false
attribute: may take values among {passed, failed, warning,
undetermined} (default is 'failed') The reported outcomes have the
following meaning:passed: the target passes the test and can be
considered as fulfilling the profile feature.failed: the target fails
the test and can be considered as violating (or not exhibiting) the
profile feature.warning: the test result is inconclusive. There is a
possibility of profile requirement violation, that deserved further
investigation.undetermined: the test result is inconclusive for this
predicate value.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:notRelevant: the
target failed the prerequisite condition and therefore does not qualify
for further testing (i.e. the predicate expression is NOT evaluated on
it).missingInput: a cotarget expression returned an empty node
set.notApplicable: this target was not even selected by the target
XPath expression, while being of the same general artifact type (e.g.
message type). |
R1101
In an
ENVELOPE, the signature referred to in R1100 MUST be created using the key associated with the security context that is being amended.
NOT_TESTABLE
COM1101
Test Assertion Analysis: |
COM1101
|
General Notes: |
untestable due to key comparison issue. Same for R1111, R1121. |
Coverage Assessment: |
|
Target Type: |
|
Test Target: |
|
Test co-Target(s): |
|
Test Prerequisite: |
|
Predicate: |
|
Prescription: |
mandatory |
Reporting: |
|
Test Control: |
|
Test Assertion: |
COM1101
|
Description: |
|
Target: |
|
Predicate: |
|
Reporting: |
true=passed, false=failed |
Prescription: |
mandatory |
Error Message: |
|
Diagnostic Data: |
|
HELP - GLOSSARY
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:
passedfailedwarningnotApplicablenotRelevantmissingInputundeterminedSee
the "reporting" item for the meaning of these results. |
Cotarget:
|
[markup:
testAssertion/cotarget ] (optional)Artifact that is related to the
target, and that needs be accessed for the testing. Identified by an
XPath expression that may refer to the related target node using the
variable '$target'. For example, the target can be a SOAP message and
the cotarget the WSDL file that describes this SOAP message.A cotarget
must have a @name attribute that identifies it. The value of this
attribute can be used as a variable (when prepending '$' to it) by
subsequently defined cotargets, prerequisite and predicate. |
Prerequisite:
|
[markup:
testAssertion/@preReq ] (optional)[markup: testAssertion/prerequisite ]
(optional)The pre-condition for evaluating this Test Assertion on this
target. If the prerequisite evaluates to "false" then the target does
not qualify for this Test Assertion (the test report is
"notRelevant")The first part (preReq attribute) is an enumeration of
Test Assertion IDs. Each one of the prerequisite TAs must either use
the same target (e.g. SOAP Envelope, or WSDL binding, etc.) as this TA,
or a target that is of a more general type than the main TA target. The
target must "pass" each one of these prerequisite TAs in order to
qualify for this TA.(e.g. the target of TA t1 can be a WSDL binding
while the target of a TA t2 prerequisite of t1, can be the entire WSDL
file).The second part ("prerequisite" element) is an XPath (boolean)
expression of the same nature as the predicate. If present, it must
evaluate to "true" for the target to qualify. If it fails, the result
for the current TA in the report will be "notRelevant". Otherwise, the
target can be further evaluated by the predicate of the main TA. The
expression may refer to the target explicitly using the variable name
"$target", or to any cotarget using its name as variable name ($[name]). |
Predicate:
|
[markup:
testAssertion/predicate] required element]A logical expression that
evaluates whether this target is fulfilling the profile requirement
addressed by this test Assertion. By default: - A result of true means
the requirement is fulfilled (reported as a "passed" in the test
report). - A result of false means the requirement is violated
(reported as a "failed" in the test report). However, in some cases and
for testability reasons, the predicate may be designed as a partial
indicator e.g. only indicates some cases of fulfillment, or some cases
of violation. As a result, when "true" indicates fulfillment it may be
that "false" is unconclusive, or conversely "false" will indicate
violation, but "true" is unconclusive. In such cases, the "Reporting"
element specifies the meaning of the predicate result w/r to the
profile requirement.The predicate expression implicitly refers to the
target (whic is its "XPath context") although it may explicitly refer
to it using the variable name "$target". It may refer to any cotarget
using its name as variable name ($[name]). |
Prescription:
|
[markup: testAssertion/prescription/@level ] (required)
Conveys the level of prescription associated with the profile requirement.
At least three values may be used:
mandatory: maps to RFC2119 keywords MUST, MUST NOT, SHALL,
SHALL NOT, REQUIRED (and sometimes MAY NOT) preferred: maps to RFC2119 keywords SHOULD, SHOULD NOT,
RECOMMENDED, NOT RECOMMENDED permitted: maps to RFC2119 keywords MAY, OPTIONAL. |
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: @true attribute: may take values among
{passed, failed, warning, undetermined} (default is 'passed') @false
attribute: may take values among {passed, failed, warning,
undetermined} (default is 'failed') The reported outcomes have the
following meaning:passed: the target passes the test and can be
considered as fulfilling the profile feature.failed: the target fails
the test and can be considered as violating (or not exhibiting) the
profile feature.warning: the test result is inconclusive. There is a
possibility of profile requirement violation, that deserved further
investigation.undetermined: the test result is inconclusive for this
predicate value.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:notRelevant: the
target failed the prerequisite condition and therefore does not qualify
for further testing (i.e. the predicate expression is NOT evaluated on
it).missingInput: a cotarget expression returned an empty node
set.notApplicable: this target was not even selected by the target
XPath expression, while being of the same general artifact type (e.g.
message type). |
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: |
RSP1110
|
General Notes: |
NOTE1: the predicate is weaker than the profile req, hence true=undetermined, but false= a sure failure. |
Coverage Assessment: |
Partial |
Target Type: |
ENVELOPE |
Test Target: |
For an Envelope with RST and action URI=.... |
Test co-Target(s): |
|
Test Prerequisite: |
|
Predicate: |
It has Security header that references SOAP body. |
Prescription: |
mandatory |
Reporting: |
true=undetermined, false=fail |
Test Control: |
Text env: must implement RMS->scenario to generate the TA context |
Test Assertion: |
RSP1110
|
Description: |
|
Target: |
/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'] |
Predicate: |
some $dsig in $target/*:Header/wsse:Security//ds:Signature satisfies
($dsig//ds:Reference[fn:substring-after(@URI, '#') eq $target/@wsu:Id])
or (
($dsig//ds:Reference[fn:substring-after(@URI, '#') eq $target/*:Header/@wsu:Id] or
(every $cruxp in $target/*:Header/wsrm:* | $target/*:Header/wsa:* satisfies
some $ref in $dsig//ds:Reference satisfies
fn:substring-after($ref/@URI, '#') = $cruxp/@wsu:Id))
and (
$dsig//ds:Reference[fn:substring-after(@URI, '#') eq $target/*:Body/@wsu:Id] or
(every $cruxp in $target/*:Body/* satisfies
some $ref in $dsig//ds:Reference satisfies
fn:substring-after($ref/@URI, '#') = $cruxp/@wsu:Id ))
)
|
Reporting: |
true=passed, false=failed |
Prescription: |
mandatory |
Error Message: |
An
ENVELOPE containing a wst:RequestSecurityToken for 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: |
|
HELP - GLOSSARY
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:
passedfailedwarningnotApplicablenotRelevantmissingInputundeterminedSee
the "reporting" item for the meaning of these results. |
Cotarget:
|
[markup:
testAssertion/cotarget ] (optional)Artifact that is related to the
target, and that needs be accessed for the testing. Identified by an
XPath expression that may refer to the related target node using the
variable '$target'. For example, the target can be a SOAP message and
the cotarget the WSDL file that describes this SOAP message.A cotarget
must have a @name attribute that identifies it. The value of this
attribute can be used as a variable (when prepending '$' to it) by
subsequently defined cotargets, prerequisite and predicate. |
Prerequisite:
|
[markup:
testAssertion/@preReq ] (optional)[markup: testAssertion/prerequisite ]
(optional)The pre-condition for evaluating this Test Assertion on this
target. If the prerequisite evaluates to "false" then the target does
not qualify for this Test Assertion (the test report is
"notRelevant")The first part (preReq attribute) is an enumeration of
Test Assertion IDs. Each one of the prerequisite TAs must either use
the same target (e.g. SOAP Envelope, or WSDL binding, etc.) as this TA,
or a target that is of a more general type than the main TA target. The
target must "pass" each one of these prerequisite TAs in order to
qualify for this TA.(e.g. the target of TA t1 can be a WSDL binding
while the target of a TA t2 prerequisite of t1, can be the entire WSDL
file).The second part ("prerequisite" element) is an XPath (boolean)
expression of the same nature as the predicate. If present, it must
evaluate to "true" for the target to qualify. If it fails, the result
for the current TA in the report will be "notRelevant". Otherwise, the
target can be further evaluated by the predicate of the main TA. The
expression may refer to the target explicitly using the variable name
"$target", or to any cotarget using its name as variable name ($[name]). |
Predicate:
|
[markup:
testAssertion/predicate] required element]A logical expression that
evaluates whether this target is fulfilling the profile requirement
addressed by this test Assertion. By default: - A result of true means
the requirement is fulfilled (reported as a "passed" in the test
report). - A result of false means the requirement is violated
(reported as a "failed" in the test report). However, in some cases and
for testability reasons, the predicate may be designed as a partial
indicator e.g. only indicates some cases of fulfillment, or some cases
of violation. As a result, when "true" indicates fulfillment it may be
that "false" is unconclusive, or conversely "false" will indicate
violation, but "true" is unconclusive. In such cases, the "Reporting"
element specifies the meaning of the predicate result w/r to the
profile requirement.The predicate expression implicitly refers to the
target (whic is its "XPath context") although it may explicitly refer
to it using the variable name "$target". It may refer to any cotarget
using its name as variable name ($[name]). |
Prescription:
|
[markup: testAssertion/prescription/@level ] (required)
Conveys the level of prescription associated with the profile requirement.
At least three values may be used:
mandatory: maps to RFC2119 keywords MUST, MUST NOT, SHALL,
SHALL NOT, REQUIRED (and sometimes MAY NOT) preferred: maps to RFC2119 keywords SHOULD, SHOULD NOT,
RECOMMENDED, NOT RECOMMENDED permitted: maps to RFC2119 keywords MAY, OPTIONAL. |
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: @true attribute: may take values among
{passed, failed, warning, undetermined} (default is 'passed') @false
attribute: may take values among {passed, failed, warning,
undetermined} (default is 'failed') The reported outcomes have the
following meaning:passed: the target passes the test and can be
considered as fulfilling the profile feature.failed: the target fails
the test and can be considered as violating (or not exhibiting) the
profile feature.warning: the test result is inconclusive. There is a
possibility of profile requirement violation, that deserved further
investigation.undetermined: the test result is inconclusive for this
predicate value.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:notRelevant: the
target failed the prerequisite condition and therefore does not qualify
for further testing (i.e. the predicate expression is NOT evaluated on
it).missingInput: a cotarget expression returned an empty node
set.notApplicable: this target was not even selected by the target
XPath expression, while being of the same general artifact type (e.g.
message type). |
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: |
RSP1120
|
General Notes: |
NOTE1: the predicate is weaker than the profile req, hence true=undetermined, but false= a sure failure. |
Coverage Assessment: |
Partial |
Target Type: |
ENVELOPE |
Test Target: |
For an Envelope with RST and action URI=.... |
Test co-Target(s): |
|
Test Prerequisite: |
|
Predicate: |
It has Security header that references SOAP body. |
Prescription: |
mandatory |
Reporting: |
true=undetermined, false=fail |
Test Control: |
Text env: must implement RMS->scenario to generate the TA context |
Test Assertion: |
RSP1120
|
Description: |
|
Target: |
/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/Cancel'] |
Predicate: |
some $dsig in $target/*:Header/wsse:Security//ds:Signature satisfies
($dsig//ds:Reference[fn:substring-after(@URI, '#') eq $target/@wsu:Id])
or (
($dsig//ds:Reference[fn:substring-after(@URI, '#') eq $target/*:Header/@wsu:Id] or
(every $cruxp in $target/*:Header/wsrm:* | $target/*:Header/wsa:* satisfies
some $ref in $dsig//ds:Reference satisfies
fn:substring-after($ref/@URI, '#') = $cruxp/@wsu:Id))
and (
$dsig//ds:Reference[fn:substring-after(@URI, '#') eq $target/*:Body/@wsu:Id] or
(every $cruxp in $target/*:Body/* satisfies
some $ref in $dsig//ds:Reference satisfies
fn:substring-after($ref/@URI, '#') = $cruxp/@wsu:Id ))
)
|
Reporting: |
true=passed, false=failed |
Prescription: |
mandatory |
Error Message: |
An
ENVELOPE containing a wst:RequestSecurityToken for 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: |
|
HELP - GLOSSARY
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:
passedfailedwarningnotApplicablenotRelevantmissingInputundeterminedSee
the "reporting" item for the meaning of these results. |
Cotarget:
|
[markup:
testAssertion/cotarget ] (optional)Artifact that is related to the
target, and that needs be accessed for the testing. Identified by an
XPath expression that may refer to the related target node using the
variable '$target'. For example, the target can be a SOAP message and
the cotarget the WSDL file that describes this SOAP message.A cotarget
must have a @name attribute that identifies it. The value of this
attribute can be used as a variable (when prepending '$' to it) by
subsequently defined cotargets, prerequisite and predicate. |
Prerequisite:
|
[markup:
testAssertion/@preReq ] (optional)[markup: testAssertion/prerequisite ]
(optional)The pre-condition for evaluating this Test Assertion on this
target. If the prerequisite evaluates to "false" then the target does
not qualify for this Test Assertion (the test report is
"notRelevant")The first part (preReq attribute) is an enumeration of
Test Assertion IDs. Each one of the prerequisite TAs must either use
the same target (e.g. SOAP Envelope, or WSDL binding, etc.) as this TA,
or a target that is of a more general type than the main TA target. The
target must "pass" each one of these prerequisite TAs in order to
qualify for this TA.(e.g. the target of TA t1 can be a WSDL binding
while the target of a TA t2 prerequisite of t1, can be the entire WSDL
file).The second part ("prerequisite" element) is an XPath (boolean)
expression of the same nature as the predicate. If present, it must
evaluate to "true" for the target to qualify. If it fails, the result
for the current TA in the report will be "notRelevant". Otherwise, the
target can be further evaluated by the predicate of the main TA. The
expression may refer to the target explicitly using the variable name
"$target", or to any cotarget using its name as variable name ($[name]). |
Predicate:
|
[markup:
testAssertion/predicate] required element]A logical expression that
evaluates whether this target is fulfilling the profile requirement
addressed by this test Assertion. By default: - A result of true means
the requirement is fulfilled (reported as a "passed" in the test
report). - A result of false means the requirement is violated
(reported as a "failed" in the test report). However, in some cases and
for testability reasons, the predicate may be designed as a partial
indicator e.g. only indicates some cases of fulfillment, or some cases
of violation. As a result, when "true" indicates fulfillment it may be
that "false" is unconclusive, or conversely "false" will indicate
violation, but "true" is unconclusive. In such cases, the "Reporting"
element specifies the meaning of the predicate result w/r to the
profile requirement.The predicate expression implicitly refers to the
target (whic is its "XPath context") although it may explicitly refer
to it using the variable name "$target". It may refer to any cotarget
using its name as variable name ($[name]). |
Prescription:
|
[markup: testAssertion/prescription/@level ] (required)
Conveys the level of prescription associated with the profile requirement.
At least three values may be used:
mandatory: maps to RFC2119 keywords MUST, MUST NOT, SHALL,
SHALL NOT, REQUIRED (and sometimes MAY NOT) preferred: maps to RFC2119 keywords SHOULD, SHOULD NOT,
RECOMMENDED, NOT RECOMMENDED permitted: maps to RFC2119 keywords MAY, OPTIONAL. |
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: @true attribute: may take values among
{passed, failed, warning, undetermined} (default is 'passed') @false
attribute: may take values among {passed, failed, warning,
undetermined} (default is 'failed') The reported outcomes have the
following meaning:passed: the target passes the test and can be
considered as fulfilling the profile feature.failed: the target fails
the test and can be considered as violating (or not exhibiting) the
profile feature.warning: the test result is inconclusive. There is a
possibility of profile requirement violation, that deserved further
investigation.undetermined: the test result is inconclusive for this
predicate value.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:notRelevant: the
target failed the prerequisite condition and therefore does not qualify
for further testing (i.e. the predicate expression is NOT evaluated on
it).missingInput: a cotarget expression returned an empty node
set.notApplicable: this target was not even selected by the target
XPath expression, while being of the same general artifact type (e.g.
message type). |
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.
TBD
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: |
RSP1200
|
General Notes: |
|
Coverage Assessment: |
Partial |
Target Type: |
ENVELOPE |
Test Target: |
For an Envelope with RST/SCT/renew action URI |
Test co-Target(s): |
|
Test Prerequisite: |
|
Predicate: |
It correlates with RSTR/SCT that correlates with original RST and renew that has auth mechanism |
Prescription: |
mandatory |
Reporting: |
true=warning, false=warning |
Test Control: |
|
Test Assertion: |
RSP1200
|
Description: |
|
Target: |
/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 |
$target/preceding::*: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: |
|
HELP - GLOSSARY
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:
passedfailedwarningnotApplicablenotRelevantmissingInputundeterminedSee
the "reporting" item for the meaning of these results. |
Cotarget:
|
[markup:
testAssertion/cotarget ] (optional)Artifact that is related to the
target, and that needs be accessed for the testing. Identified by an
XPath expression that may refer to the related target node using the
variable '$target'. For example, the target can be a SOAP message and
the cotarget the WSDL file that describes this SOAP message.A cotarget
must have a @name attribute that identifies it. The value of this
attribute can be used as a variable (when prepending '$' to it) by
subsequently defined cotargets, prerequisite and predicate. |
Prerequisite:
|
[markup:
testAssertion/@preReq ] (optional)[markup: testAssertion/prerequisite ]
(optional)The pre-condition for evaluating this Test Assertion on this
target. If the prerequisite evaluates to "false" then the target does
not qualify for this Test Assertion (the test report is
"notRelevant")The first part (preReq attribute) is an enumeration of
Test Assertion IDs. Each one of the prerequisite TAs must either use
the same target (e.g. SOAP Envelope, or WSDL binding, etc.) as this TA,
or a target that is of a more general type than the main TA target. The
target must "pass" each one of these prerequisite TAs in order to
qualify for this TA.(e.g. the target of TA t1 can be a WSDL binding
while the target of a TA t2 prerequisite of t1, can be the entire WSDL
file).The second part ("prerequisite" element) is an XPath (boolean)
expression of the same nature as the predicate. If present, it must
evaluate to "true" for the target to qualify. If it fails, the result
for the current TA in the report will be "notRelevant". Otherwise, the
target can be further evaluated by the predicate of the main TA. The
expression may refer to the target explicitly using the variable name
"$target", or to any cotarget using its name as variable name ($[name]). |
Predicate:
|
[markup:
testAssertion/predicate] required element]A logical expression that
evaluates whether this target is fulfilling the profile requirement
addressed by this test Assertion. By default: - A result of true means
the requirement is fulfilled (reported as a "passed" in the test
report). - A result of false means the requirement is violated
(reported as a "failed" in the test report). However, in some cases and
for testability reasons, the predicate may be designed as a partial
indicator e.g. only indicates some cases of fulfillment, or some cases
of violation. As a result, when "true" indicates fulfillment it may be
that "false" is unconclusive, or conversely "false" will indicate
violation, but "true" is unconclusive. In such cases, the "Reporting"
element specifies the meaning of the predicate result w/r to the
profile requirement.The predicate expression implicitly refers to the
target (whic is its "XPath context") although it may explicitly refer
to it using the variable name "$target". It may refer to any cotarget
using its name as variable name ($[name]). |
Prescription:
|
[markup: testAssertion/prescription/@level ] (required)
Conveys the level of prescription associated with the profile requirement.
At least three values may be used:
mandatory: maps to RFC2119 keywords MUST, MUST NOT, SHALL,
SHALL NOT, REQUIRED (and sometimes MAY NOT) preferred: maps to RFC2119 keywords SHOULD, SHOULD NOT,
RECOMMENDED, NOT RECOMMENDED permitted: maps to RFC2119 keywords MAY, OPTIONAL. |
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: @true attribute: may take values among
{passed, failed, warning, undetermined} (default is 'passed') @false
attribute: may take values among {passed, failed, warning,
undetermined} (default is 'failed') The reported outcomes have the
following meaning:passed: the target passes the test and can be
considered as fulfilling the profile feature.failed: the target fails
the test and can be considered as violating (or not exhibiting) the
profile feature.warning: the test result is inconclusive. There is a
possibility of profile requirement violation, that deserved further
investigation.undetermined: the test result is inconclusive for this
predicate value.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:notRelevant: the
target failed the prerequisite condition and therefore does not qualify
for further testing (i.e. the predicate expression is NOT evaluated on
it).missingInput: a cotarget expression returned an empty node
set.notApplicable: this target was not even selected by the target
XPath expression, while being of the same general artifact type (e.g.
message type). |
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: |
RSP1300
|
General Notes: |
NOTE1:Type=Feature
Usage. NOTE2: investigate ways at improving the context. NOTE3:
coverage is good, but possiblemany false negatives |
Coverage Assessment: |
Good |
Target Type: |
ENVELOPE |
Test Target: |
For an Envelope with wssc:Security or RST or RSTR and with SCT refs |
Test co-Target(s): |
|
Test Prerequisite: |
|
Predicate: |
In the envelope, there exists wssc:STR/ref [@URI does not start with "#"] |
Prescription: |
mandatory |
Reporting: |
true=pass, false=warning |
Test Control: |
scenario to provide context. |
Test Assertion: |
RSP1300
|
Description: |
|
Target: |
/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: |
|
HELP - GLOSSARY
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:
passedfailedwarningnotApplicablenotRelevantmissingInputundeterminedSee
the "reporting" item for the meaning of these results. |
Cotarget:
|
[markup:
testAssertion/cotarget ] (optional)Artifact that is related to the
target, and that needs be accessed for the testing. Identified by an
XPath expression that may refer to the related target node using the
variable '$target'. For example, the target can be a SOAP message and
the cotarget the WSDL file that describes this SOAP message.A cotarget
must have a @name attribute that identifies it. The value of this
attribute can be used as a variable (when prepending '$' to it) by
subsequently defined cotargets, prerequisite and predicate. |
Prerequisite:
|
[markup:
testAssertion/@preReq ] (optional)[markup: testAssertion/prerequisite ]
(optional)The pre-condition for evaluating this Test Assertion on this
target. If the prerequisite evaluates to "false" then the target does
not qualify for this Test Assertion (the test report is
"notRelevant")The first part (preReq attribute) is an enumeration of
Test Assertion IDs. Each one of the prerequisite TAs must either use
the same target (e.g. SOAP Envelope, or WSDL binding, etc.) as this TA,
or a target that is of a more general type than the main TA target. The
target must "pass" each one of these prerequisite TAs in order to
qualify for this TA.(e.g. the target of TA t1 can be a WSDL binding
while the target of a TA t2 prerequisite of t1, can be the entire WSDL
file).The second part ("prerequisite" element) is an XPath (boolean)
expression of the same nature as the predicate. If present, it must
evaluate to "true" for the target to qualify. If it fails, the result
for the current TA in the report will be "notRelevant". Otherwise, the
target can be further evaluated by the predicate of the main TA. The
expression may refer to the target explicitly using the variable name
"$target", or to any cotarget using its name as variable name ($[name]). |
Predicate:
|
[markup:
testAssertion/predicate] required element]A logical expression that
evaluates whether this target is fulfilling the profile requirement
addressed by this test Assertion. By default: - A result of true means
the requirement is fulfilled (reported as a "passed" in the test
report). - A result of false means the requirement is violated
(reported as a "failed" in the test report). However, in some cases and
for testability reasons, the predicate may be designed as a partial
indicator e.g. only indicates some cases of fulfillment, or some cases
of violation. As a result, when "true" indicates fulfillment it may be
that "false" is unconclusive, or conversely "false" will indicate
violation, but "true" is unconclusive. In such cases, the "Reporting"
element specifies the meaning of the predicate result w/r to the
profile requirement.The predicate expression implicitly refers to the
target (whic is its "XPath context") although it may explicitly refer
to it using the variable name "$target". It may refer to any cotarget
using its name as variable name ($[name]). |
Prescription:
|
[markup: testAssertion/prescription/@level ] (required)
Conveys the level of prescription associated with the profile requirement.
At least three values may be used:
mandatory: maps to RFC2119 keywords MUST, MUST NOT, SHALL,
SHALL NOT, REQUIRED (and sometimes MAY NOT) preferred: maps to RFC2119 keywords SHOULD, SHOULD NOT,
RECOMMENDED, NOT RECOMMENDED permitted: maps to RFC2119 keywords MAY, OPTIONAL. |
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: @true attribute: may take values among
{passed, failed, warning, undetermined} (default is 'passed') @false
attribute: may take values among {passed, failed, warning,
undetermined} (default is 'failed') The reported outcomes have the
following meaning:passed: the target passes the test and can be
considered as fulfilling the profile feature.failed: the target fails
the test and can be considered as violating (or not exhibiting) the
profile feature.warning: the test result is inconclusive. There is a
possibility of profile requirement violation, that deserved further
investigation.undetermined: the test result is inconclusive for this
predicate value.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:notRelevant: the
target failed the prerequisite condition and therefore does not qualify
for further testing (i.e. the predicate expression is NOT evaluated on
it).missingInput: a cotarget expression returned an empty node
set.notApplicable: this target was not even selected by the target
XPath expression, while being of the same general artifact type (e.g.
message type). |
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: |
RSP1310
|
General Notes: |
|
Coverage Assessment: |
Good |
Target Type: |
ENVELOPE |
Test Target: |
For an Envelope with wsc:DKT |
Test co-Target(s): |
|
Test Prerequisite: |
|
Predicate: |
there exists DKT/STR and there exists a message with (SCT/identifier=STR/Refrence@URI) |
Prescription: |
mandatory |
Reporting: |
(default) |
Test Control: |
|
Test Assertion: |
RSP1310
|
Description: |
|
Target: |
/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: |
|
HELP - GLOSSARY
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:
passedfailedwarningnotApplicablenotRelevantmissingInputundeterminedSee
the "reporting" item for the meaning of these results. |
Cotarget:
|
[markup:
testAssertion/cotarget ] (optional)Artifact that is related to the
target, and that needs be accessed for the testing. Identified by an
XPath expression that may refer to the related target node using the
variable '$target'. For example, the target can be a SOAP message and
the cotarget the WSDL file that describes this SOAP message.A cotarget
must have a @name attribute that identifies it. The value of this
attribute can be used as a variable (when prepending '$' to it) by
subsequently defined cotargets, prerequisite and predicate. |
Prerequisite:
|
[markup:
testAssertion/@preReq ] (optional)[markup: testAssertion/prerequisite ]
(optional)The pre-condition for evaluating this Test Assertion on this
target. If the prerequisite evaluates to "false" then the target does
not qualify for this Test Assertion (the test report is
"notRelevant")The first part (preReq attribute) is an enumeration of
Test Assertion IDs. Each one of the prerequisite TAs must either use
the same target (e.g. SOAP Envelope, or WSDL binding, etc.) as this TA,
or a target that is of a more general type than the main TA target. The
target must "pass" each one of these prerequisite TAs in order to
qualify for this TA.(e.g. the target of TA t1 can be a WSDL binding
while the target of a TA t2 prerequisite of t1, can be the entire WSDL
file).The second part ("prerequisite" element) is an XPath (boolean)
expression of the same nature as the predicate. If present, it must
evaluate to "true" for the target to qualify. If it fails, the result
for the current TA in the report will be "notRelevant". Otherwise, the
target can be further evaluated by the predicate of the main TA. The
expression may refer to the target explicitly using the variable name
"$target", or to any cotarget using its name as variable name ($[name]). |
Predicate:
|
[markup:
testAssertion/predicate] required element]A logical expression that
evaluates whether this target is fulfilling the profile requirement
addressed by this test Assertion. By default: - A result of true means
the requirement is fulfilled (reported as a "passed" in the test
report). - A result of false means the requirement is violated
(reported as a "failed" in the test report). However, in some cases and
for testability reasons, the predicate may be designed as a partial
indicator e.g. only indicates some cases of fulfillment, or some cases
of violation. As a result, when "true" indicates fulfillment it may be
that "false" is unconclusive, or conversely "false" will indicate
violation, but "true" is unconclusive. In such cases, the "Reporting"
element specifies the meaning of the predicate result w/r to the
profile requirement.The predicate expression implicitly refers to the
target (whic is its "XPath context") although it may explicitly refer
to it using the variable name "$target". It may refer to any cotarget
using its name as variable name ($[name]). |
Prescription:
|
[markup: testAssertion/prescription/@level ] (required)
Conveys the level of prescription associated with the profile requirement.
At least three values may be used:
mandatory: maps to RFC2119 keywords MUST, MUST NOT, SHALL,
SHALL NOT, REQUIRED (and sometimes MAY NOT) preferred: maps to RFC2119 keywords SHOULD, SHOULD NOT,
RECOMMENDED, NOT RECOMMENDED permitted: maps to RFC2119 keywords MAY, OPTIONAL. |
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: @true attribute: may take values among
{passed, failed, warning, undetermined} (default is 'passed') @false
attribute: may take values among {passed, failed, warning,
undetermined} (default is 'failed') The reported outcomes have the
following meaning:passed: the target passes the test and can be
considered as fulfilling the profile feature.failed: the target fails
the test and can be considered as violating (or not exhibiting) the
profile feature.warning: the test result is inconclusive. There is a
possibility of profile requirement violation, that deserved further
investigation.undetermined: the test result is inconclusive for this
predicate value.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:notRelevant: the
target failed the prerequisite condition and therefore does not qualify
for further testing (i.e. the predicate expression is NOT evaluated on
it).missingInput: a cotarget expression returned an empty node
set.notApplicable: this target was not even selected by the target
XPath expression, while being of the same general artifact type (e.g.
message type). |
To
properly and interoperably process derived keys it is necessary to
relate the key to the shared secret from which it is derived. There are
no alternatives to using wsse:SecurityTokenReference's that are
consistent with WS-Security.
Since
the semantics of the WS-SecureConversation protocol are dependent upon
the value of various WS-Addressing headers, ensuring the proper
functioning of WS-SecureConversation requires protecting the integrity
of these headers. These requirements are not specific to the use of
WS-SecureConversation. They also apply whenever WS-Security is being
used in conjunction with WS-Addressing.
R1400
When present in an
ENVELOPE in which the SOAP Body in that ENVELOPE is signed, each of the following SOAP header blocks MUST be included in a signature:
wsa:To
,
wsa:From
,
wsa:ReplyTo
,
wsa:Action
,
wsa:FaultTo
,
wsa:MessageId
,
wsa:RelatesTo
.
TESTABLE
RSP1400
Test Assertion Analysis: |
RSP1400
|
General Notes: |
|
Coverage Assessment: |
|
Target Type: |
ENVELOPE |
Test Target: |
Envelope with a signed body and some wsa headers. |
Test co-Target(s): |
|
Test Prerequisite: |
|
Predicate: |
|
Prescription: |
mandatory |
Reporting: |
(default) |
Test Control: |
|
Test Assertion: |
RSP1400
|
Description: |
|
Target: |
/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: |
|
HELP - GLOSSARY
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:
passedfailedwarningnotApplicablenotRelevantmissingInputundeterminedSee
the "reporting" item for the meaning of these results. |
Cotarget:
|
[markup:
testAssertion/cotarget ] (optional)Artifact that is related to the
target, and that needs be accessed for the testing. Identified by an
XPath expression that may refer to the related target node using the
variable '$target'. For example, the target can be a SOAP message and
the cotarget the WSDL file that describes this SOAP message.A cotarget
must have a @name attribute that identifies it. The value of this
attribute can be used as a variable (when prepending '$' to it) by
subsequently defined cotargets, prerequisite and predicate. |
Prerequisite:
|
[markup:
testAssertion/@preReq ] (optional)[markup: testAssertion/prerequisite ]
(optional)The pre-condition for evaluating this Test Assertion on this
target. If the prerequisite evaluates to "false" then the target does
not qualify for this Test Assertion (the test report is
"notRelevant")The first part (preReq attribute) is an enumeration of
Test Assertion IDs. Each one of the prerequisite TAs must either use
the same target (e.g. SOAP Envelope, or WSDL binding, etc.) as this TA,
or a target that is of a more general type than the main TA target. The
target must "pass" each one of these prerequisite TAs in order to
qualify for this TA.(e.g. the target of TA t1 can be a WSDL binding
while the target of a TA t2 prerequisite of t1, can be the entire WSDL
file).The second part ("prerequisite" element) is an XPath (boolean)
expression of the same nature as the predicate. If present, it must
evaluate to "true" for the target to qualify. If it fails, the result
for the current TA in the report will be "notRelevant". Otherwise, the
target can be further evaluated by the predicate of the main TA. The
expression may refer to the target explicitly using the variable name
"$target", or to any cotarget using its name as variable name ($[name]). |
Predicate:
|
[markup:
testAssertion/predicate] required element]A logical expression that
evaluates whether this target is fulfilling the profile requirement
addressed by this test Assertion. By default: - A result of true means
the requirement is fulfilled (reported as a "passed" in the test
report). - A result of false means the requirement is violated
(reported as a "failed" in the test report). However, in some cases and
for testability reasons, the predicate may be designed as a partial
indicator e.g. only indicates some cases of fulfillment, or some cases
of violation. As a result, when "true" indicates fulfillment it may be
that "false" is unconclusive, or conversely "false" will indicate
violation, but "true" is unconclusive. In such cases, the "Reporting"
element specifies the meaning of the predicate result w/r to the
profile requirement.The predicate expression implicitly refers to the
target (whic is its "XPath context") although it may explicitly refer
to it using the variable name "$target". It may refer to any cotarget
using its name as variable name ($[name]). |
Prescription:
|
[markup: testAssertion/prescription/@level ] (required)
Conveys the level of prescription associated with the profile requirement.
At least three values may be used:
mandatory: maps to RFC2119 keywords MUST, MUST NOT, SHALL,
SHALL NOT, REQUIRED (and sometimes MAY NOT) preferred: maps to RFC2119 keywords SHOULD, SHOULD NOT,
RECOMMENDED, NOT RECOMMENDED permitted: maps to RFC2119 keywords MAY, OPTIONAL. |
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: @true attribute: may take values among
{passed, failed, warning, undetermined} (default is 'passed') @false
attribute: may take values among {passed, failed, warning,
undetermined} (default is 'failed') The reported outcomes have the
following meaning:passed: the target passes the test and can be
considered as fulfilling the profile feature.failed: the target fails
the test and can be considered as violating (or not exhibiting) the
profile feature.warning: the test result is inconclusive. There is a
possibility of profile requirement violation, that deserved further
investigation.undetermined: the test result is inconclusive for this
predicate value.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:notRelevant: the
target failed the prerequisite condition and therefore does not qualify
for further testing (i.e. the predicate expression is NOT evaluated on
it).missingInput: a cotarget expression returned an empty node
set.notApplicable: this target was not even selected by the target
XPath expression, while being of the same general artifact type (e.g.
message type). |
R1401
In an
ENVELOPE, the signature(s) referred to in R1400 MUST be coupled cryptographically (e.g. share a common signature) with the message body.
TESTABLE
RSP1401
Test Assertion Analysis: |
RSP1401
|
General Notes: |
|
Coverage Assessment: |
partial (does not cover UnknownSequence Fault) |
Target Type: |
ENVELOPE |
Test Target: |
Envelope with Soap11 Fault. a SOAP11 fault that has in its detail element wsrm identifier that refers to a known Secured Seq |
Test co-Target(s): |
|
Test Prerequisite: |
|
Predicate: |
|
Prescription: |
mandatory |
Reporting: |
(default) |
Test Control: |
|
Test Assertion: |
RSP1401
|
Description: |
|
Target: |
/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: |
|
HELP - GLOSSARY
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:
passedfailedwarningnotApplicablenotRelevantmissingInputundeterminedSee
the "reporting" item for the meaning of these results. |
Cotarget:
|
[markup:
testAssertion/cotarget ] (optional)Artifact that is related to the
target, and that needs be accessed for the testing. Identified by an
XPath expression that may refer to the related target node using the
variable '$target'. For example, the target can be a SOAP message and
the cotarget the WSDL file that describes this SOAP message.A cotarget
must have a @name attribute that identifies it. The value of this
attribute can be used as a variable (when prepending '$' to it) by
subsequently defined cotargets, prerequisite and predicate. |
Prerequisite:
|
[markup:
testAssertion/@preReq ] (optional)[markup: testAssertion/prerequisite ]
(optional)The pre-condition for evaluating this Test Assertion on this
target. If the prerequisite evaluates to "false" then the target does
not qualify for this Test Assertion (the test report is
"notRelevant")The first part (preReq attribute) is an enumeration of
Test Assertion IDs. Each one of the prerequisite TAs must either use
the same target (e.g. SOAP Envelope, or WSDL binding, etc.) as this TA,
or a target that is of a more general type than the main TA target. The
target must "pass" each one of these prerequisite TAs in order to
qualify for this TA.(e.g. the target of TA t1 can be a WSDL binding
while the target of a TA t2 prerequisite of t1, can be the entire WSDL
file).The second part ("prerequisite" element) is an XPath (boolean)
expression of the same nature as the predicate. If present, it must
evaluate to "true" for the target to qualify. If it fails, the result
for the current TA in the report will be "notRelevant". Otherwise, the
target can be further evaluated by the predicate of the main TA. The
expression may refer to the target explicitly using the variable name
"$target", or to any cotarget using its name as variable name ($[name]). |
Predicate:
|
[markup:
testAssertion/predicate] required element]A logical expression that
evaluates whether this target is fulfilling the profile requirement
addressed by this test Assertion. By default: - A result of true means
the requirement is fulfilled (reported as a "passed" in the test
report). - A result of false means the requirement is violated
(reported as a "failed" in the test report). However, in some cases and
for testability reasons, the predicate may be designed as a partial
indicator e.g. only indicates some cases of fulfillment, or some cases
of violation. As a result, when "true" indicates fulfillment it may be
that "false" is unconclusive, or conversely "false" will indicate
violation, but "true" is unconclusive. In such cases, the "Reporting"
element specifies the meaning of the predicate result w/r to the
profile requirement.The predicate expression implicitly refers to the
target (whic is its "XPath context") although it may explicitly refer
to it using the variable name "$target". It may refer to any cotarget
using its name as variable name ($[name]). |
Prescription:
|
[markup: testAssertion/prescription/@level ] (required)
Conveys the level of prescription associated with the profile requirement.
At least three values may be used:
mandatory: maps to RFC2119 keywords MUST, MUST NOT, SHALL,
SHALL NOT, REQUIRED (and sometimes MAY NOT) preferred: maps to RFC2119 keywords SHOULD, SHOULD NOT,
RECOMMENDED, NOT RECOMMENDED permitted: maps to RFC2119 keywords MAY, OPTIONAL. |
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: @true attribute: may take values among
{passed, failed, warning, undetermined} (default is 'passed') @false
attribute: may take values among {passed, failed, warning,
undetermined} (default is 'failed') The reported outcomes have the
following meaning:passed: the target passes the test and can be
considered as fulfilling the profile feature.failed: the target fails
the test and can be considered as violating (or not exhibiting) the
profile feature.warning: the test result is inconclusive. There is a
possibility of profile requirement violation, that deserved further
investigation.undetermined: the test result is inconclusive for this
predicate value.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:notRelevant: the
target failed the prerequisite condition and therefore does not qualify
for further testing (i.e. the predicate expression is NOT evaluated on
it).missingInput: a cotarget expression returned an empty node
set.notApplicable: this target was not even selected by the target
XPath expression, while being of the same general artifact type (e.g.
message type). |
R1402
When present in an
ENVELOPE
in which the SOAP Body in that ENVELOPE is signed, SOAP Header blocks
with the wsa:isReferenceParameter attribute MUST be included in a
signature for their designated SOAP role. TESTABLE
RSP1402
Test Assertion Analysis: |
RSP1402
|
General Notes: |
|
Coverage Assessment: |
|
Target Type: |
ENVELOPE |
Test Target: |
Envelope with a signed body and some wsa headers. |
Test co-Target(s): |
|
Test Prerequisite: |
|
Predicate: |
|
Prescription: |
mandatory |
Reporting: |
(default) |
Test Control: |
|
Test Assertion: |
RSP1402
|
Description: |
|
Target: |
/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: |
|
HELP - GLOSSARY
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:
passedfailedwarningnotApplicablenotRelevantmissingInputundeterminedSee
the "reporting" item for the meaning of these results. |
Cotarget:
|
[markup:
testAssertion/cotarget ] (optional)Artifact that is related to the
target, and that needs be accessed for the testing. Identified by an
XPath expression that may refer to the related target node using the
variable '$target'. For example, the target can be a SOAP message and
the cotarget the WSDL file that describes this SOAP message.A cotarget
must have a @name attribute that identifies it. The value of this
attribute can be used as a variable (when prepending '$' to it) by
subsequently defined cotargets, prerequisite and predicate. |
Prerequisite:
|
[markup:
testAssertion/@preReq ] (optional)[markup: testAssertion/prerequisite ]
(optional)The pre-condition for evaluating this Test Assertion on this
target. If the prerequisite evaluates to "false" then the target does
not qualify for this Test Assertion (the test report is
"notRelevant")The first part (preReq attribute) is an enumeration of
Test Assertion IDs. Each one of the prerequisite TAs must either use
the same target (e.g. SOAP Envelope, or WSDL binding, etc.) as this TA,
or a target that is of a more general type than the main TA target. The
target must "pass" each one of these prerequisite TAs in order to
qualify for this TA.(e.g. the target of TA t1 can be a WSDL binding
while the target of a TA t2 prerequisite of t1, can be the entire WSDL
file).The second part ("prerequisite" element) is an XPath (boolean)
expression of the same nature as the predicate. If present, it must
evaluate to "true" for the target to qualify. If it fails, the result
for the current TA in the report will be "notRelevant". Otherwise, the
target can be further evaluated by the predicate of the main TA. The
expression may refer to the target explicitly using the variable name
"$target", or to any cotarget using its name as variable name ($[name]). |
Predicate:
|
[markup:
testAssertion/predicate] required element]A logical expression that
evaluates whether this target is fulfilling the profile requirement
addressed by this test Assertion. By default: - A result of true means
the requirement is fulfilled (reported as a "passed" in the test
report). - A result of false means the requirement is violated
(reported as a "failed" in the test report). However, in some cases and
for testability reasons, the predicate may be designed as a partial
indicator e.g. only indicates some cases of fulfillment, or some cases
of violation. As a result, when "true" indicates fulfillment it may be
that "false" is unconclusive, or conversely "false" will indicate
violation, but "true" is unconclusive. In such cases, the "Reporting"
element specifies the meaning of the predicate result w/r to the
profile requirement.The predicate expression implicitly refers to the
target (whic is its "XPath context") although it may explicitly refer
to it using the variable name "$target". It may refer to any cotarget
using its name as variable name ($[name]). |
Prescription:
|
[markup: testAssertion/prescription/@level ] (required)
Conveys the level of prescription associated with the profile requirement.
At least three values may be used:
mandatory: maps to RFC2119 keywords MUST, MUST NOT, SHALL,
SHALL NOT, REQUIRED (and sometimes MAY NOT) preferred: maps to RFC2119 keywords SHOULD, SHOULD NOT,
RECOMMENDED, NOT RECOMMENDED permitted: maps to RFC2119 keywords MAY, OPTIONAL. |
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: @true attribute: may take values among
{passed, failed, warning, undetermined} (default is 'passed') @false
attribute: may take values among {passed, failed, warning,
undetermined} (default is 'failed') The reported outcomes have the
following meaning:passed: the target passes the test and can be
considered as fulfilling the profile feature.failed: the target fails
the test and can be considered as violating (or not exhibiting) the
profile feature.warning: the test result is inconclusive. There is a
possibility of profile requirement violation, that deserved further
investigation.undetermined: the test result is inconclusive for this
predicate value.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:notRelevant: the
target failed the prerequisite condition and therefore does not qualify
for further testing (i.e. the predicate expression is NOT evaluated on
it).missingInput: a cotarget expression returned an empty node
set.notApplicable: this target was not even selected by the target
XPath expression, while being of the same general artifact type (e.g.
message type). |
R1403
In an
ENVELOPE, the signature(s) referred to in R1402 MUST be coupled cryptographically (e.g. share a common signature) with the message body.
TESTABLE
RSP1403
Test Assertion Analysis: |
RSP1403
|
General Notes: |
|
Coverage Assessment: |
partial (does not cover UnknownSequence Fault) |
Target Type: |
ENVELOPE |
Test Target: |
Envelope with Soap11 Fault. a SOAP11 fault that has in its detail element wsrm identifier that refers to a known Secured Seq |
Test co-Target(s): |
|
Test Prerequisite: |
|
Predicate: |
|
Prescription: |
mandatory |
Reporting: |
(default) |
Test Control: |
|
Test Assertion: |
RSP1403
|
Description: |
|
Target: |
/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: |
|
HELP - GLOSSARY
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:
passedfailedwarningnotApplicablenotRelevantmissingInputundeterminedSee
the "reporting" item for the meaning of these results. |
Cotarget:
|
[markup:
testAssertion/cotarget ] (optional)Artifact that is related to the
target, and that needs be accessed for the testing. Identified by an
XPath expression that may refer to the related target node using the
variable '$target'. For example, the target can be a SOAP message and
the cotarget the WSDL file that describes this SOAP message.A cotarget
must have a @name attribute that identifies it. The value of this
attribute can be used as a variable (when prepending '$' to it) by
subsequently defined cotargets, prerequisite and predicate. |
Prerequisite:
|
[markup:
testAssertion/@preReq ] (optional)[markup: testAssertion/prerequisite ]
(optional)The pre-condition for evaluating this Test Assertion on this
target. If the prerequisite evaluates to "false" then the target does
not qualify for this Test Assertion (the test report is
"notRelevant")The first part (preReq attribute) is an enumeration of
Test Assertion IDs. Each one of the prerequisite TAs must either use
the same target (e.g. SOAP Envelope, or WSDL binding, etc.) as this TA,
or a target that is of a more general type than the main TA target. The
target must "pass" each one of these prerequisite TAs in order to
qualify for this TA.(e.g. the target of TA t1 can be a WSDL binding
while the target of a TA t2 prerequisite of t1, can be the entire WSDL
file).The second part ("prerequisite" element) is an XPath (boolean)
expression of the same nature as the predicate. If present, it must
evaluate to "true" for the target to qualify. If it fails, the result
for the current TA in the report will be "notRelevant". Otherwise, the
target can be further evaluated by the predicate of the main TA. The
expression may refer to the target explicitly using the variable name
"$target", or to any cotarget using its name as variable name ($[name]). |
Predicate:
|
[markup:
testAssertion/predicate] required element]A logical expression that
evaluates whether this target is fulfilling the profile requirement
addressed by this test Assertion. By default: - A result of true means
the requirement is fulfilled (reported as a "passed" in the test
report). - A result of false means the requirement is violated
(reported as a "failed" in the test report). However, in some cases and
for testability reasons, the predicate may be designed as a partial
indicator e.g. only indicates some cases of fulfillment, or some cases
of violation. As a result, when "true" indicates fulfillment it may be
that "false" is unconclusive, or conversely "false" will indicate
violation, but "true" is unconclusive. In such cases, the "Reporting"
element specifies the meaning of the predicate result w/r to the
profile requirement.The predicate expression implicitly refers to the
target (whic is its "XPath context") although it may explicitly refer
to it using the variable name "$target". It may refer to any cotarget
using its name as variable name ($[name]). |
Prescription:
|
[markup: testAssertion/prescription/@level ] (required)
Conveys the level of prescription associated with the profile requirement.
At least three values may be used:
mandatory: maps to RFC2119 keywords MUST, MUST NOT, SHALL,
SHALL NOT, REQUIRED (and sometimes MAY NOT) preferred: maps to RFC2119 keywords SHOULD, SHOULD NOT,
RECOMMENDED, NOT RECOMMENDED permitted: maps to RFC2119 keywords MAY, OPTIONAL. |
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: @true attribute: may take values among
{passed, failed, warning, undetermined} (default is 'passed') @false
attribute: may take values among {passed, failed, warning,
undetermined} (default is 'failed') The reported outcomes have the
following meaning:passed: the target passes the test and can be
considered as fulfilling the profile feature.failed: the target fails
the test and can be considered as violating (or not exhibiting) the
profile feature.warning: the test result is inconclusive. There is a
possibility of profile requirement violation, that deserved further
investigation.undetermined: the test result is inconclusive for this
predicate value.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:notRelevant: the
target failed the prerequisite condition and therefore does not qualify
for further testing (i.e. the predicate expression is NOT evaluated on
it).missingInput: a cotarget expression returned an empty node
set.notApplicable: this target was not even selected by the target
XPath expression, while being of the same general artifact type (e.g.
message type). |
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: |
RSP2030
|
General Notes: |
. |
Coverage Assessment: |
Good |
Target Type: |
ENVELOPE |
Test Target: |
For an Envelope with s:Body/MC and wsa:Action header |
Test co-Target(s): |
|
Test Prerequisite: |
|
Predicate: |
wsa:Action value is http://docs.oasis-open.org/ws-rx/wsmc/200702/MakeConnection |
Prescription: |
mandatory |
Reporting: |
(default) |
Test Control: |
|
Test Assertion: |
RSP2030
|
Description: |
|
Target: |
//wsil:messageContents/*:Envelope
[*:Body/wsmc:MakeConnection and *:Header/wsa:Action] |
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: |
|
HELP - GLOSSARY
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:
passedfailedwarningnotApplicablenotRelevantmissingInputundeterminedSee
the "reporting" item for the meaning of these results. |
Cotarget:
|
[markup:
testAssertion/cotarget ] (optional)Artifact that is related to the
target, and that needs be accessed for the testing. Identified by an
XPath expression that may refer to the related target node using the
variable '$target'. For example, the target can be a SOAP message and
the cotarget the WSDL file that describes this SOAP message.A cotarget
must have a @name attribute that identifies it. The value of this
attribute can be used as a variable (when prepending '$' to it) by
subsequently defined cotargets, prerequisite and predicate. |
Prerequisite:
|
[markup:
testAssertion/@preReq ] (optional)[markup: testAssertion/prerequisite ]
(optional)The pre-condition for evaluating this Test Assertion on this
target. If the prerequisite evaluates to "false" then the target does
not qualify for this Test Assertion (the test report is
"notRelevant")The first part (preReq attribute) is an enumeration of
Test Assertion IDs. Each one of the prerequisite TAs must either use
the same target (e.g. SOAP Envelope, or WSDL binding, etc.) as this TA,
or a target that is of a more general type than the main TA target. The
target must "pass" each one of these prerequisite TAs in order to
qualify for this TA.(e.g. the target of TA t1 can be a WSDL binding
while the target of a TA t2 prerequisite of t1, can be the entire WSDL
file).The second part ("prerequisite" element) is an XPath (boolean)
expression of the same nature as the predicate. If present, it must
evaluate to "true" for the target to qualify. If it fails, the result
for the current TA in the report will be "notRelevant". Otherwise, the
target can be further evaluated by the predicate of the main TA. The
expression may refer to the target explicitly using the variable name
"$target", or to any cotarget using its name as variable name ($[name]). |
Predicate:
|
[markup:
testAssertion/predicate] required element]A logical expression that
evaluates whether this target is fulfilling the profile requirement
addressed by this test Assertion. By default: - A result of true means
the requirement is fulfilled (reported as a "passed" in the test
report). - A result of false means the requirement is violated
(reported as a "failed" in the test report). However, in some cases and
for testability reasons, the predicate may be designed as a partial
indicator e.g. only indicates some cases of fulfillment, or some cases
of violation. As a result, when "true" indicates fulfillment it may be
that "false" is unconclusive, or conversely "false" will indicate
violation, but "true" is unconclusive. In such cases, the "Reporting"
element specifies the meaning of the predicate result w/r to the
profile requirement.The predicate expression implicitly refers to the
target (whic is its "XPath context") although it may explicitly refer
to it using the variable name "$target". It may refer to any cotarget
using its name as variable name ($[name]). |
Prescription:
|
[markup: testAssertion/prescription/@level ] (required)
Conveys the level of prescription associated with the profile requirement.
At least three values may be used:
mandatory: maps to RFC2119 keywords MUST, MUST NOT, SHALL,
SHALL NOT, REQUIRED (and sometimes MAY NOT) preferred: maps to RFC2119 keywords SHOULD, SHOULD NOT,
RECOMMENDED, NOT RECOMMENDED permitted: maps to RFC2119 keywords MAY, OPTIONAL. |
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: @true attribute: may take values among
{passed, failed, warning, undetermined} (default is 'passed') @false
attribute: may take values among {passed, failed, warning,
undetermined} (default is 'failed') The reported outcomes have the
following meaning:passed: the target passes the test and can be
considered as fulfilling the profile feature.failed: the target fails
the test and can be considered as violating (or not exhibiting) the
profile feature.warning: the test result is inconclusive. There is a
possibility of profile requirement violation, that deserved further
investigation.undetermined: the test result is inconclusive for this
predicate value.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:notRelevant: the
target failed the prerequisite condition and therefore does not qualify
for further testing (i.e. the predicate expression is NOT evaluated on
it).missingInput: a cotarget expression returned an empty node
set.notApplicable: this target was not even selected by the target
XPath expression, while being of the same general artifact type (e.g.
message type). |
R2031
If a
MESSAGE contains a SOAP 1.1 envelope with the wsmc:MakeConnection element as the child of the Body, the HTTP
SOAPAction
header, if present and not equal to the value of "" (empty string),
MUST contain the value
"http://docs.oasis-open.org/ws-rx/wsmc/200702/MakeConnection". TESTABLE
RSP2031
Test Assertion Analysis: |
RSP2031
|
General Notes: |
If
a MESSAGE contains a SOAP 1.1 envelope with the wsmc:MakeConnection
element as the child of the Body, the HTTP SOAPAction header, if
present and not equal to the value of "" (empty string), MUST contain
the value "http://docs.oasis-open.org/ws-rx/wsmc/200702/MakeConnection. |
Coverage Assessment: |
Good |
Target Type: |
MESSAGE |
Test Target: |
For a Message with sopa11:Body/MC and HTTP SOAPAction header |
Test co-Target(s): |
|
Test Prerequisite: |
|
Predicate: |
either SOAPAction value isempty string, or "http://docs.oasis-open.org/ws-rx/wsmc/200702/MakeConnection" |
Prescription: |
mandatory |
Reporting: |
(default) |
Test Control: |
|
Test Assertion: |
RSP2031
|
Description: |
|
Target: |
//wsil:message
[wsil:messageContents/soap11:Envelope/soap11:Body/wsmc:MakeConnection and
(wsil:httpHeaders/wsil:httpHeader/@key = 'SOAPAction' )] |
Predicate: |
(wsil:httpHeaders/wsil:httpHeader[@key = 'SOAPAction']/@value = 'http://docs.oasis-open.org/ws-rx/wsmc/200702/MakeConnection'
or
wsil:httpHeaders/wsil:httpHeader[@key = 'SOAPAction']/@value = '' )
and (wsil:httpHeaders/wsil:httpHeader[@key = 'SOAPAction']/@quoted = 'true' or
not (wsil:httpHeaders/wsil:httpHeader[@key = 'SOAPAction']/@quoted )) |
Reporting: |
true=passed, false=failed |
Prescription: |
mandatory |
Error Message: |
A
message containing wsmc:MakeConnection has a non-empty SOAPAction
header value different from
'http://docs.oasis-open.org/ws-rx/wsmc/200702/MakeConnection' or this
HTTP header is not quoted. |
Diagnostic Data: |
|
HELP - GLOSSARY
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:
passedfailedwarningnotApplicablenotRelevantmissingInputundeterminedSee
the "reporting" item for the meaning of these results. |
Cotarget:
|
[markup:
testAssertion/cotarget ] (optional)Artifact that is related to the
target, and that needs be accessed for the testing. Identified by an
XPath expression that may refer to the related target node using the
variable '$target'. For example, the target can be a SOAP message and
the cotarget the WSDL file that describes this SOAP message.A cotarget
must have a @name attribute that identifies it. The value of this
attribute can be used as a variable (when prepending '$' to it) by
subsequently defined cotargets, prerequisite and predicate. |
Prerequisite:
|
[markup:
testAssertion/@preReq ] (optional)[markup: testAssertion/prerequisite ]
(optional)The pre-condition for evaluating this Test Assertion on this
target. If the prerequisite evaluates to "false" then the target does
not qualify for this Test Assertion (the test report is
"notRelevant")The first part (preReq attribute) is an enumeration of
Test Assertion IDs. Each one of the prerequisite TAs must either use
the same target (e.g. SOAP Envelope, or WSDL binding, etc.) as this TA,
or a target that is of a more general type than the main TA target. The
target must "pass" each one of these prerequisite TAs in order to
qualify for this TA.(e.g. the target of TA t1 can be a WSDL binding
while the target of a TA t2 prerequisite of t1, can be the entire WSDL
file).The second part ("prerequisite" element) is an XPath (boolean)
expression of the same nature as the predicate. If present, it must
evaluate to "true" for the target to qualify. If it fails, the result
for the current TA in the report will be "notRelevant". Otherwise, the
target can be further evaluated by the predicate of the main TA. The
expression may refer to the target explicitly using the variable name
"$target", or to any cotarget using its name as variable name ($[name]). |
Predicate:
|
[markup:
testAssertion/predicate] required element]A logical expression that
evaluates whether this target is fulfilling the profile requirement
addressed by this test Assertion. By default: - A result of true means
the requirement is fulfilled (reported as a "passed" in the test
report). - A result of false means the requirement is violated
(reported as a "failed" in the test report). However, in some cases and
for testability reasons, the predicate may be designed as a partial
indicator e.g. only indicates some cases of fulfillment, or some cases
of violation. As a result, when "true" indicates fulfillment it may be
that "false" is unconclusive, or conversely "false" will indicate
violation, but "true" is unconclusive. In such cases, the "Reporting"
element specifies the meaning of the predicate result w/r to the
profile requirement.The predicate expression implicitly refers to the
target (whic is its "XPath context") although it may explicitly refer
to it using the variable name "$target". It may refer to any cotarget
using its name as variable name ($[name]). |
Prescription:
|
[markup: testAssertion/prescription/@level ] (required)
Conveys the level of prescription associated with the profile requirement.
At least three values may be used:
mandatory: maps to RFC2119 keywords MUST, MUST NOT, SHALL,
SHALL NOT, REQUIRED (and sometimes MAY NOT) preferred: maps to RFC2119 keywords SHOULD, SHOULD NOT,
RECOMMENDED, NOT RECOMMENDED permitted: maps to RFC2119 keywords MAY, OPTIONAL. |
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: @true attribute: may take values among
{passed, failed, warning, undetermined} (default is 'passed') @false
attribute: may take values among {passed, failed, warning,
undetermined} (default is 'failed') The reported outcomes have the
following meaning:passed: the target passes the test and can be
considered as fulfilling the profile feature.failed: the target fails
the test and can be considered as violating (or not exhibiting) the
profile feature.warning: the test result is inconclusive. There is a
possibility of profile requirement violation, that deserved further
investigation.undetermined: the test result is inconclusive for this
predicate value.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:notRelevant: the
target failed the prerequisite condition and therefore does not qualify
for further testing (i.e. the predicate expression is NOT evaluated on
it).missingInput: a cotarget expression returned an empty node
set.notApplicable: this target was not even selected by the target
XPath expression, while being of the same general artifact type (e.g.
message type). |
R2032
If a
MESSAGE contains a SOAP 1.2 envelope with the wsmc:MakeConnection element as the child of the Body, the
action
parameter of the HTTP
Content-Type
header, if present, MUST contain the value "http://docs.oasis-open.org/ws-rx/wsmc/200702/MakeConnection".
TESTABLE
RSP2032
Test Assertion Analysis: |
RSP2032
|
General Notes: |
If
a MESSAGE contains a SOAP 1.2 envelope with the wsmc:MakeConnection
element as the child of the Body, the action parameter of the HTTP
Content-Type header, if present, MUST contain the value
"http://docs.oasis-open.org/ws-rx/wsmc/200702/MakeConnection" |
Coverage Assessment: |
Good |
Target Type: |
MESSAGE |
Test Target: |
For an Message with sopa12:Body/MC and action parameter of the HTTP Content-Type header |
Test co-Target(s): |
|
Test Prerequisite: |
|
Predicate: |
action parameter = "http://docs.oasis-open.org/ws-rx/wsmc/200702/MakeConnection" |
Prescription: |
mandatory |
Reporting: |
(default) |
Test Control: |
|
Test Assertion: |
RSP2032
|
Description: |
|
Target: |
//wsil:message
[wsil:messageContents/soap12:Envelope/soap12:Body/wsmc:MakeConnection and
(wsil:httpHeaders/wsil:contentTypeHeader/wsil:parameter/@key = 'action' )] |
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: |
|
HELP - GLOSSARY
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:
passedfailedwarningnotApplicablenotRelevantmissingInputundeterminedSee
the "reporting" item for the meaning of these results. |
Cotarget:
|
[markup:
testAssertion/cotarget ] (optional)Artifact that is related to the
target, and that needs be accessed for the testing. Identified by an
XPath expression that may refer to the related target node using the
variable '$target'. For example, the target can be a SOAP message and
the cotarget the WSDL file that describes this SOAP message.A cotarget
must have a @name attribute that identifies it. The value of this
attribute can be used as a variable (when prepending '$' to it) by
subsequently defined cotargets, prerequisite and predicate. |
Prerequisite:
|
[markup:
testAssertion/@preReq ] (optional)[markup: testAssertion/prerequisite ]
(optional)The pre-condition for evaluating this Test Assertion on this
target. If the prerequisite evaluates to "false" then the target does
not qualify for this Test Assertion (the test report is
"notRelevant")The first part (preReq attribute) is an enumeration of
Test Assertion IDs. Each one of the prerequisite TAs must either use
the same target (e.g. SOAP Envelope, or WSDL binding, etc.) as this TA,
or a target that is of a more general type than the main TA target. The
target must "pass" each one of these prerequisite TAs in order to
qualify for this TA.(e.g. the target of TA t1 can be a WSDL binding
while the target of a TA t2 prerequisite of t1, can be the entire WSDL
file).The second part ("prerequisite" element) is an XPath (boolean)
expression of the same nature as the predicate. If present, it must
evaluate to "true" for the target to qualify. If it fails, the result
for the current TA in the report will be "notRelevant". Otherwise, the
target can be further evaluated by the predicate of the main TA. The
expression may refer to the target explicitly using the variable name
"$target", or to any cotarget using its name as variable name ($[name]). |
Predicate:
|
[markup:
testAssertion/predicate] required element]A logical expression that
evaluates whether this target is fulfilling the profile requirement
addressed by this test Assertion. By default: - A result of true means
the requirement is fulfilled (reported as a "passed" in the test
report). - A result of false means the requirement is violated
(reported as a "failed" in the test report). However, in some cases and
for testability reasons, the predicate may be designed as a partial
indicator e.g. only indicates some cases of fulfillment, or some cases
of violation. As a result, when "true" indicates fulfillment it may be
that "false" is unconclusive, or conversely "false" will indicate
violation, but "true" is unconclusive. In such cases, the "Reporting"
element specifies the meaning of the predicate result w/r to the
profile requirement.The predicate expression implicitly refers to the
target (whic is its "XPath context") although it may explicitly refer
to it using the variable name "$target". It may refer to any cotarget
using its name as variable name ($[name]). |
Prescription:
|
[markup: testAssertion/prescription/@level ] (required)
Conveys the level of prescription associated with the profile requirement.
At least three values may be used:
mandatory: maps to RFC2119 keywords MUST, MUST NOT, SHALL,
SHALL NOT, REQUIRED (and sometimes MAY NOT) preferred: maps to RFC2119 keywords SHOULD, SHOULD NOT,
RECOMMENDED, NOT RECOMMENDED permitted: maps to RFC2119 keywords MAY, OPTIONAL. |
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: @true attribute: may take values among
{passed, failed, warning, undetermined} (default is 'passed') @false
attribute: may take values among {passed, failed, warning,
undetermined} (default is 'failed') The reported outcomes have the
following meaning:passed: the target passes the test and can be
considered as fulfilling the profile feature.failed: the target fails
the test and can be considered as violating (or not exhibiting) the
profile feature.warning: the test result is inconclusive. There is a
possibility of profile requirement violation, that deserved further
investigation.undetermined: the test result is inconclusive for this
predicate value.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:notRelevant: the
target failed the prerequisite condition and therefore does not qualify
for further testing (i.e. the predicate expression is NOT evaluated on
it).missingInput: a cotarget expression returned an empty node
set.notApplicable: this target was not even selected by the target
XPath expression, while being of the same general artifact type (e.g.
message type). |
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: |
RSP2004a
|
General Notes: |
When
the wsa:ReplyTo addressing property of a request message (SOAP envelope
included in the HTTP entity body of the HTTP request) described by the
input message of a WSDL request-response operation is set to a
MakeConnection anonymous URI, the corresponding response MESSAGE (SOAP
envelope included in the HTTP entity body of the HTTP response)
described by the WSDL output message of the same WSDL request-response
operation MUST be sent as an HTTP response to either the HTTP request
that carried the WSDL input message, or to the HTTP request that
carried a wsmc:MakeConnection message with the correct MakeConnection
anonymous URI. |
Coverage Assessment: |
Good |
Target Type: |
MESSAGE |
Test Target: |
response message to a MakeConnection that has an MC anon ReplyTo |
Test co-Target(s): |
related request-response WSDL op |
Test Prerequisite: |
|
Predicate: |
response
message is sent on same HTTP connection (response), or is sent on
another HTTP response of a MakeConnection request with same MC URI in
wsmc:Address. |
Prescription: |
mandatory |
Reporting: |
true=pass, false=fail |
Test Control: |
|
Test Assertion: |
RSP2004a
|
Description: |
|
Target: |
/wsil:testLog/wsil:messageLog/wsil:message
[@type = 'response'] [ some $resp1 in . satisfies some $req1 in
./preceding::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)])] satisfies (
$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: |
|
HELP - GLOSSARY
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:
passedfailedwarningnotApplicablenotRelevantmissingInputundeterminedSee
the "reporting" item for the meaning of these results. |
Cotarget:
|
[markup:
testAssertion/cotarget ] (optional)Artifact that is related to the
target, and that needs be accessed for the testing. Identified by an
XPath expression that may refer to the related target node using the
variable '$target'. For example, the target can be a SOAP message and
the cotarget the WSDL file that describes this SOAP message.A cotarget
must have a @name attribute that identifies it. The value of this
attribute can be used as a variable (when prepending '$' to it) by
subsequently defined cotargets, prerequisite and predicate. |
Prerequisite:
|
[markup:
testAssertion/@preReq ] (optional)[markup: testAssertion/prerequisite ]
(optional)The pre-condition for evaluating this Test Assertion on this
target. If the prerequisite evaluates to "false" then the target does
not qualify for this Test Assertion (the test report is
"notRelevant")The first part (preReq attribute) is an enumeration of
Test Assertion IDs. Each one of the prerequisite TAs must either use
the same target (e.g. SOAP Envelope, or WSDL binding, etc.) as this TA,
or a target that is of a more general type than the main TA target. The
target must "pass" each one of these prerequisite TAs in order to
qualify for this TA.(e.g. the target of TA t1 can be a WSDL binding
while the target of a TA t2 prerequisite of t1, can be the entire WSDL
file).The second part ("prerequisite" element) is an XPath (boolean)
expression of the same nature as the predicate. If present, it must
evaluate to "true" for the target to qualify. If it fails, the result
for the current TA in the report will be "notRelevant". Otherwise, the
target can be further evaluated by the predicate of the main TA. The
expression may refer to the target explicitly using the variable name
"$target", or to any cotarget using its name as variable name ($[name]). |
Predicate:
|
[markup:
testAssertion/predicate] required element]A logical expression that
evaluates whether this target is fulfilling the profile requirement
addressed by this test Assertion. By default: - A result of true means
the requirement is fulfilled (reported as a "passed" in the test
report). - A result of false means the requirement is violated
(reported as a "failed" in the test report). However, in some cases and
for testability reasons, the predicate may be designed as a partial
indicator e.g. only indicates some cases of fulfillment, or some cases
of violation. As a result, when "true" indicates fulfillment it may be
that "false" is unconclusive, or conversely "false" will indicate
violation, but "true" is unconclusive. In such cases, the "Reporting"
element specifies the meaning of the predicate result w/r to the
profile requirement.The predicate expression implicitly refers to the
target (whic is its "XPath context") although it may explicitly refer
to it using the variable name "$target". It may refer to any cotarget
using its name as variable name ($[name]). |
Prescription:
|
[markup: testAssertion/prescription/@level ] (required)
Conveys the level of prescription associated with the profile requirement.
At least three values may be used:
mandatory: maps to RFC2119 keywords MUST, MUST NOT, SHALL,
SHALL NOT, REQUIRED (and sometimes MAY NOT) preferred: maps to RFC2119 keywords SHOULD, SHOULD NOT,
RECOMMENDED, NOT RECOMMENDED permitted: maps to RFC2119 keywords MAY, OPTIONAL. |
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: @true attribute: may take values among
{passed, failed, warning, undetermined} (default is 'passed') @false
attribute: may take values among {passed, failed, warning,
undetermined} (default is 'failed') The reported outcomes have the
following meaning:passed: the target passes the test and can be
considered as fulfilling the profile feature.failed: the target fails
the test and can be considered as violating (or not exhibiting) the
profile feature.warning: the test result is inconclusive. There is a
possibility of profile requirement violation, that deserved further
investigation.undetermined: the test result is inconclusive for this
predicate value.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:notRelevant: the
target failed the prerequisite condition and therefore does not qualify
for further testing (i.e. the predicate expression is NOT evaluated on
it).missingInput: a cotarget expression returned an empty node
set.notApplicable: this target was not even selected by the target
XPath expression, while being of the same general artifact type (e.g.
message type). |
Test Assertion Analysis: |
RSP2004b
|
General Notes: |
When
the wsa:ReplyTo addressing property of a request message (SOAP envelope
included in the HTTP entity body of the HTTP request) described by the
input message of a WSDL request-response operation is set to a
MakeConnection anonymous URI, the corresponding response MESSAGE (SOAP
envelope included in the HTTP entity body of the HTTP response)
described by the WSDL output message of the same WSDL request-response
operation MUST be sent as an HTTP response to either the HTTP request
that carried the WSDL input message, or to the HTTP request that
carried a wsmc:MakeConnection message with the correct MakeConnection
anonymous URI. |
Coverage Assessment: |
Good |
Target Type: |
MESSAGE |
Test Target: |
response message to a MakeConnection that has an MC anon ReplyTo |
Test co-Target(s): |
related request-response WSDL op |
Test Prerequisite: |
|
Predicate: |
response
message is sent on same HTTP connection (response), or is sent on
another HTTP response of a MakeConnection request with same MC URI in
wsmc:Address. |
Prescription: |
mandatory |
Reporting: |
true=pass, false=fail |
Test Control: |
|
Test Assertion: |
RSP2004b
|
Description: |
|
Target: |
/wsil:testLog/wsil:messageLog/wsil:message
[@type = 'response'] [ some $resp1 in . satisfies some $req1 in
./preceding::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)])] satisfies (
$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:testLog/wsil:descriptionFiles/wsil:descriptionFile/wsdl:definitions/wsdl:message[fn:resolve-QName(xsd:string(wsdl:part[1]/@element),
. ) = fn:node-name($req1//*:Envelope/*:Body/*[1])] ) ] |
co-Target:
myRequestMsg |
$target/preceding::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:testLog/wsil:descriptionFiles/wsil:descriptionFile/wsdl:definitions/wsdl:binding
[not(.//*[@style = 'rpc'])]/wsdl:operation [wsdl:input and wsdl:output]
[ some $opBinding in . satisfies some $dmesg in
/wsil:testLog/wsil:descriptionFiles/wsil:descriptionFile/wsdl:definitions/wsdl:message[wsdl:part[fn:resolve-QName(xsd:string(@element),
. ) = fn:node-name($myRequestMsg//*:Envelope/*:Body/*[1])] ] satisfies
some $dopmsg in
/wsil:testLog/wsil:descriptionFiles/wsil:descriptionFile/wsdl:definitions/wsdl:portType/wsdl:operation/wsdl:input
[fn:local-name-from-QName(fn:resolve-QName(xsd:string(@message), . )) =
$dmesg/@name] satisfies $opBinding/@name = $dopmsg/../@name ] |
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 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: |
|
HELP - GLOSSARY
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:
passedfailedwarningnotApplicablenotRelevantmissingInputundeterminedSee
the "reporting" item for the meaning of these results. |
Cotarget:
|
[markup:
testAssertion/cotarget ] (optional)Artifact that is related to the
target, and that needs be accessed for the testing. Identified by an
XPath expression that may refer to the related target node using the
variable '$target'. For example, the target can be a SOAP message and
the cotarget the WSDL file that describes this SOAP message.A cotarget
must have a @name attribute that identifies it. The value of this
attribute can be used as a variable (when prepending '$' to it) by
subsequently defined cotargets, prerequisite and predicate. |
Prerequisite:
|
[markup:
testAssertion/@preReq ] (optional)[markup: testAssertion/prerequisite ]
(optional)The pre-condition for evaluating this Test Assertion on this
target. If the prerequisite evaluates to "false" then the target does
not qualify for this Test Assertion (the test report is
"notRelevant")The first part (preReq attribute) is an enumeration of
Test Assertion IDs. Each one of the prerequisite TAs must either use
the same target (e.g. SOAP Envelope, or WSDL binding, etc.) as this TA,
or a target that is of a more general type than the main TA target. The
target must "pass" each one of these prerequisite TAs in order to
qualify for this TA.(e.g. the target of TA t1 can be a WSDL binding
while the target of a TA t2 prerequisite of t1, can be the entire WSDL
file).The second part ("prerequisite" element) is an XPath (boolean)
expression of the same nature as the predicate. If present, it must
evaluate to "true" for the target to qualify. If it fails, the result
for the current TA in the report will be "notRelevant". Otherwise, the
target can be further evaluated by the predicate of the main TA. The
expression may refer to the target explicitly using the variable name
"$target", or to any cotarget using its name as variable name ($[name]). |
Predicate:
|
[markup:
testAssertion/predicate] required element]A logical expression that
evaluates whether this target is fulfilling the profile requirement
addressed by this test Assertion. By default: - A result of true means
the requirement is fulfilled (reported as a "passed" in the test
report). - A result of false means the requirement is violated
(reported as a "failed" in the test report). However, in some cases and
for testability reasons, the predicate may be designed as a partial
indicator e.g. only indicates some cases of fulfillment, or some cases
of violation. As a result, when "true" indicates fulfillment it may be
that "false" is unconclusive, or conversely "false" will indicate
violation, but "true" is unconclusive. In such cases, the "Reporting"
element specifies the meaning of the predicate result w/r to the
profile requirement.The predicate expression implicitly refers to the
target (whic is its "XPath context") although it may explicitly refer
to it using the variable name "$target". It may refer to any cotarget
using its name as variable name ($[name]). |
Prescription:
|
[markup: testAssertion/prescription/@level ] (required)
Conveys the level of prescription associated with the profile requirement.
At least three values may be used:
mandatory: maps to RFC2119 keywords MUST, MUST NOT, SHALL,
SHALL NOT, REQUIRED (and sometimes MAY NOT) preferred: maps to RFC2119 keywords SHOULD, SHOULD NOT,
RECOMMENDED, NOT RECOMMENDED permitted: maps to RFC2119 keywords MAY, OPTIONAL. |
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: @true attribute: may take values among
{passed, failed, warning, undetermined} (default is 'passed') @false
attribute: may take values among {passed, failed, warning,
undetermined} (default is 'failed') The reported outcomes have the
following meaning:passed: the target passes the test and can be
considered as fulfilling the profile feature.failed: the target fails
the test and can be considered as violating (or not exhibiting) the
profile feature.warning: the test result is inconclusive. There is a
possibility of profile requirement violation, that deserved further
investigation.undetermined: the test result is inconclusive for this
predicate value.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:notRelevant: the
target failed the prerequisite condition and therefore does not qualify
for further testing (i.e. the predicate expression is NOT evaluated on
it).missingInput: a cotarget expression returned an empty node
set.notApplicable: this target was not even selected by the target
XPath expression, while being of the same general artifact type (e.g.
message type). |
R2005
Any
MESSAGE
resulting from the processing of a SOAP envelope included in the HTTP
entity body of the HTTP response, if transmitted, MUST be sent via a
new HTTP request. TESTABLE
RSP2005
Test Assertion Analysis: |
RSP2005
|
General Notes: |
|
Coverage Assessment: |
good |
Target Type: |
ENVELOPE |
Test Target: |
for a soap:Envelope sent as a response (wsa:RelatesTo)
to another Envelope sent over an HTTP response |
Test co-Target(s): |
|
Test Prerequisite: |
|
Predicate: |
The target Envelope is sent over an HTTP Request |
Prescription: |
mandatory |
Reporting: |
true=passed, false=failed |
Test Control: |
|
Test Assertion: |
RSP2005
|
Description: |
|
Target: |
/wsil:testLog/wsil:messageLog/wsil:message/wsil:messageContents/*:Envelope[
*:Header/wsa:RelatesTo[@RelationshipType = 'http://www.w3.org/2005/08/addressing/reply' or not (@RelationshipType)]
] |
co-Target:
initmsg |
$target/preceding::*:Envelope [
(*:Header/wsa:MessageID = $target/*:Header/wsa:RelatesTo[@RelationshipType = 'http://www.w3.org/2005/08/addressing/reply']
or
(not(*:Header/wsa:RelatesTo/@RelationshipType) and *:Header/wsa:MessageID = $target/*:Header/wsa:RelatesTo ) )
and
../../@type = 'response' ]
|
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: |
|
HELP - GLOSSARY
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:
passedfailedwarningnotApplicablenotRelevantmissingInputundeterminedSee
the "reporting" item for the meaning of these results. |
Cotarget:
|
[markup:
testAssertion/cotarget ] (optional)Artifact that is related to the
target, and that needs be accessed for the testing. Identified by an
XPath expression that may refer to the related target node using the
variable '$target'. For example, the target can be a SOAP message and
the cotarget the WSDL file that describes this SOAP message.A cotarget
must have a @name attribute that identifies it. The value of this
attribute can be used as a variable (when prepending '$' to it) by
subsequently defined cotargets, prerequisite and predicate. |
Prerequisite:
|
[markup:
testAssertion/@preReq ] (optional)[markup: testAssertion/prerequisite ]
(optional)The pre-condition for evaluating this Test Assertion on this
target. If the prerequisite evaluates to "false" then the target does
not qualify for this Test Assertion (the test report is
"notRelevant")The first part (preReq attribute) is an enumeration of
Test Assertion IDs. Each one of the prerequisite TAs must either use
the same target (e.g. SOAP Envelope, or WSDL binding, etc.) as this TA,
or a target that is of a more general type than the main TA target. The
target must "pass" each one of these prerequisite TAs in order to
qualify for this TA.(e.g. the target of TA t1 can be a WSDL binding
while the target of a TA t2 prerequisite of t1, can be the entire WSDL
file).The second part ("prerequisite" element) is an XPath (boolean)
expression of the same nature as the predicate. If present, it must
evaluate to "true" for the target to qualify. If it fails, the result
for the current TA in the report will be "notRelevant". Otherwise, the
target can be further evaluated by the predicate of the main TA. The
expression may refer to the target explicitly using the variable name
"$target", or to any cotarget using its name as variable name ($[name]). |
Predicate:
|
[markup:
testAssertion/predicate] required element]A logical expression that
evaluates whether this target is fulfilling the profile requirement
addressed by this test Assertion. By default: - A result of true means
the requirement is fulfilled (reported as a "passed" in the test
report). - A result of false means the requirement is violated
(reported as a "failed" in the test report). However, in some cases and
for testability reasons, the predicate may be designed as a partial
indicator e.g. only indicates some cases of fulfillment, or some cases
of violation. As a result, when "true" indicates fulfillment it may be
that "false" is unconclusive, or conversely "false" will indicate
violation, but "true" is unconclusive. In such cases, the "Reporting"
element specifies the meaning of the predicate result w/r to the
profile requirement.The predicate expression implicitly refers to the
target (whic is its "XPath context") although it may explicitly refer
to it using the variable name "$target". It may refer to any cotarget
using its name as variable name ($[name]). |
Prescription:
|
[markup: testAssertion/prescription/@level ] (required)
Conveys the level of prescription associated with the profile requirement.
At least three values may be used:
mandatory: maps to RFC2119 keywords MUST, MUST NOT, SHALL,
SHALL NOT, REQUIRED (and sometimes MAY NOT) preferred: maps to RFC2119 keywords SHOULD, SHOULD NOT,
RECOMMENDED, NOT RECOMMENDED permitted: maps to RFC2119 keywords MAY, OPTIONAL. |
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: @true attribute: may take values among
{passed, failed, warning, undetermined} (default is 'passed') @false
attribute: may take values among {passed, failed, warning,
undetermined} (default is 'failed') The reported outcomes have the
following meaning:passed: the target passes the test and can be
considered as fulfilling the profile feature.failed: the target fails
the test and can be considered as violating (or not exhibiting) the
profile feature.warning: the test result is inconclusive. There is a
possibility of profile requirement violation, that deserved further
investigation.undetermined: the test result is inconclusive for this
predicate value.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:notRelevant: the
target failed the prerequisite condition and therefore does not qualify
for further testing (i.e. the predicate expression is NOT evaluated on
it).missingInput: a cotarget expression returned an empty node
set.notApplicable: this target was not even selected by the target
XPath expression, while being of the same general artifact type (e.g.
message type). |
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: |
RSP2100
|
General Notes: |
There's
an option in the MC spec that allows for the retrieval of messages
based on things other than the target URI – however, RSP limits this
by requiring that a search MUST, at least, be based on the target URI
(ie. the wsa:To URI). |
Coverage Assessment: |
Good |
Target Type: |
ENVELOPE |
Test Target: |
For an Envelope with s:Body/MC |
Test co-Target(s): |
|
Test Prerequisite: |
|
Predicate: |
there exists MC/wsmc:Address child element |
Prescription: |
mandatory |
Reporting: |
(default) |
Test Control: |
provide
context and cause MC sending such as do a req/resp and the response is
lost. Flag=much more difficult study required to force use of MC. Run
some request/response tests and set the wsa:ReplyTo of the request
messages (from a non-addressable endpoint) to an instance of the MC
Anonymous URI Template |
Test Assertion: |
RSP2100
|
Description: |
|
Target: |
//wsil:messageContents/*:Envelope[*:Body/wsmc:MakeConnection] |
Predicate: |
*:Body/wsmc:MakeConnection/wsmc:Address |
Reporting: |
true=passed, false=failed |
Prescription: |
mandatory |
Error Message: |
|
Diagnostic Data: |
|
HELP - GLOSSARY
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:
passedfailedwarningnotApplicablenotRelevantmissingInputundeterminedSee
the "reporting" item for the meaning of these results. |
Cotarget:
|
[markup:
testAssertion/cotarget ] (optional)Artifact that is related to the
target, and that needs be accessed for the testing. Identified by an
XPath expression that may refer to the related target node using the
variable '$target'. For example, the target can be a SOAP message and
the cotarget the WSDL file that describes this SOAP message.A cotarget
must have a @name attribute that identifies it. The value of this
attribute can be used as a variable (when prepending '$' to it) by
subsequently defined cotargets, prerequisite and predicate. |
Prerequisite:
|
[markup:
testAssertion/@preReq ] (optional)[markup: testAssertion/prerequisite ]
(optional)The pre-condition for evaluating this Test Assertion on this
target. If the prerequisite evaluates to "false" then the target does
not qualify for this Test Assertion (the test report is
"notRelevant")The first part (preReq attribute) is an enumeration of
Test Assertion IDs. Each one of the prerequisite TAs must either use
the same target (e.g. SOAP Envelope, or WSDL binding, etc.) as this TA,
or a target that is of a more general type than the main TA target. The
target must "pass" each one of these prerequisite TAs in order to
qualify for this TA.(e.g. the target of TA t1 can be a WSDL binding
while the target of a TA t2 prerequisite of t1, can be the entire WSDL
file).The second part ("prerequisite" element) is an XPath (boolean)
expression of the same nature as the predicate. If present, it must
evaluate to "true" for the target to qualify. If it fails, the result
for the current TA in the report will be "notRelevant". Otherwise, the
target can be further evaluated by the predicate of the main TA. The
expression may refer to the target explicitly using the variable name
"$target", or to any cotarget using its name as variable name ($[name]). |
Predicate:
|
[markup:
testAssertion/predicate] required element]A logical expression that
evaluates whether this target is fulfilling the profile requirement
addressed by this test Assertion. By default: - A result of true means
the requirement is fulfilled (reported as a "passed" in the test
report). - A result of false means the requirement is violated
(reported as a "failed" in the test report). However, in some cases and
for testability reasons, the predicate may be designed as a partial
indicator e.g. only indicates some cases of fulfillment, or some cases
of violation. As a result, when "true" indicates fulfillment it may be
that "false" is unconclusive, or conversely "false" will indicate
violation, but "true" is unconclusive. In such cases, the "Reporting"
element specifies the meaning of the predicate result w/r to the
profile requirement.The predicate expression implicitly refers to the
target (whic is its "XPath context") although it may explicitly refer
to it using the variable name "$target". It may refer to any cotarget
using its name as variable name ($[name]). |
Prescription:
|
[markup: testAssertion/prescription/@level ] (required)
Conveys the level of prescription associated with the profile requirement.
At least three values may be used:
mandatory: maps to RFC2119 keywords MUST, MUST NOT, SHALL,
SHALL NOT, REQUIRED (and sometimes MAY NOT) preferred: maps to RFC2119 keywords SHOULD, SHOULD NOT,
RECOMMENDED, NOT RECOMMENDED permitted: maps to RFC2119 keywords MAY, OPTIONAL. |
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: @true attribute: may take values among
{passed, failed, warning, undetermined} (default is 'passed') @false
attribute: may take values among {passed, failed, warning,
undetermined} (default is 'failed') The reported outcomes have the
following meaning:passed: the target passes the test and can be
considered as fulfilling the profile feature.failed: the target fails
the test and can be considered as violating (or not exhibiting) the
profile feature.warning: the test result is inconclusive. There is a
possibility of profile requirement violation, that deserved further
investigation.undetermined: the test result is inconclusive for this
predicate value.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:notRelevant: the
target failed the prerequisite condition and therefore does not qualify
for further testing (i.e. the predicate expression is NOT evaluated on
it).missingInput: a cotarget expression returned an empty node
set.notApplicable: this target was not even selected by the target
XPath expression, while being of the same general artifact type (e.g.
message type). |
R2101
If an
ENVELOPE
contains a wsmc:MakeConnection element as a child of the SOAP Body, the
wsmc:MakeConnection element MUST NOT contain a wsrm:Identifier child
element. TESTABLE
RSP2101
Test Assertion Analysis: |
RSP2101
|
General Notes: |
|
Coverage Assessment: |
Good |
Target Type: |
ENVELOPE |
Test Target: |
For an Envelope with s:Body/MC |
Test co-Target(s): |
|
Test Prerequisite: |
|
Predicate: |
there is no MC/wsrm:Identifier |
Prescription: |
mandatory |
Reporting: |
(default) |
Test Control: |
provide
context and cause MC sending such as do a req/resp and the response is
lost. Flag=much more difficult study required to force use of MC. Run
some request/response tests and set the wsa:ReplyTo of the request
messages (from a non-addressable endpoint) to an instance of the MC
Anonymous URI Template |
Test Assertion: |
RSP2101
|
Description: |
|
Target: |
//wsil:messageContents/*:Envelope[*:Body/wsmc:MakeConnection] |
Predicate: |
not (*:Body/wsmc:MakeConnection/wsrm:Identifier) |
Reporting: |
true=passed, false=failed |
Prescription: |
mandatory |
Error Message: |
|
Diagnostic Data: |
|
HELP - GLOSSARY
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:
passedfailedwarningnotApplicablenotRelevantmissingInputundeterminedSee
the "reporting" item for the meaning of these results. |
Cotarget:
|
[markup:
testAssertion/cotarget ] (optional)Artifact that is related to the
target, and that needs be accessed for the testing. Identified by an
XPath expression that may refer to the related target node using the
variable '$target'. For example, the target can be a SOAP message and
the cotarget the WSDL file that describes this SOAP message.A cotarget
must have a @name attribute that identifies it. The value of this
attribute can be used as a variable (when prepending '$' to it) by
subsequently defined cotargets, prerequisite and predicate. |
Prerequisite:
|
[markup:
testAssertion/@preReq ] (optional)[markup: testAssertion/prerequisite ]
(optional)The pre-condition for evaluating this Test Assertion on this
target. If the prerequisite evaluates to "false" then the target does
not qualify for this Test Assertion (the test report is
"notRelevant")The first part (preReq attribute) is an enumeration of
Test Assertion IDs. Each one of the prerequisite TAs must either use
the same target (e.g. SOAP Envelope, or WSDL binding, etc.) as this TA,
or a target that is of a more general type than the main TA target. The
target must "pass" each one of these prerequisite TAs in order to
qualify for this TA.(e.g. the target of TA t1 can be a WSDL binding
while the target of a TA t2 prerequisite of t1, can be the entire WSDL
file).The second part ("prerequisite" element) is an XPath (boolean)
expression of the same nature as the predicate. If present, it must
evaluate to "true" for the target to qualify. If it fails, the result
for the current TA in the report will be "notRelevant". Otherwise, the
target can be further evaluated by the predicate of the main TA. The
expression may refer to the target explicitly using the variable name
"$target", or to any cotarget using its name as variable name ($[name]). |
Predicate:
|
[markup:
testAssertion/predicate] required element]A logical expression that
evaluates whether this target is fulfilling the profile requirement
addressed by this test Assertion. By default: - A result of true means
the requirement is fulfilled (reported as a "passed" in the test
report). - A result of false means the requirement is violated
(reported as a "failed" in the test report). However, in some cases and
for testability reasons, the predicate may be designed as a partial
indicator e.g. only indicates some cases of fulfillment, or some cases
of violation. As a result, when "true" indicates fulfillment it may be
that "false" is unconclusive, or conversely "false" will indicate
violation, but "true" is unconclusive. In such cases, the "Reporting"
element specifies the meaning of the predicate result w/r to the
profile requirement.The predicate expression implicitly refers to the
target (whic is its "XPath context") although it may explicitly refer
to it using the variable name "$target". It may refer to any cotarget
using its name as variable name ($[name]). |
Prescription:
|
[markup: testAssertion/prescription/@level ] (required)
Conveys the level of prescription associated with the profile requirement.
At least three values may be used:
mandatory: maps to RFC2119 keywords MUST, MUST NOT, SHALL,
SHALL NOT, REQUIRED (and sometimes MAY NOT) preferred: maps to RFC2119 keywords SHOULD, SHOULD NOT,
RECOMMENDED, NOT RECOMMENDED permitted: maps to RFC2119 keywords MAY, OPTIONAL. |
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: @true attribute: may take values among
{passed, failed, warning, undetermined} (default is 'passed') @false
attribute: may take values among {passed, failed, warning,
undetermined} (default is 'failed') The reported outcomes have the
following meaning:passed: the target passes the test and can be
considered as fulfilling the profile feature.failed: the target fails
the test and can be considered as violating (or not exhibiting) the
profile feature.warning: the test result is inconclusive. There is a
possibility of profile requirement violation, that deserved further
investigation.undetermined: the test result is inconclusive for this
predicate value.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:notRelevant: the
target failed the prerequisite condition and therefore does not qualify
for further testing (i.e. the predicate expression is NOT evaluated on
it).missingInput: a cotarget expression returned an empty node
set.notApplicable: this target was not even selected by the target
XPath expression, while being of the same general artifact type (e.g.
message type). |
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: |
RSP2110
|
General Notes: |
While
the MakeConnection specification allows for any URI to be used in the
mc:Address element, for the purposes of increasing interoperability the
RSP narrows its usage down to just the cases of the MCAnonymous URI |
Coverage Assessment: |
Good (should be able to cover all cases) |
Target Type: |
ENVELOPE |
Test Target: |
Any message that contains a MakeConnection element in the Body |
Test co-Target(s): |
|
Test Prerequisite: |
|
Predicate: |
The
[target] contains an mc:MakeConnection/mc:Address child element whose
value is an instance of the MC Anonymous URI template (ie. starts with
'http://docs.oasis-open.org/ws-rx/wsmc/200702/anonymous?id=' ). |
Prescription: |
mandatory |
Reporting: |
true=passed, false=failed |
Test Control: |
Run
some request/response tests and set the wsa:ReplyTo of the request
messages (from a non-addressable endpoint) to an instance of the MC
Anonymous URI Template. |
Test Assertion: |
RSP2110
|
Description: |
|
Target: |
//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: |
|
HELP - GLOSSARY
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:
passedfailedwarningnotApplicablenotRelevantmissingInputundeterminedSee
the "reporting" item for the meaning of these results. |
Cotarget:
|
[markup:
testAssertion/cotarget ] (optional)Artifact that is related to the
target, and that needs be accessed for the testing. Identified by an
XPath expression that may refer to the related target node using the
variable '$target'. For example, the target can be a SOAP message and
the cotarget the WSDL file that describes this SOAP message.A cotarget
must have a @name attribute that identifies it. The value of this
attribute can be used as a variable (when prepending '$' to it) by
subsequently defined cotargets, prerequisite and predicate. |
Prerequisite:
|
[markup:
testAssertion/@preReq ] (optional)[markup: testAssertion/prerequisite ]
(optional)The pre-condition for evaluating this Test Assertion on this
target. If the prerequisite evaluates to "false" then the target does
not qualify for this Test Assertion (the test report is
"notRelevant")The first part (preReq attribute) is an enumeration of
Test Assertion IDs. Each one of the prerequisite TAs must either use
the same target (e.g. SOAP Envelope, or WSDL binding, etc.) as this TA,
or a target that is of a more general type than the main TA target. The
target must "pass" each one of these prerequisite TAs in order to
qualify for this TA.(e.g. the target of TA t1 can be a WSDL binding
while the target of a TA t2 prerequisite of t1, can be the entire WSDL
file).The second part ("prerequisite" element) is an XPath (boolean)
expression of the same nature as the predicate. If present, it must
evaluate to "true" for the target to qualify. If it fails, the result
for the current TA in the report will be "notRelevant". Otherwise, the
target can be further evaluated by the predicate of the main TA. The
expression may refer to the target explicitly using the variable name
"$target", or to any cotarget using its name as variable name ($[name]). |
Predicate:
|
[markup:
testAssertion/predicate] required element]A logical expression that
evaluates whether this target is fulfilling the profile requirement
addressed by this test Assertion. By default: - A result of true means
the requirement is fulfilled (reported as a "passed" in the test
report). - A result of false means the requirement is violated
(reported as a "failed" in the test report). However, in some cases and
for testability reasons, the predicate may be designed as a partial
indicator e.g. only indicates some cases of fulfillment, or some cases
of violation. As a result, when "true" indicates fulfillment it may be
that "false" is unconclusive, or conversely "false" will indicate
violation, but "true" is unconclusive. In such cases, the "Reporting"
element specifies the meaning of the predicate result w/r to the
profile requirement.The predicate expression implicitly refers to the
target (whic is its "XPath context") although it may explicitly refer
to it using the variable name "$target". It may refer to any cotarget
using its name as variable name ($[name]). |
Prescription:
|
[markup: testAssertion/prescription/@level ] (required)
Conveys the level of prescription associated with the profile requirement.
At least three values may be used:
mandatory: maps to RFC2119 keywords MUST, MUST NOT, SHALL,
SHALL NOT, REQUIRED (and sometimes MAY NOT) preferred: maps to RFC2119 keywords SHOULD, SHOULD NOT,
RECOMMENDED, NOT RECOMMENDED permitted: maps to RFC2119 keywords MAY, OPTIONAL. |
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: @true attribute: may take values among
{passed, failed, warning, undetermined} (default is 'passed') @false
attribute: may take values among {passed, failed, warning,
undetermined} (default is 'failed') The reported outcomes have the
following meaning:passed: the target passes the test and can be
considered as fulfilling the profile feature.failed: the target fails
the test and can be considered as violating (or not exhibiting) the
profile feature.warning: the test result is inconclusive. There is a
possibility of profile requirement violation, that deserved further
investigation.undetermined: the test result is inconclusive for this
predicate value.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:notRelevant: the
target failed the prerequisite condition and therefore does not qualify
for further testing (i.e. the predicate expression is NOT evaluated on
it).missingInput: a cotarget expression returned an empty node
set.notApplicable: this target was not even selected by the target
XPath expression, while being of the same general artifact type (e.g.
message type). |
R2111
Once the MakeConnection protocol is established through the exchange of
an EPR that contains the wsmc:MakeConnection Anonymous URI as its
[address] property, the MC-RECEIVER MUST make use of the MakeConnection response channel to transfer messages targeted to that EPR.
TESTABLE
RSP2111
Test Assertion Analysis: |
RSP2111
|
General Notes: |
This
is a test to make sure that messages targeted to the MakeConnection
Anonymous URI flow over an HTTP response flow (as opposed to an HTTP
request flow). |
Coverage Assessment: |
Good (should be able to cover all cases) |
Target Type: |
ENVELOPE |
Test Target: |
A
message with a wsa:To value set to an instance of the MC Anonymous URI
template (ie. starts with
"http://docs.oasis-open.org/ws-rx/wsmc/200702/anonymous?id=" ). |
Test co-Target(s): |
|
Test Prerequisite: |
|
Predicate: |
The [target] is an HTTP response message. |
Prescription: |
mandatory |
Reporting: |
true=passed, false=failed |
Test Control: |
Run
some request/response tests and set the wsa:ReplyTo of the request
messages (from a non-addressable endpoint) to an instance of the MC
Anonymous URI Template. |
Test Assertion: |
RSP2111
|
Description: |
|
Target: |
/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: |
|
HELP - GLOSSARY
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:
passedfailedwarningnotApplicablenotRelevantmissingInputundeterminedSee
the "reporting" item for the meaning of these results. |
Cotarget:
|
[markup:
testAssertion/cotarget ] (optional)Artifact that is related to the
target, and that needs be accessed for the testing. Identified by an
XPath expression that may refer to the related target node using the
variable '$target'. For example, the target can be a SOAP message and
the cotarget the WSDL file that describes this SOAP message.A cotarget
must have a @name attribute that identifies it. The value of this
attribute can be used as a variable (when prepending '$' to it) by
subsequently defined cotargets, prerequisite and predicate. |
Prerequisite:
|
[markup:
testAssertion/@preReq ] (optional)[markup: testAssertion/prerequisite ]
(optional)The pre-condition for evaluating this Test Assertion on this
target. If the prerequisite evaluates to "false" then the target does
not qualify for this Test Assertion (the test report is
"notRelevant")The first part (preReq attribute) is an enumeration of
Test Assertion IDs. Each one of the prerequisite TAs must either use
the same target (e.g. SOAP Envelope, or WSDL binding, etc.) as this TA,
or a target that is of a more general type than the main TA target. The
target must "pass" each one of these prerequisite TAs in order to
qualify for this TA.(e.g. the target of TA t1 can be a WSDL binding
while the target of a TA t2 prerequisite of t1, can be the entire WSDL
file).The second part ("prerequisite" element) is an XPath (boolean)
expression of the same nature as the predicate. If present, it must
evaluate to "true" for the target to qualify. If it fails, the result
for the current TA in the report will be "notRelevant". Otherwise, the
target can be further evaluated by the predicate of the main TA. The
expression may refer to the target explicitly using the variable name
"$target", or to any cotarget using its name as variable name ($[name]). |
Predicate:
|
[markup:
testAssertion/predicate] required element]A logical expression that
evaluates whether this target is fulfilling the profile requirement
addressed by this test Assertion. By default: - A result of true means
the requirement is fulfilled (reported as a "passed" in the test
report). - A result of false means the requirement is violated
(reported as a "failed" in the test report). However, in some cases and
for testability reasons, the predicate may be designed as a partial
indicator e.g. only indicates some cases of fulfillment, or some cases
of violation. As a result, when "true" indicates fulfillment it may be
that "false" is unconclusive, or conversely "false" will indicate
violation, but "true" is unconclusive. In such cases, the "Reporting"
element specifies the meaning of the predicate result w/r to the
profile requirement.The predicate expression implicitly refers to the
target (whic is its "XPath context") although it may explicitly refer
to it using the variable name "$target". It may refer to any cotarget
using its name as variable name ($[name]). |
Prescription:
|
[markup: testAssertion/prescription/@level ] (required)
Conveys the level of prescription associated with the profile requirement.
At least three values may be used:
mandatory: maps to RFC2119 keywords MUST, MUST NOT, SHALL,
SHALL NOT, REQUIRED (and sometimes MAY NOT) preferred: maps to RFC2119 keywords SHOULD, SHOULD NOT,
RECOMMENDED, NOT RECOMMENDED permitted: maps to RFC2119 keywords MAY, OPTIONAL. |
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: @true attribute: may take values among
{passed, failed, warning, undetermined} (default is 'passed') @false
attribute: may take values among {passed, failed, warning,
undetermined} (default is 'failed') The reported outcomes have the
following meaning:passed: the target passes the test and can be
considered as fulfilling the profile feature.failed: the target fails
the test and can be considered as violating (or not exhibiting) the
profile feature.warning: the test result is inconclusive. There is a
possibility of profile requirement violation, that deserved further
investigation.undetermined: the test result is inconclusive for this
predicate value.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:notRelevant: the
target failed the prerequisite condition and therefore does not qualify
for further testing (i.e. the predicate expression is NOT evaluated on
it).missingInput: a cotarget expression returned an empty node
set.notApplicable: this target was not even selected by the target
XPath expression, while being of the same general artifact type (e.g.
message type). |
R2112
A
MESSAGE
sent to a non-addressable endpoint MUST have the wsa:To addressing
property set to an instance of the MakeConnection anonymous URI that
identifies that endpoint, except in the following situation where this
is [permitted but] not required (a) the message (that is not a WS-RM
lifecycle message) is sent non-reliably over the back-channel of an
underlying protocol connection initiated by the non-addressable
endpoint. TESTABLE
RSP2112
Test Assertion Analysis: |
RSP2112
|
General Notes: |
This
requirement focuses on ensuring that when RM is being used by an
anonymous endpoint, that the MC Anonymous URI is used so that the full
features of RM can still continue to be used. So: IF MC anon used in
request, and same used i response/wsa:To then OK else Fail. IF MC anon
not used in request, but regular anon, THEN fail. |
Coverage Assessment: |
Good (should be able to cover all cases) |
Target Type: |
ENVELOPE |
Test Target: |
Any Message sent on an HTTP response flow that contains a wsrm:Sequence Header. |
Test co-Target(s): |
|
Test Prerequisite: |
|
Predicate: |
The
[target] has a wsa:To Header whose value is an instance of the MC
Anonymous URI (ie. starts with
"http://docs.oasis-open.org/ws-rx/wsmc/200702/anonymous?id="). |
Prescription: |
mandatory |
Reporting: |
true=passed, false=failed |
Test Control: |
Run
some request/response tests and set the wsa:ReplyTo of the request
messages (from a non-addressable endpoint) to an instance of the MC
Anonymous URI Template. |
Test Assertion: |
RSP2112
|
Description: |
|
Target: |
/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: |
|
HELP - GLOSSARY
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:
passedfailedwarningnotApplicablenotRelevantmissingInputundeterminedSee
the "reporting" item for the meaning of these results. |
Cotarget:
|
[markup:
testAssertion/cotarget ] (optional)Artifact that is related to the
target, and that needs be accessed for the testing. Identified by an
XPath expression that may refer to the related target node using the
variable '$target'. For example, the target can be a SOAP message and
the cotarget the WSDL file that describes this SOAP message.A cotarget
must have a @name attribute that identifies it. The value of this
attribute can be used as a variable (when prepending '$' to it) by
subsequently defined cotargets, prerequisite and predicate. |
Prerequisite:
|
[markup:
testAssertion/@preReq ] (optional)[markup: testAssertion/prerequisite ]
(optional)The pre-condition for evaluating this Test Assertion on this
target. If the prerequisite evaluates to "false" then the target does
not qualify for this Test Assertion (the test report is
"notRelevant")The first part (preReq attribute) is an enumeration of
Test Assertion IDs. Each one of the prerequisite TAs must either use
the same target (e.g. SOAP Envelope, or WSDL binding, etc.) as this TA,
or a target that is of a more general type than the main TA target. The
target must "pass" each one of these prerequisite TAs in order to
qualify for this TA.(e.g. the target of TA t1 can be a WSDL binding
while the target of a TA t2 prerequisite of t1, can be the entire WSDL
file).The second part ("prerequisite" element) is an XPath (boolean)
expression of the same nature as the predicate. If present, it must
evaluate to "true" for the target to qualify. If it fails, the result
for the current TA in the report will be "notRelevant". Otherwise, the
target can be further evaluated by the predicate of the main TA. The
expression may refer to the target explicitly using the variable name
"$target", or to any cotarget using its name as variable name ($[name]). |
Predicate:
|
[markup:
testAssertion/predicate] required element]A logical expression that
evaluates whether this target is fulfilling the profile requirement
addressed by this test Assertion. By default: - A result of true means
the requirement is fulfilled (reported as a "passed" in the test
report). - A result of false means the requirement is violated
(reported as a "failed" in the test report). However, in some cases and
for testability reasons, the predicate may be designed as a partial
indicator e.g. only indicates some cases of fulfillment, or some cases
of violation. As a result, when "true" indicates fulfillment it may be
that "false" is unconclusive, or conversely "false" will indicate
violation, but "true" is unconclusive. In such cases, the "Reporting"
element specifies the meaning of the predicate result w/r to the
profile requirement.The predicate expression implicitly refers to the
target (whic is its "XPath context") although it may explicitly refer
to it using the variable name "$target". It may refer to any cotarget
using its name as variable name ($[name]). |
Prescription:
|
[markup: testAssertion/prescription/@level ] (required)
Conveys the level of prescription associated with the profile requirement.
At least three values may be used:
mandatory: maps to RFC2119 keywords MUST, MUST NOT, SHALL,
SHALL NOT, REQUIRED (and sometimes MAY NOT) preferred: maps to RFC2119 keywords SHOULD, SHOULD NOT,
RECOMMENDED, NOT RECOMMENDED permitted: maps to RFC2119 keywords MAY, OPTIONAL. |
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: @true attribute: may take values among
{passed, failed, warning, undetermined} (default is 'passed') @false
attribute: may take values among {passed, failed, warning,
undetermined} (default is 'failed') The reported outcomes have the
following meaning:passed: the target passes the test and can be
considered as fulfilling the profile feature.failed: the target fails
the test and can be considered as violating (or not exhibiting) the
profile feature.warning: the test result is inconclusive. There is a
possibility of profile requirement violation, that deserved further
investigation.undetermined: the test result is inconclusive for this
predicate value.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:notRelevant: the
target failed the prerequisite condition and therefore does not qualify
for further testing (i.e. the predicate expression is NOT evaluated on
it).missingInput: a cotarget expression returned an empty node
set.notApplicable: this target was not even selected by the target
XPath expression, while being of the same general artifact type (e.g.
message type). |
R2113
When referring to a non-addressable endpoint, and if present in a SOAP
ENVELOPE, the /wsrm:CreateSequence/wsrm:Offer/wsrm:Endpoint element MUST be set to an instance of the WS-MakeConnection anonymous URI.
TESTABLE
RSP2113
Test Assertion Analysis: |
RSP2113
|
General Notes: |
To
ensure all of the RM features can be used, even when a non-addressable
endpoint is used, the RSP requires implementations to use an instance
of the MC Anonymous URI in the CS/Offer/Endpoint EPR. |
Coverage Assessment: |
Good (should be able to cover all cases) |
Target Type: |
ENVELOPE |
Test Target: |
A CreateSequence message that contains an Offer element. |
Test co-Target(s): |
|
Test Prerequisite: |
|
Predicate: |
The [target] does not have a CreateSequence/Offer/wsa:Address element with a value of wsa:Anonymous or wsa:None. |
Prescription: |
mandatory |
Reporting: |
true=passed, false=failed |
Test Control: |
Run some reliable request/response tests where the client is non-addressable and make sure the CreateSequence contains an Offer. |
Test Assertion: |
RSP2113
|
Description: |
|
Target: |
/wsil:testLog/wsil:messageLog/wsil:message/wsil:messageContents/*:Envelope
[*:Body/wsrm:CreateSequence/wsrm:Offer and
(fn:contains(xsd:string(*:Body/wsrm:CreateSequence/wsrm:Offer/wsrm:Endpoint/*:Address), 'anonymous') or
fn:contains(xsd:string(*:Body/wsrm:CreateSequence/wsrm:Offer/wsrm:Endpoint/*:Address), 'none'))] |
Predicate: |
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: |
|
HELP - GLOSSARY
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:
passedfailedwarningnotApplicablenotRelevantmissingInputundeterminedSee
the "reporting" item for the meaning of these results. |
Cotarget:
|
[markup:
testAssertion/cotarget ] (optional)Artifact that is related to the
target, and that needs be accessed for the testing. Identified by an
XPath expression that may refer to the related target node using the
variable '$target'. For example, the target can be a SOAP message and
the cotarget the WSDL file that describes this SOAP message.A cotarget
must have a @name attribute that identifies it. The value of this
attribute can be used as a variable (when prepending '$' to it) by
subsequently defined cotargets, prerequisite and predicate. |
Prerequisite:
|
[markup:
testAssertion/@preReq ] (optional)[markup: testAssertion/prerequisite ]
(optional)The pre-condition for evaluating this Test Assertion on this
target. If the prerequisite evaluates to "false" then the target does
not qualify for this Test Assertion (the test report is
"notRelevant")The first part (preReq attribute) is an enumeration of
Test Assertion IDs. Each one of the prerequisite TAs must either use
the same target (e.g. SOAP Envelope, or WSDL binding, etc.) as this TA,
or a target that is of a more general type than the main TA target. The
target must "pass" each one of these prerequisite TAs in order to
qualify for this TA.(e.g. the target of TA t1 can be a WSDL binding
while the target of a TA t2 prerequisite of t1, can be the entire WSDL
file).The second part ("prerequisite" element) is an XPath (boolean)
expression of the same nature as the predicate. If present, it must
evaluate to "true" for the target to qualify. If it fails, the result
for the current TA in the report will be "notRelevant". Otherwise, the
target can be further evaluated by the predicate of the main TA. The
expression may refer to the target explicitly using the variable name
"$target", or to any cotarget using its name as variable name ($[name]). |
Predicate:
|
[markup:
testAssertion/predicate] required element]A logical expression that
evaluates whether this target is fulfilling the profile requirement
addressed by this test Assertion. By default: - A result of true means
the requirement is fulfilled (reported as a "passed" in the test
report). - A result of false means the requirement is violated
(reported as a "failed" in the test report). However, in some cases and
for testability reasons, the predicate may be designed as a partial
indicator e.g. only indicates some cases of fulfillment, or some cases
of violation. As a result, when "true" indicates fulfillment it may be
that "false" is unconclusive, or conversely "false" will indicate
violation, but "true" is unconclusive. In such cases, the "Reporting"
element specifies the meaning of the predicate result w/r to the
profile requirement.The predicate expression implicitly refers to the
target (whic is its "XPath context") although it may explicitly refer
to it using the variable name "$target". It may refer to any cotarget
using its name as variable name ($[name]). |
Prescription:
|
[markup: testAssertion/prescription/@level ] (required)
Conveys the level of prescription associated with the profile requirement.
At least three values may be used:
mandatory: maps to RFC2119 keywords MUST, MUST NOT, SHALL,
SHALL NOT, REQUIRED (and sometimes MAY NOT) preferred: maps to RFC2119 keywords SHOULD, SHOULD NOT,
RECOMMENDED, NOT RECOMMENDED permitted: maps to RFC2119 keywords MAY, OPTIONAL. |
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: @true attribute: may take values among
{passed, failed, warning, undetermined} (default is 'passed') @false
attribute: may take values among {passed, failed, warning,
undetermined} (default is 'failed') The reported outcomes have the
following meaning:passed: the target passes the test and can be
considered as fulfilling the profile feature.failed: the target fails
the test and can be considered as violating (or not exhibiting) the
profile feature.warning: the test result is inconclusive. There is a
possibility of profile requirement violation, that deserved further
investigation.undetermined: the test result is inconclusive for this
predicate value.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:notRelevant: the
target failed the prerequisite condition and therefore does not qualify
for further testing (i.e. the predicate expression is NOT evaluated on
it).missingInput: a cotarget expression returned an empty node
set.notApplicable: this target was not even selected by the target
XPath expression, while being of the same general artifact type (e.g.
message type). |
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:
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: |
RSP3010
|
General Notes: |
|
Coverage Assessment: |
Good |
Target Type: |
ENVELOPE |
Test Target: |
For an Envelope that contains a wsrm:CreateSequence element that has security token ref |
Test co-Target(s): |
|
Test Prerequisite: |
|
Predicate: |
Envelope includes the UsesSequenceSTR header |
Prescription: |
mandatory |
Reporting: |
(default) |
Test Control: |
scenario provide the expected "context" (manipulate content of CreateSequence) |
Test Assertion: |
RSP3010
|
Description: |
|
Target: |
/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: |
|
HELP - GLOSSARY
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:
passedfailedwarningnotApplicablenotRelevantmissingInputundeterminedSee
the "reporting" item for the meaning of these results. |
Cotarget:
|
[markup:
testAssertion/cotarget ] (optional)Artifact that is related to the
target, and that needs be accessed for the testing. Identified by an
XPath expression that may refer to the related target node using the
variable '$target'. For example, the target can be a SOAP message and
the cotarget the WSDL file that describes this SOAP message.A cotarget
must have a @name attribute that identifies it. The value of this
attribute can be used as a variable (when prepending '$' to it) by
subsequently defined cotargets, prerequisite and predicate. |
Prerequisite:
|
[markup:
testAssertion/@preReq ] (optional)[markup: testAssertion/prerequisite ]
(optional)The pre-condition for evaluating this Test Assertion on this
target. If the prerequisite evaluates to "false" then the target does
not qualify for this Test Assertion (the test report is
"notRelevant")The first part (preReq attribute) is an enumeration of
Test Assertion IDs. Each one of the prerequisite TAs must either use
the same target (e.g. SOAP Envelope, or WSDL binding, etc.) as this TA,
or a target that is of a more general type than the main TA target. The
target must "pass" each one of these prerequisite TAs in order to
qualify for this TA.(e.g. the target of TA t1 can be a WSDL binding
while the target of a TA t2 prerequisite of t1, can be the entire WSDL
file).The second part ("prerequisite" element) is an XPath (boolean)
expression of the same nature as the predicate. If present, it must
evaluate to "true" for the target to qualify. If it fails, the result
for the current TA in the report will be "notRelevant". Otherwise, the
target can be further evaluated by the predicate of the main TA. The
expression may refer to the target explicitly using the variable name
"$target", or to any cotarget using its name as variable name ($[name]). |
Predicate:
|
[markup:
testAssertion/predicate] required element]A logical expression that
evaluates whether this target is fulfilling the profile requirement
addressed by this test Assertion. By default: - A result of true means
the requirement is fulfilled (reported as a "passed" in the test
report). - A result of false means the requirement is violated
(reported as a "failed" in the test report). However, in some cases and
for testability reasons, the predicate may be designed as a partial
indicator e.g. only indicates some cases of fulfillment, or some cases
of violation. As a result, when "true" indicates fulfillment it may be
that "false" is unconclusive, or conversely "false" will indicate
violation, but "true" is unconclusive. In such cases, the "Reporting"
element specifies the meaning of the predicate result w/r to the
profile requirement.The predicate expression implicitly refers to the
target (whic is its "XPath context") although it may explicitly refer
to it using the variable name "$target". It may refer to any cotarget
using its name as variable name ($[name]). |
Prescription:
|
[markup: testAssertion/prescription/@level ] (required)
Conveys the level of prescription associated with the profile requirement.
At least three values may be used:
mandatory: maps to RFC2119 keywords MUST, MUST NOT, SHALL,
SHALL NOT, REQUIRED (and sometimes MAY NOT) preferred: maps to RFC2119 keywords SHOULD, SHOULD NOT,
RECOMMENDED, NOT RECOMMENDED permitted: maps to RFC2119 keywords MAY, OPTIONAL. |
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: @true attribute: may take values among
{passed, failed, warning, undetermined} (default is 'passed') @false
attribute: may take values among {passed, failed, warning,
undetermined} (default is 'failed') The reported outcomes have the
following meaning:passed: the target passes the test and can be
considered as fulfilling the profile feature.failed: the target fails
the test and can be considered as violating (or not exhibiting) the
profile feature.warning: the test result is inconclusive. There is a
possibility of profile requirement violation, that deserved further
investigation.undetermined: the test result is inconclusive for this
predicate value.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:notRelevant: the
target failed the prerequisite condition and therefore does not qualify
for further testing (i.e. the predicate expression is NOT evaluated on
it).missingInput: a cotarget expression returned an empty node
set.notApplicable: this target was not even selected by the target
XPath expression, while being of the same general artifact type (e.g.
message type). |
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: |
RSP3100
|
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 |
$target/preceding::*: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: |
|
HELP - GLOSSARY
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:
passedfailedwarningnotApplicablenotRelevantmissingInputundeterminedSee
the "reporting" item for the meaning of these results. |
Cotarget:
|
[markup:
testAssertion/cotarget ] (optional)Artifact that is related to the
target, and that needs be accessed for the testing. Identified by an
XPath expression that may refer to the related target node using the
variable '$target'. For example, the target can be a SOAP message and
the cotarget the WSDL file that describes this SOAP message.A cotarget
must have a @name attribute that identifies it. The value of this
attribute can be used as a variable (when prepending '$' to it) by
subsequently defined cotargets, prerequisite and predicate. |
Prerequisite:
|
[markup:
testAssertion/@preReq ] (optional)[markup: testAssertion/prerequisite ]
(optional)The pre-condition for evaluating this Test Assertion on this
target. If the prerequisite evaluates to "false" then the target does
not qualify for this Test Assertion (the test report is
"notRelevant")The first part (preReq attribute) is an enumeration of
Test Assertion IDs. Each one of the prerequisite TAs must either use
the same target (e.g. SOAP Envelope, or WSDL binding, etc.) as this TA,
or a target that is of a more general type than the main TA target. The
target must "pass" each one of these prerequisite TAs in order to
qualify for this TA.(e.g. the target of TA t1 can be a WSDL binding
while the target of a TA t2 prerequisite of t1, can be the entire WSDL
file).The second part ("prerequisite" element) is an XPath (boolean)
expression of the same nature as the predicate. If present, it must
evaluate to "true" for the target to qualify. If it fails, the result
for the current TA in the report will be "notRelevant". Otherwise, the
target can be further evaluated by the predicate of the main TA. The
expression may refer to the target explicitly using the variable name
"$target", or to any cotarget using its name as variable name ($[name]). |
Predicate:
|
[markup:
testAssertion/predicate] required element]A logical expression that
evaluates whether this target is fulfilling the profile requirement
addressed by this test Assertion. By default: - A result of true means
the requirement is fulfilled (reported as a "passed" in the test
report). - A result of false means the requirement is violated
(reported as a "failed" in the test report). However, in some cases and
for testability reasons, the predicate may be designed as a partial
indicator e.g. only indicates some cases of fulfillment, or some cases
of violation. As a result, when "true" indicates fulfillment it may be
that "false" is unconclusive, or conversely "false" will indicate
violation, but "true" is unconclusive. In such cases, the "Reporting"
element specifies the meaning of the predicate result w/r to the
profile requirement.The predicate expression implicitly refers to the
target (whic is its "XPath context") although it may explicitly refer
to it using the variable name "$target". It may refer to any cotarget
using its name as variable name ($[name]). |
Prescription:
|
[markup: testAssertion/prescription/@level ] (required)
Conveys the level of prescription associated with the profile requirement.
At least three values may be used:
mandatory: maps to RFC2119 keywords MUST, MUST NOT, SHALL,
SHALL NOT, REQUIRED (and sometimes MAY NOT) preferred: maps to RFC2119 keywords SHOULD, SHOULD NOT,
RECOMMENDED, NOT RECOMMENDED permitted: maps to RFC2119 keywords MAY, OPTIONAL. |
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: @true attribute: may take values among
{passed, failed, warning, undetermined} (default is 'passed') @false
attribute: may take values among {passed, failed, warning,
undetermined} (default is 'failed') The reported outcomes have the
following meaning:passed: the target passes the test and can be
considered as fulfilling the profile feature.failed: the target fails
the test and can be considered as violating (or not exhibiting) the
profile feature.warning: the test result is inconclusive. There is a
possibility of profile requirement violation, that deserved further
investigation.undetermined: the test result is inconclusive for this
predicate value.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:notRelevant: the
target failed the prerequisite condition and therefore does not qualify
for further testing (i.e. the predicate expression is NOT evaluated on
it).missingInput: a cotarget expression returned an empty node
set.notApplicable: this target was not even selected by the target
XPath expression, while being of the same general artifact type (e.g.
message type). |
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: |
RSP3101
|
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: |
|
HELP - GLOSSARY
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:
passedfailedwarningnotApplicablenotRelevantmissingInputundeterminedSee
the "reporting" item for the meaning of these results. |
Cotarget:
|
[markup:
testAssertion/cotarget ] (optional)Artifact that is related to the
target, and that needs be accessed for the testing. Identified by an
XPath expression that may refer to the related target node using the
variable '$target'. For example, the target can be a SOAP message and
the cotarget the WSDL file that describes this SOAP message.A cotarget
must have a @name attribute that identifies it. The value of this
attribute can be used as a variable (when prepending '$' to it) by
subsequently defined cotargets, prerequisite and predicate. |
Prerequisite:
|
[markup:
testAssertion/@preReq ] (optional)[markup: testAssertion/prerequisite ]
(optional)The pre-condition for evaluating this Test Assertion on this
target. If the prerequisite evaluates to "false" then the target does
not qualify for this Test Assertion (the test report is
"notRelevant")The first part (preReq attribute) is an enumeration of
Test Assertion IDs. Each one of the prerequisite TAs must either use
the same target (e.g. SOAP Envelope, or WSDL binding, etc.) as this TA,
or a target that is of a more general type than the main TA target. The
target must "pass" each one of these prerequisite TAs in order to
qualify for this TA.(e.g. the target of TA t1 can be a WSDL binding
while the target of a TA t2 prerequisite of t1, can be the entire WSDL
file).The second part ("prerequisite" element) is an XPath (boolean)
expression of the same nature as the predicate. If present, it must
evaluate to "true" for the target to qualify. If it fails, the result
for the current TA in the report will be "notRelevant". Otherwise, the
target can be further evaluated by the predicate of the main TA. The
expression may refer to the target explicitly using the variable name
"$target", or to any cotarget using its name as variable name ($[name]). |
Predicate:
|
[markup:
testAssertion/predicate] required element]A logical expression that
evaluates whether this target is fulfilling the profile requirement
addressed by this test Assertion. By default: - A result of true means
the requirement is fulfilled (reported as a "passed" in the test
report). - A result of false means the requirement is violated
(reported as a "failed" in the test report). However, in some cases and
for testability reasons, the predicate may be designed as a partial
indicator e.g. only indicates some cases of fulfillment, or some cases
of violation. As a result, when "true" indicates fulfillment it may be
that "false" is unconclusive, or conversely "false" will indicate
violation, but "true" is unconclusive. In such cases, the "Reporting"
element specifies the meaning of the predicate result w/r to the
profile requirement.The predicate expression implicitly refers to the
target (whic is its "XPath context") although it may explicitly refer
to it using the variable name "$target". It may refer to any cotarget
using its name as variable name ($[name]). |
Prescription:
|
[markup: testAssertion/prescription/@level ] (required)
Conveys the level of prescription associated with the profile requirement.
At least three values may be used:
mandatory: maps to RFC2119 keywords MUST, MUST NOT, SHALL,
SHALL NOT, REQUIRED (and sometimes MAY NOT) preferred: maps to RFC2119 keywords SHOULD, SHOULD NOT,
RECOMMENDED, NOT RECOMMENDED permitted: maps to RFC2119 keywords MAY, OPTIONAL. |
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: @true attribute: may take values among
{passed, failed, warning, undetermined} (default is 'passed') @false
attribute: may take values among {passed, failed, warning,
undetermined} (default is 'failed') The reported outcomes have the
following meaning:passed: the target passes the test and can be
considered as fulfilling the profile feature.failed: the target fails
the test and can be considered as violating (or not exhibiting) the
profile feature.warning: the test result is inconclusive. There is a
possibility of profile requirement violation, that deserved further
investigation.undetermined: the test result is inconclusive for this
predicate value.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:notRelevant: the
target failed the prerequisite condition and therefore does not qualify
for further testing (i.e. the predicate expression is NOT evaluated on
it).missingInput: a cotarget expression returned an empty node
set.notApplicable: this target was not even selected by the target
XPath expression, while being of the same general artifact type (e.g.
message type). |
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. TBD
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: |
RSP3110
|
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: |
|
HELP - GLOSSARY
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:
passedfailedwarningnotApplicablenotRelevantmissingInputundeterminedSee
the "reporting" item for the meaning of these results. |
Cotarget:
|
[markup:
testAssertion/cotarget ] (optional)Artifact that is related to the
target, and that needs be accessed for the testing. Identified by an
XPath expression that may refer to the related target node using the
variable '$target'. For example, the target can be a SOAP message and
the cotarget the WSDL file that describes this SOAP message.A cotarget
must have a @name attribute that identifies it. The value of this
attribute can be used as a variable (when prepending '$' to it) by
subsequently defined cotargets, prerequisite and predicate. |
Prerequisite:
|
[markup:
testAssertion/@preReq ] (optional)[markup: testAssertion/prerequisite ]
(optional)The pre-condition for evaluating this Test Assertion on this
target. If the prerequisite evaluates to "false" then the target does
not qualify for this Test Assertion (the test report is
"notRelevant")The first part (preReq attribute) is an enumeration of
Test Assertion IDs. Each one of the prerequisite TAs must either use
the same target (e.g. SOAP Envelope, or WSDL binding, etc.) as this TA,
or a target that is of a more general type than the main TA target. The
target must "pass" each one of these prerequisite TAs in order to
qualify for this TA.(e.g. the target of TA t1 can be a WSDL binding
while the target of a TA t2 prerequisite of t1, can be the entire WSDL
file).The second part ("prerequisite" element) is an XPath (boolean)
expression of the same nature as the predicate. If present, it must
evaluate to "true" for the target to qualify. If it fails, the result
for the current TA in the report will be "notRelevant". Otherwise, the
target can be further evaluated by the predicate of the main TA. The
expression may refer to the target explicitly using the variable name
"$target", or to any cotarget using its name as variable name ($[name]). |
Predicate:
|
[markup:
testAssertion/predicate] required element]A logical expression that
evaluates whether this target is fulfilling the profile requirement
addressed by this test Assertion. By default: - A result of true means
the requirement is fulfilled (reported as a "passed" in the test
report). - A result of false means the requirement is violated
(reported as a "failed" in the test report). However, in some cases and
for testability reasons, the predicate may be designed as a partial
indicator e.g. only indicates some cases of fulfillment, or some cases
of violation. As a result, when "true" indicates fulfillment it may be
that "false" is unconclusive, or conversely "false" will indicate
violation, but "true" is unconclusive. In such cases, the "Reporting"
element specifies the meaning of the predicate result w/r to the
profile requirement.The predicate expression implicitly refers to the
target (whic is its "XPath context") although it may explicitly refer
to it using the variable name "$target". It may refer to any cotarget
using its name as variable name ($[name]). |
Prescription:
|
[markup: testAssertion/prescription/@level ] (required)
Conveys the level of prescription associated with the profile requirement.
At least three values may be used:
mandatory: maps to RFC2119 keywords MUST, MUST NOT, SHALL,
SHALL NOT, REQUIRED (and sometimes MAY NOT) preferred: maps to RFC2119 keywords SHOULD, SHOULD NOT,
RECOMMENDED, NOT RECOMMENDED permitted: maps to RFC2119 keywords MAY, OPTIONAL. |
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: @true attribute: may take values among
{passed, failed, warning, undetermined} (default is 'passed') @false
attribute: may take values among {passed, failed, warning,
undetermined} (default is 'failed') The reported outcomes have the
following meaning:passed: the target passes the test and can be
considered as fulfilling the profile feature.failed: the target fails
the test and can be considered as violating (or not exhibiting) the
profile feature.warning: the test result is inconclusive. There is a
possibility of profile requirement violation, that deserved further
investigation.undetermined: the test result is inconclusive for this
predicate value.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:notRelevant: the
target failed the prerequisite condition and therefore does not qualify
for further testing (i.e. the predicate expression is NOT evaluated on
it).missingInput: a cotarget expression returned an empty node
set.notApplicable: this target was not even selected by the target
XPath expression, while being of the same general artifact type (e.g.
message type). |
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. TBD
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: |
RSP3114
|
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: |
|
HELP - GLOSSARY
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:
passedfailedwarningnotApplicablenotRelevantmissingInputundeterminedSee
the "reporting" item for the meaning of these results. |
Cotarget:
|
[markup:
testAssertion/cotarget ] (optional)Artifact that is related to the
target, and that needs be accessed for the testing. Identified by an
XPath expression that may refer to the related target node using the
variable '$target'. For example, the target can be a SOAP message and
the cotarget the WSDL file that describes this SOAP message.A cotarget
must have a @name attribute that identifies it. The value of this
attribute can be used as a variable (when prepending '$' to it) by
subsequently defined cotargets, prerequisite and predicate. |
Prerequisite:
|
[markup:
testAssertion/@preReq ] (optional)[markup: testAssertion/prerequisite ]
(optional)The pre-condition for evaluating this Test Assertion on this
target. If the prerequisite evaluates to "false" then the target does
not qualify for this Test Assertion (the test report is
"notRelevant")The first part (preReq attribute) is an enumeration of
Test Assertion IDs. Each one of the prerequisite TAs must either use
the same target (e.g. SOAP Envelope, or WSDL binding, etc.) as this TA,
or a target that is of a more general type than the main TA target. The
target must "pass" each one of these prerequisite TAs in order to
qualify for this TA.(e.g. the target of TA t1 can be a WSDL binding
while the target of a TA t2 prerequisite of t1, can be the entire WSDL
file).The second part ("prerequisite" element) is an XPath (boolean)
expression of the same nature as the predicate. If present, it must
evaluate to "true" for the target to qualify. If it fails, the result
for the current TA in the report will be "notRelevant". Otherwise, the
target can be further evaluated by the predicate of the main TA. The
expression may refer to the target explicitly using the variable name
"$target", or to any cotarget using its name as variable name ($[name]). |
Predicate:
|
[markup:
testAssertion/predicate] required element]A logical expression that
evaluates whether this target is fulfilling the profile requirement
addressed by this test Assertion. By default: - A result of true means
the requirement is fulfilled (reported as a "passed" in the test
report). - A result of false means the requirement is violated
(reported as a "failed" in the test report). However, in some cases and
for testability reasons, the predicate may be designed as a partial
indicator e.g. only indicates some cases of fulfillment, or some cases
of violation. As a result, when "true" indicates fulfillment it may be
that "false" is unconclusive, or conversely "false" will indicate
violation, but "true" is unconclusive. In such cases, the "Reporting"
element specifies the meaning of the predicate result w/r to the
profile requirement.The predicate expression implicitly refers to the
target (whic is its "XPath context") although it may explicitly refer
to it using the variable name "$target". It may refer to any cotarget
using its name as variable name ($[name]). |
Prescription:
|
[markup: testAssertion/prescription/@level ] (required)
Conveys the level of prescription associated with the profile requirement.
At least three values may be used:
mandatory: maps to RFC2119 keywords MUST, MUST NOT, SHALL,
SHALL NOT, REQUIRED (and sometimes MAY NOT) preferred: maps to RFC2119 keywords SHOULD, SHOULD NOT,
RECOMMENDED, NOT RECOMMENDED permitted: maps to RFC2119 keywords MAY, OPTIONAL. |
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: @true attribute: may take values among
{passed, failed, warning, undetermined} (default is 'passed') @false
attribute: may take values among {passed, failed, warning,
undetermined} (default is 'failed') The reported outcomes have the
following meaning:passed: the target passes the test and can be
considered as fulfilling the profile feature.failed: the target fails
the test and can be considered as violating (or not exhibiting) the
profile feature.warning: the test result is inconclusive. There is a
possibility of profile requirement violation, that deserved further
investigation.undetermined: the test result is inconclusive for this
predicate value.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:notRelevant: the
target failed the prerequisite condition and therefore does not qualify
for further testing (i.e. the predicate expression is NOT evaluated on
it).missingInput: a cotarget expression returned an empty node
set.notApplicable: this target was not even selected by the target
XPath expression, while being of the same general artifact type (e.g.
message type). |
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. TBD
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: |
RSP3117
|
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: |
|
HELP - GLOSSARY
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:
passedfailedwarningnotApplicablenotRelevantmissingInputundeterminedSee
the "reporting" item for the meaning of these results. |
Cotarget:
|
[markup:
testAssertion/cotarget ] (optional)Artifact that is related to the
target, and that needs be accessed for the testing. Identified by an
XPath expression that may refer to the related target node using the
variable '$target'. For example, the target can be a SOAP message and
the cotarget the WSDL file that describes this SOAP message.A cotarget
must have a @name attribute that identifies it. The value of this
attribute can be used as a variable (when prepending '$' to it) by
subsequently defined cotargets, prerequisite and predicate. |
Prerequisite:
|
[markup:
testAssertion/@preReq ] (optional)[markup: testAssertion/prerequisite ]
(optional)The pre-condition for evaluating this Test Assertion on this
target. If the prerequisite evaluates to "false" then the target does
not qualify for this Test Assertion (the test report is
"notRelevant")The first part (preReq attribute) is an enumeration of
Test Assertion IDs. Each one of the prerequisite TAs must either use
the same target (e.g. SOAP Envelope, or WSDL binding, etc.) as this TA,
or a target that is of a more general type than the main TA target. The
target must "pass" each one of these prerequisite TAs in order to
qualify for this TA.(e.g. the target of TA t1 can be a WSDL binding
while the target of a TA t2 prerequisite of t1, can be the entire WSDL
file).The second part ("prerequisite" element) is an XPath (boolean)
expression of the same nature as the predicate. If present, it must
evaluate to "true" for the target to qualify. If it fails, the result
for the current TA in the report will be "notRelevant". Otherwise, the
target can be further evaluated by the predicate of the main TA. The
expression may refer to the target explicitly using the variable name
"$target", or to any cotarget using its name as variable name ($[name]). |
Predicate:
|
[markup:
testAssertion/predicate] required element]A logical expression that
evaluates whether this target is fulfilling the profile requirement
addressed by this test Assertion. By default: - A result of true means
the requirement is fulfilled (reported as a "passed" in the test
report). - A result of false means the requirement is violated
(reported as a "failed" in the test report). However, in some cases and
for testability reasons, the predicate may be designed as a partial
indicator e.g. only indicates some cases of fulfillment, or some cases
of violation. As a result, when "true" indicates fulfillment it may be
that "false" is unconclusive, or conversely "false" will indicate
violation, but "true" is unconclusive. In such cases, the "Reporting"
element specifies the meaning of the predicate result w/r to the
profile requirement.The predicate expression implicitly refers to the
target (whic is its "XPath context") although it may explicitly refer
to it using the variable name "$target". It may refer to any cotarget
using its name as variable name ($[name]). |
Prescription:
|
[markup: testAssertion/prescription/@level ] (required)
Conveys the level of prescription associated with the profile requirement.
At least three values may be used:
mandatory: maps to RFC2119 keywords MUST, MUST NOT, SHALL,
SHALL NOT, REQUIRED (and sometimes MAY NOT) preferred: maps to RFC2119 keywords SHOULD, SHOULD NOT,
RECOMMENDED, NOT RECOMMENDED permitted: maps to RFC2119 keywords MAY, OPTIONAL. |
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: @true attribute: may take values among
{passed, failed, warning, undetermined} (default is 'passed') @false
attribute: may take values among {passed, failed, warning,
undetermined} (default is 'failed') The reported outcomes have the
following meaning:passed: the target passes the test and can be
considered as fulfilling the profile feature.failed: the target fails
the test and can be considered as violating (or not exhibiting) the
profile feature.warning: the test result is inconclusive. There is a
possibility of profile requirement violation, that deserved further
investigation.undetermined: the test result is inconclusive for this
predicate value.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:notRelevant: the
target failed the prerequisite condition and therefore does not qualify
for further testing (i.e. the predicate expression is NOT evaluated on
it).missingInput: a cotarget expression returned an empty node
set.notApplicable: this target was not even selected by the target
XPath expression, while being of the same general artifact type (e.g.
message type). |
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. TBD
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: |
RSP3120
|
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: |
|
HELP - GLOSSARY
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:
passedfailedwarningnotApplicablenotRelevantmissingInputundeterminedSee
the "reporting" item for the meaning of these results. |
Cotarget:
|
[markup:
testAssertion/cotarget ] (optional)Artifact that is related to the
target, and that needs be accessed for the testing. Identified by an
XPath expression that may refer to the related target node using the
variable '$target'. For example, the target can be a SOAP message and
the cotarget the WSDL file that describes this SOAP message.A cotarget
must have a @name attribute that identifies it. The value of this
attribute can be used as a variable (when prepending '$' to it) by
subsequently defined cotargets, prerequisite and predicate. |
Prerequisite:
|
[markup:
testAssertion/@preReq ] (optional)[markup: testAssertion/prerequisite ]
(optional)The pre-condition for evaluating this Test Assertion on this
target. If the prerequisite evaluates to "false" then the target does
not qualify for this Test Assertion (the test report is
"notRelevant")The first part (preReq attribute) is an enumeration of
Test Assertion IDs. Each one of the prerequisite TAs must either use
the same target (e.g. SOAP Envelope, or WSDL binding, etc.) as this TA,
or a target that is of a more general type than the main TA target. The
target must "pass" each one of these prerequisite TAs in order to
qualify for this TA.(e.g. the target of TA t1 can be a WSDL binding
while the target of a TA t2 prerequisite of t1, can be the entire WSDL
file).The second part ("prerequisite" element) is an XPath (boolean)
expression of the same nature as the predicate. If present, it must
evaluate to "true" for the target to qualify. If it fails, the result
for the current TA in the report will be "notRelevant". Otherwise, the
target can be further evaluated by the predicate of the main TA. The
expression may refer to the target explicitly using the variable name
"$target", or to any cotarget using its name as variable name ($[name]). |
Predicate:
|
[markup:
testAssertion/predicate] required element]A logical expression that
evaluates whether this target is fulfilling the profile requirement
addressed by this test Assertion. By default: - A result of true means
the requirement is fulfilled (reported as a "passed" in the test
report). - A result of false means the requirement is violated
(reported as a "failed" in the test report). However, in some cases and
for testability reasons, the predicate may be designed as a partial
indicator e.g. only indicates some cases of fulfillment, or some cases
of violation. As a result, when "true" indicates fulfillment it may be
that "false" is unconclusive, or conversely "false" will indicate
violation, but "true" is unconclusive. In such cases, the "Reporting"
element specifies the meaning of the predicate result w/r to the
profile requirement.The predicate expression implicitly refers to the
target (whic is its "XPath context") although it may explicitly refer
to it using the variable name "$target". It may refer to any cotarget
using its name as variable name ($[name]). |
Prescription:
|
[markup: testAssertion/prescription/@level ] (required)
Conveys the level of prescription associated with the profile requirement.
At least three values may be used:
mandatory: maps to RFC2119 keywords MUST, MUST NOT, SHALL,
SHALL NOT, REQUIRED (and sometimes MAY NOT) preferred: maps to RFC2119 keywords SHOULD, SHOULD NOT,
RECOMMENDED, NOT RECOMMENDED permitted: maps to RFC2119 keywords MAY, OPTIONAL. |
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: @true attribute: may take values among
{passed, failed, warning, undetermined} (default is 'passed') @false
attribute: may take values among {passed, failed, warning,
undetermined} (default is 'failed') The reported outcomes have the
following meaning:passed: the target passes the test and can be
considered as fulfilling the profile feature.failed: the target fails
the test and can be considered as violating (or not exhibiting) the
profile feature.warning: the test result is inconclusive. There is a
possibility of profile requirement violation, that deserved further
investigation.undetermined: the test result is inconclusive for this
predicate value.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:notRelevant: the
target failed the prerequisite condition and therefore does not qualify
for further testing (i.e. the predicate expression is NOT evaluated on
it).missingInput: a cotarget expression returned an empty node
set.notApplicable: this target was not even selected by the target
XPath expression, while being of the same general artifact type (e.g.
message type). |
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: |
RSP3121
|
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: |
|
HELP - GLOSSARY
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:
passedfailedwarningnotApplicablenotRelevantmissingInputundeterminedSee
the "reporting" item for the meaning of these results. |
Cotarget:
|
[markup:
testAssertion/cotarget ] (optional)Artifact that is related to the
target, and that needs be accessed for the testing. Identified by an
XPath expression that may refer to the related target node using the
variable '$target'. For example, the target can be a SOAP message and
the cotarget the WSDL file that describes this SOAP message.A cotarget
must have a @name attribute that identifies it. The value of this
attribute can be used as a variable (when prepending '$' to it) by
subsequently defined cotargets, prerequisite and predicate. |
Prerequisite:
|
[markup:
testAssertion/@preReq ] (optional)[markup: testAssertion/prerequisite ]
(optional)The pre-condition for evaluating this Test Assertion on this
target. If the prerequisite evaluates to "false" then the target does
not qualify for this Test Assertion (the test report is
"notRelevant")The first part (preReq attribute) is an enumeration of
Test Assertion IDs. Each one of the prerequisite TAs must either use
the same target (e.g. SOAP Envelope, or WSDL binding, etc.) as this TA,
or a target that is of a more general type than the main TA target. The
target must "pass" each one of these prerequisite TAs in order to
qualify for this TA.(e.g. the target of TA t1 can be a WSDL binding
while the target of a TA t2 prerequisite of t1, can be the entire WSDL
file).The second part ("prerequisite" element) is an XPath (boolean)
expression of the same nature as the predicate. If present, it must
evaluate to "true" for the target to qualify. If it fails, the result
for the current TA in the report will be "notRelevant". Otherwise, the
target can be further evaluated by the predicate of the main TA. The
expression may refer to the target explicitly using the variable name
"$target", or to any cotarget using its name as variable name ($[name]). |
Predicate:
|
[markup:
testAssertion/predicate] required element]A logical expression that
evaluates whether this target is fulfilling the profile requirement
addressed by this test Assertion. By default: - A result of true means
the requirement is fulfilled (reported as a "passed" in the test
report). - A result of false means the requirement is violated
(reported as a "failed" in the test report). However, in some cases and
for testability reasons, the predicate may be designed as a partial
indicator e.g. only indicates some cases of fulfillment, or some cases
of violation. As a result, when "true" indicates fulfillment it may be
that "false" is unconclusive, or conversely "false" will indicate
violation, but "true" is unconclusive. In such cases, the "Reporting"
element specifies the meaning of the predicate result w/r to the
profile requirement.The predicate expression implicitly refers to the
target (whic is its "XPath context") although it may explicitly refer
to it using the variable name "$target". It may refer to any cotarget
using its name as variable name ($[name]). |
Prescription:
|
[markup: testAssertion/prescription/@level ] (required)
Conveys the level of prescription associated with the profile requirement.
At least three values may be used:
mandatory: maps to RFC2119 keywords MUST, MUST NOT, SHALL,
SHALL NOT, REQUIRED (and sometimes MAY NOT) preferred: maps to RFC2119 keywords SHOULD, SHOULD NOT,
RECOMMENDED, NOT RECOMMENDED permitted: maps to RFC2119 keywords MAY, OPTIONAL. |
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: @true attribute: may take values among
{passed, failed, warning, undetermined} (default is 'passed') @false
attribute: may take values among {passed, failed, warning,
undetermined} (default is 'failed') The reported outcomes have the
following meaning:passed: the target passes the test and can be
considered as fulfilling the profile feature.failed: the target fails
the test and can be considered as violating (or not exhibiting) the
profile feature.warning: the test result is inconclusive. There is a
possibility of profile requirement violation, that deserved further
investigation.undetermined: the test result is inconclusive for this
predicate value.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:notRelevant: the
target failed the prerequisite condition and therefore does not qualify
for further testing (i.e. the predicate expression is NOT evaluated on
it).missingInput: a cotarget expression returned an empty node
set.notApplicable: this target was not even selected by the target
XPath expression, while being of the same general artifact type (e.g.
message type). |
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. TBD
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.
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: |
RSP3201
|
General Notes: |
|
Coverage Assessment: |
|
Target Type: |
ENVELOPE |
Test Target: |
Env contains MessagePending header AND whose Body is being signed (relates to Secured RM Seq) |
Test co-Target(s): |
|
Test Prerequisite: |
|
Predicate: |
(a)
is signed, (b) signature covers both the header block and the Body. The
[target]'s security Header that indicates the Body is signed also
includes a reference to the wsu:Id of the MessagePending Header |
Prescription: |
mandatory |
Reporting: |
(default) |
Test Control: |
Run
some secure request/response tests where there are several request
messages being processed at the same time (ie. they are not
serialized). Also, set the wsa:ReplyTo of the request messages (from a
non-addressable endpoint) to an instance of the MC Anonymous URI
Template. |
Test Assertion: |
RSP3201
|
Description: |
|
Target: |
/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: |
|
HELP - GLOSSARY
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:
passedfailedwarningnotApplicablenotRelevantmissingInputundeterminedSee
the "reporting" item for the meaning of these results. |
Cotarget:
|
[markup:
testAssertion/cotarget ] (optional)Artifact that is related to the
target, and that needs be accessed for the testing. Identified by an
XPath expression that may refer to the related target node using the
variable '$target'. For example, the target can be a SOAP message and
the cotarget the WSDL file that describes this SOAP message.A cotarget
must have a @name attribute that identifies it. The value of this
attribute can be used as a variable (when prepending '$' to it) by
subsequently defined cotargets, prerequisite and predicate. |
Prerequisite:
|
[markup:
testAssertion/@preReq ] (optional)[markup: testAssertion/prerequisite ]
(optional)The pre-condition for evaluating this Test Assertion on this
target. If the prerequisite evaluates to "false" then the target does
not qualify for this Test Assertion (the test report is
"notRelevant")The first part (preReq attribute) is an enumeration of
Test Assertion IDs. Each one of the prerequisite TAs must either use
the same target (e.g. SOAP Envelope, or WSDL binding, etc.) as this TA,
or a target that is of a more general type than the main TA target. The
target must "pass" each one of these prerequisite TAs in order to
qualify for this TA.(e.g. the target of TA t1 can be a WSDL binding
while the target of a TA t2 prerequisite of t1, can be the entire WSDL
file).The second part ("prerequisite" element) is an XPath (boolean)
expression of the same nature as the predicate. If present, it must
evaluate to "true" for the target to qualify. If it fails, the result
for the current TA in the report will be "notRelevant". Otherwise, the
target can be further evaluated by the predicate of the main TA. The
expression may refer to the target explicitly using the variable name
"$target", or to any cotarget using its name as variable name ($[name]). |
Predicate:
|
[markup:
testAssertion/predicate] required element]A logical expression that
evaluates whether this target is fulfilling the profile requirement
addressed by this test Assertion. By default: - A result of true means
the requirement is fulfilled (reported as a "passed" in the test
report). - A result of false means the requirement is violated
(reported as a "failed" in the test report). However, in some cases and
for testability reasons, the predicate may be designed as a partial
indicator e.g. only indicates some cases of fulfillment, or some cases
of violation. As a result, when "true" indicates fulfillment it may be
that "false" is unconclusive, or conversely "false" will indicate
violation, but "true" is unconclusive. In such cases, the "Reporting"
element specifies the meaning of the predicate result w/r to the
profile requirement.The predicate expression implicitly refers to the
target (whic is its "XPath context") although it may explicitly refer
to it using the variable name "$target". It may refer to any cotarget
using its name as variable name ($[name]). |
Prescription:
|
[markup: testAssertion/prescription/@level ] (required)
Conveys the level of prescription associated with the profile requirement.
At least three values may be used:
mandatory: maps to RFC2119 keywords MUST, MUST NOT, SHALL,
SHALL NOT, REQUIRED (and sometimes MAY NOT) preferred: maps to RFC2119 keywords SHOULD, SHOULD NOT,
RECOMMENDED, NOT RECOMMENDED permitted: maps to RFC2119 keywords MAY, OPTIONAL. |
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: @true attribute: may take values among
{passed, failed, warning, undetermined} (default is 'passed') @false
attribute: may take values among {passed, failed, warning,
undetermined} (default is 'failed') The reported outcomes have the
following meaning:passed: the target passes the test and can be
considered as fulfilling the profile feature.failed: the target fails
the test and can be considered as violating (or not exhibiting) the
profile feature.warning: the test result is inconclusive. There is a
possibility of profile requirement violation, that deserved further
investigation.undetermined: the test result is inconclusive for this
predicate value.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:notRelevant: the
target failed the prerequisite condition and therefore does not qualify
for further testing (i.e. the predicate expression is NOT evaluated on
it).missingInput: a cotarget expression returned an empty node
set.notApplicable: this target was not even selected by the target
XPath expression, while being of the same general artifact type (e.g.
message type). |
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: |
RSP3300
|
General Notes: |
|
Coverage Assessment: |
Good (should be able to cover all cases) |
Target Type: |
ENVELOPE |
Test Target: |
A
SOAP Envelope that belongs to a Secure Sequence, i.e. with a
wsrm:Sequence/wsrm:Identifier element that match the
wsrm:CreateSequenceResponse/wsrm:Identifier that is response of a
wsrm:CreateSequence element extended with a wsse:SecurityTokenReference
element. |
Test co-Target(s): |
|
Test Prerequisite: |
|
Predicate: |
The SOAP Envelope contains a wsse:Security header that has a wsu:Timestamp child element. |
Prescription: |
mandatory |
Reporting: |
true=passed, false=failed |
Test Control: |
No
WS-SecurityPolicy assertions will be deployed or published. Initiate a
Secure Sequence (wsrm:CreateSequence element has been extended with a
wsse:SecurityTokenReference element). Then RMS is sending messages over
this sequence. |
Test Assertion: |
RSP3300
|
Description: |
|
Target: |
/wsil:testLog/wsil:messageLog/wsil:message/wsil:messageContents/*:Envelope[*:Header/wsrm:Sequence][*:Header/wsse:Security] |
co-Target:
mysecureseq |
$target/preceding::*: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: |
$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: |
|
HELP - GLOSSARY
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:
passedfailedwarningnotApplicablenotRelevantmissingInputundeterminedSee
the "reporting" item for the meaning of these results. |
Cotarget:
|
[markup:
testAssertion/cotarget ] (optional)Artifact that is related to the
target, and that needs be accessed for the testing. Identified by an
XPath expression that may refer to the related target node using the
variable '$target'. For example, the target can be a SOAP message and
the cotarget the WSDL file that describes this SOAP message.A cotarget
must have a @name attribute that identifies it. The value of this
attribute can be used as a variable (when prepending '$' to it) by
subsequently defined cotargets, prerequisite and predicate. |
Prerequisite:
|
[markup:
testAssertion/@preReq ] (optional)[markup: testAssertion/prerequisite ]
(optional)The pre-condition for evaluating this Test Assertion on this
target. If the prerequisite evaluates to "false" then the target does
not qualify for this Test Assertion (the test report is
"notRelevant")The first part (preReq attribute) is an enumeration of
Test Assertion IDs. Each one of the prerequisite TAs must either use
the same target (e.g. SOAP Envelope, or WSDL binding, etc.) as this TA,
or a target that is of a more general type than the main TA target. The
target must "pass" each one of these prerequisite TAs in order to
qualify for this TA.(e.g. the target of TA t1 can be a WSDL binding
while the target of a TA t2 prerequisite of t1, can be the entire WSDL
file).The second part ("prerequisite" element) is an XPath (boolean)
expression of the same nature as the predicate. If present, it must
evaluate to "true" for the target to qualify. If it fails, the result
for the current TA in the report will be "notRelevant". Otherwise, the
target can be further evaluated by the predicate of the main TA. The
expression may refer to the target explicitly using the variable name
"$target", or to any cotarget using its name as variable name ($[name]). |
Predicate:
|
[markup:
testAssertion/predicate] required element]A logical expression that
evaluates whether this target is fulfilling the profile requirement
addressed by this test Assertion. By default: - A result of true means
the requirement is fulfilled (reported as a "passed" in the test
report). - A result of false means the requirement is violated
(reported as a "failed" in the test report). However, in some cases and
for testability reasons, the predicate may be designed as a partial
indicator e.g. only indicates some cases of fulfillment, or some cases
of violation. As a result, when "true" indicates fulfillment it may be
that "false" is unconclusive, or conversely "false" will indicate
violation, but "true" is unconclusive. In such cases, the "Reporting"
element specifies the meaning of the predicate result w/r to the
profile requirement.The predicate expression implicitly refers to the
target (whic is its "XPath context") although it may explicitly refer
to it using the variable name "$target". It may refer to any cotarget
using its name as variable name ($[name]). |
Prescription:
|
[markup: testAssertion/prescription/@level ] (required)
Conveys the level of prescription associated with the profile requirement.
At least three values may be used:
mandatory: maps to RFC2119 keywords MUST, MUST NOT, SHALL,
SHALL NOT, REQUIRED (and sometimes MAY NOT) preferred: maps to RFC2119 keywords SHOULD, SHOULD NOT,
RECOMMENDED, NOT RECOMMENDED permitted: maps to RFC2119 keywords MAY, OPTIONAL. |
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: @true attribute: may take values among
{passed, failed, warning, undetermined} (default is 'passed') @false
attribute: may take values among {passed, failed, warning,
undetermined} (default is 'failed') The reported outcomes have the
following meaning:passed: the target passes the test and can be
considered as fulfilling the profile feature.failed: the target fails
the test and can be considered as violating (or not exhibiting) the
profile feature.warning: the test result is inconclusive. There is a
possibility of profile requirement violation, that deserved further
investigation.undetermined: the test result is inconclusive for this
predicate value.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:notRelevant: the
target failed the prerequisite condition and therefore does not qualify
for further testing (i.e. the predicate expression is NOT evaluated on
it).missingInput: a cotarget expression returned an empty node
set.notApplicable: this target was not even selected by the target
XPath expression, while being of the same general artifact type (e.g.
message type). |
R3301
For any two
ENVELOPEs
in a particular secure Sequence that contain WS-RM Sequence headers in
which the value of their wsrm:MessageNumber elements are equal, it MUST
be true that neither of the envelopes contains a wsu:Timestamp as a
child element of wsse:Security header, OR that both messages contain a
wsu:Timestamp as child elements of their wsse:Security headers and the
value of these wsu:Timestamp elements are NOT equal. TESTABLE
RSP3301
Test Assertion Analysis: |
RSP3301
|
General Notes: |
This
is a more general situation than R3300: a WS-SecurityPolicy assertions
may or may not be deployed, that controls the presence of
wsu:Timestamp. Although the Rxxxx is considering a pair of Envelopes,
the test target (and predicate) focus on a single one at a time. |
Coverage Assessment: |
Good (should be able to cover all cases) |
Target Type: |
ENVELOPE |
Test Target: |
A SOAP Envelope that belongs to a Secure Sequence, (see the filter condition in R3300 for this) |
Test co-Target(s): |
|
Test Prerequisite: |
|
Predicate: |
if
the SOAP Envelope contains a wsse:Security/wsu:Timestamp child element,
then any previous RM retry SOAP Envelope (same
wsrm:Sequence/wsrm:Identifier and same
wsrm:Sequence/wsrm:MessageNumber) has a different
wsse:Security/wsu:Timestamp, else any previous RM retry SOAP Envelope
does NOT have wsu:Timestamp under wsse:Security |
Prescription: |
mandatory |
Reporting: |
true=passed, false=failed |
Test Control: |
Initiate
a Secure Sequence (wsrm:CreateSequence element has been extended with a
wsse:SecurityTokenReference element). Then RMS is sending messages over
this sequence. Manage to cause message resending (block Acks, or set
the retry period shorter than the Ack period.) |
Test Assertion: |
RSP3301
|
Description: |
|
Target: |
/wsil:testLog/wsil:messageLog/wsil:message/wsil:messageContents/*:Envelope[*:Header/wsrm:Sequence
= preceding::*:Envelope/*:Header/wsrm:Sequence][*:Header/wsse:Security] |
co-Target:
mysecureseq |
$target/preceding::*: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: |
|
HELP - GLOSSARY
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:
passedfailedwarningnotApplicablenotRelevantmissingInputundeterminedSee
the "reporting" item for the meaning of these results. |
Cotarget:
|
[markup:
testAssertion/cotarget ] (optional)Artifact that is related to the
target, and that needs be accessed for the testing. Identified by an
XPath expression that may refer to the related target node using the
variable '$target'. For example, the target can be a SOAP message and
the cotarget the WSDL file that describes this SOAP message.A cotarget
must have a @name attribute that identifies it. The value of this
attribute can be used as a variable (when prepending '$' to it) by
subsequently defined cotargets, prerequisite and predicate. |
Prerequisite:
|
[markup:
testAssertion/@preReq ] (optional)[markup: testAssertion/prerequisite ]
(optional)The pre-condition for evaluating this Test Assertion on this
target. If the prerequisite evaluates to "false" then the target does
not qualify for this Test Assertion (the test report is
"notRelevant")The first part (preReq attribute) is an enumeration of
Test Assertion IDs. Each one of the prerequisite TAs must either use
the same target (e.g. SOAP Envelope, or WSDL binding, etc.) as this TA,
or a target that is of a more general type than the main TA target. The
target must "pass" each one of these prerequisite TAs in order to
qualify for this TA.(e.g. the target of TA t1 can be a WSDL binding
while the target of a TA t2 prerequisite of t1, can be the entire WSDL
file).The second part ("prerequisite" element) is an XPath (boolean)
expression of the same nature as the predicate. If present, it must
evaluate to "true" for the target to qualify. If it fails, the result
for the current TA in the report will be "notRelevant". Otherwise, the
target can be further evaluated by the predicate of the main TA. The
expression may refer to the target explicitly using the variable name
"$target", or to any cotarget using its name as variable name ($[name]). |
Predicate:
|
[markup:
testAssertion/predicate] required element]A logical expression that
evaluates whether this target is fulfilling the profile requirement
addressed by this test Assertion. By default: - A result of true means
the requirement is fulfilled (reported as a "passed" in the test
report). - A result of false means the requirement is violated
(reported as a "failed" in the test report). However, in some cases and
for testability reasons, the predicate may be designed as a partial
indicator e.g. only indicates some cases of fulfillment, or some cases
of violation. As a result, when "true" indicates fulfillment it may be
that "false" is unconclusive, or conversely "false" will indicate
violation, but "true" is unconclusive. In such cases, the "Reporting"
element specifies the meaning of the predicate result w/r to the
profile requirement.The predicate expression implicitly refers to the
target (whic is its "XPath context") although it may explicitly refer
to it using the variable name "$target". It may refer to any cotarget
using its name as variable name ($[name]). |
Prescription:
|
[markup: testAssertion/prescription/@level ] (required)
Conveys the level of prescription associated with the profile requirement.
At least three values may be used:
mandatory: maps to RFC2119 keywords MUST, MUST NOT, SHALL,
SHALL NOT, REQUIRED (and sometimes MAY NOT) preferred: maps to RFC2119 keywords SHOULD, SHOULD NOT,
RECOMMENDED, NOT RECOMMENDED permitted: maps to RFC2119 keywords MAY, OPTIONAL. |
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: @true attribute: may take values among
{passed, failed, warning, undetermined} (default is 'passed') @false
attribute: may take values among {passed, failed, warning,
undetermined} (default is 'failed') The reported outcomes have the
following meaning:passed: the target passes the test and can be
considered as fulfilling the profile feature.failed: the target fails
the test and can be considered as violating (or not exhibiting) the
profile feature.warning: the test result is inconclusive. There is a
possibility of profile requirement violation, that deserved further
investigation.undetermined: the test result is inconclusive for this
predicate value.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:notRelevant: the
target failed the prerequisite condition and therefore does not qualify
for further testing (i.e. the predicate expression is NOT evaluated on
it).missingInput: a cotarget expression returned an empty node
set.notApplicable: this target was not even selected by the target
XPath expression, while being of the same general artifact type (e.g.
message type). |
Appendix A: Referenced Specifications
The following specifications' requirements are incorporated
into the Profile by reference, except where superseded by the
Profile:
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.
In
WS-SecureConversation 1.4:
-
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, whose members have included:
Incomplete List;
Doug Bunting (Microsoft)
Doug Davis (IBM)
Jacques Durand (Fujitsu)
Leonid Felikson (Freddie Mac)
Chris Ferris (IBM)
Robert Freund (Hitachi Ltd.).
Marc Goodner (Microsoft)
Frederick Hirsch (Nokia)
Ram Jeyaraman (Microsoft)
Anish Karmarkar (Oracle)
Charles LeVay (IBM)
Rich Levinson (Oracle)
Hal Lockhart (Oracle)
Monica Martin (Microsoft)
Arnaud Meyniel (Axway)
Dale Moberg (Axway)
Sanjay Patil (SAP)
Gilbert Pilz (Oracle)
Tom Rutt (Fujitsu)
Daniel Toth (Ford Motor Company)
Faisal Waris (Ford Motor Company)
Eric Wells (Hitachi Ltd.).