Basic Security Profile - Version 1.1 (WGAD)

This document defines the WS-I Basic Security Profile 1.1, based on a set of non-proprietary Web services specifications, along with clarifications and amendments to those specifications which promote interoperability.

Status of this Document

This document is a Working Group Approval Draft; it is an intermediate document that has been approved for publication by the Working Group. It is a work in progress, and should not be considered as final; other documents may supersede this document.

Notice

The material contained herein is not a license, either expressly or impliedly, to any intellectual property owned or controlled by any of the authors or developers of this material or WS-I. The material contained herein is provided on an "AS IS" basis and to the maximum extent permitted by applicable law, this material is provided AS IS AND WITH ALL FAULTS, and the authors and developers of this material and WS-I hereby disclaim all other warranties and conditions, either express, implied or statutory, including, but not limited to, any (if any) implied warranties, duties or conditions of merchantability, of fitness for a particular purpose, of accuracy or completeness of responses, of results, of workmanlike effort, of lack of viruses, and of lack of negligence. ALSO, THERE IS NO WARRANTY OR CONDITION OF TITLE, QUIET ENJOYMENT, QUIET POSSESSION, CORRESPONDENCE TO DESCRIPTION OR NON-INFRINGEMENT WITH REGARD TO THIS MATERIAL.

IN NO EVENT WILL ANY AUTHOR OR DEVELOPER OF THIS MATERIAL OR WS-I BE LIABLE TO ANY OTHER PARTY FOR THE COST OF PROCURING SUBSTITUTE GOODS OR SERVICES, LOST PROFITS, LOSS OF USE, LOSS OF DATA, OR ANY INCIDENTAL, CONSEQUENTIAL, DIRECT, INDIRECT, OR SPECIAL DAMAGES WHETHER UNDER CONTRACT, TORT, WARRANTY, OR OTHERWISE, ARISING IN ANY WAY OUT OF THIS OR ANY OTHER AGREEMENT RELATING TO THIS MATERIAL, WHETHER OR NOT SUCH PARTY HAD ADVANCE NOTICE OF THE POSSIBILITY OF SUCH DAMAGES.

Feedback

The Web Services-Interoperability Organization (WS-I) would like to receive input, suggestions and other feedback ("Feedback") on this work from a wide variety of industry participants to improve its quality over time.

By sending email, or otherwise communicating with WS-I, you (on behalf of yourself if you are an individual, and your company if you are providing Feedback on behalf of the company) will be deemed to have granted to WS-I, the members of WS-I, and other parties that have access to your Feedback, a non-exclusive, non-transferable, worldwide, perpetual, irrevocable, royalty-free license to use, disclose, copy, license, modify, sublicense or otherwise distribute and exploit in any manner whatsoever the Feedback you provide regarding the work. You acknowledge that you have no expectation of confidentiality with respect to any Feedback you provide. You represent and warrant that you have rights to provide this Feedback, and if you are providing Feedback on behalf of a company, you represent and warrant that you have the rights to provide Feedback on behalf of your company. You also acknowledge that WS-I is not required to review, discuss, use, consider or in any way incorporate your Feedback into future versions of its work. If WS-I does incorporate some or all of your Feedback in a future version of the work, it may, but is not obligated to include your name (or, if you are identified as acting on behalf of your company, the name of your company) on a list of contributors to the work. If the foregoing is not acceptable to you and any company on whose behalf you are acting, please do not provide any Feedback.

1. Introduction

This document defines the WS-I Basic Security Profile 1.1 (hereafter, "Profile"), consisting of a set of non-proprietary Web services specifications, along with clarifications to and amplifications of those specifications which promote interoperability.

Section 1, "Introduction," introduces the Basic Security Profile 1.1 and relates the philosophy that it takes with regard to interoperability.

Section 2, "Document Conventions," describes notational conventions utilized by the Basic Security Profile 1.1.

Section 3, "Profile Conformance," explains what it means to be conformant to the Basic Security Profile 1.1.

Each subsequent section addresses a component of the Basic Security Profile 1.1, 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 Guiding Principles

The Profile was developed according to a set of principles that, together, form the philosophy of the Basic Security Profile 1.1, as it relates to bringing about interoperability. This section documents these guidelines.

2. Document Conventions

This document follows conventions common to all WS-I profiles. These are described in the following sections.

2.1 Security Considerations

In addition to interoperability recommendations (which are made in Rnnnn statements and intended to improve interoperability), the Basic Security Profile 1.1 makes a number of security recommendations intended to improve security. These Security Considerations are presented as follows:

where "nnnn" is replaced by a number that is unique among the security recommendations in the Basic Security Profile 1.1, thereby forming a unique security recommendation identifier. Each security recommendation contains a SHOULD or a MAY to highlight exactly what is being recommended; however, these recommendations are informational only and are non-normative. Though security recommendations are expected to be tested by the test tools to highlight possible security problems, security recommendations have no impact on conformance.

It should be understood that, while a number of recommendations are made about security, adherence to these security recommendations does not guarantee security.

2.2 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 Basic Security Profile 1.1 (i.e., those impacting conformance, as outlined in "Conformance Requirements") are presented in the following manner:

where "nnnn" is replaced by a number that is unique among the requirements in the Basic Security Profile 1.1, 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:

where "nnnn" is replaced by a number that is unique among the extensibility points in the Basic Security Profile 1.1. 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.

2.3 Profile Identification and Versioning

This document is identified by a name (in this case, Basic Security Profile) and a version number (here, 1.1). 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.

3 Profile Conformance

Conformance to the Basic Security Profile 1.1 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.

3.1 Conformance Requirements

Requirements state the criteria for conformance to the Profile. They typically refer to an existing specification and embody refinements, amplifications, interpretations and clarifications to it in order to improve interoperability. All requirements in the Basic Security Profile 1.1 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 Basic Security Profile 1.1 and its referenced specifications contradict each other, the Basic Security Profile 1.1'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.

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 Basic Security Profile 1.1 are considered authoritative for the purposes of determining conformance.

None of the requirements in the Basic Security Profile 1.1, 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).

3.2 Conformance Targets

Conformance targets identify what artifacts (e.g., SOAP message, WSDL description, UDDI registry data) or parties (e.g., SOAP processor, end user) requirements apply to.

This allows for the definition of conformance in different contexts, to assure unambiguous interpretation of the applicability of requirements, and to allow conformance testing of artifacts (e.g., SOAP messages and WSDL descriptions) and the behavior of various parties to a Web service (e.g., clients and service instances).

Requirements' conformance targets are physical artifacts wherever possible, to simplify testing and avoid ambiguity.

3.3 Conformance Scope

The scope of the Basic Security Profile 1.1 delineates the technologies that it addresses; in other words, the Basic Security Profile 1.1 only attempts to improve interoperability within its own scope. Generally, the Basic Security Profile 1.1'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 Basic Security Profile 1.1 as an extensibility point, such a mechanism or parameter is outside the scope of the Basic Security Profile 1.1, and its use or non-use is not relevant to conformance.

Note that the Basic Security Profile 1.1 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 Basic Security Profile 1.1.

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.

3.4 Claiming Conformance

Claims of conformance to the Basic Security Profile 1.1 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:

The conformance claim URI for the Basic Security Profile 1.1 is " http://ws-i.org/profiles/basic-security/1.1/core " , with the following exceptions, which are associated with specific sections:

If a claim of conformance is made as described in CCAM to Basic Security Profile 1.1 (" http://ws-i.org/profiles/basic-security/1.1/core "), then the claim MUST also specify which tokens, be they BSP profile tokens or other mutually agreed upon tokens, are supported.

The conformance URI for transport level security ("http://ws-i.org/profiles/basic-security/1.1/transport") can be used in isolation or in combination with other conformance URIs.

3. Transport Layer Mechanisms

This section of the Basic Security Profile 1.1 incorporates the following specifications by reference, and defines extensibility points within them:

3.1 TLS and SSL Versions

SSL and TLS are both used as underlying protocols for HTTP/S. The Profile places the following constraints on those protocols:

3.1.1 SSL 2.0 Prohibited

SSL 2.0 has known security issues and all current implementations of HTTP/S support more recent protocols. Therefore the Basic Security Profile 1.1 prohibits use of SSL 2.0.

R2001 A SENDER MUST NOT use SSL 2.0 as the underlying protocol for HTTP/S.

R2002 A RECEIVER MUST NOT use SSL 2.0 as the underlying protocol for HTTP/S.

3.2 TLS and SSL Ciphersuites

In SSL and TLS, choices of algorithms are expressed as ciphersuites. The following subsections specify ciphersuites that are required, recommended, discouraged and prohibited, respectively. The use of any other ciphersuite not discussed below is optional.

3.2.1 Mandatory Ciphersuites

The specified algorithm suites are considered to be widely-implemented, secure and interoperable.

R5701 Any TLS-capable INSTANCE that is not FIPS compliant MUST support TLS_RSA_WITH_3DES_EDE_CBC_SHA

R5702 Any SSL-capable INSTANCE that is not FIPS compliant MUST support SSL_RSA_WITH_3DES_EDE_CBC_SHA

R5703 Any TLS-capable INSTANCE that is FIPS compliant MUST support TLS_RSA_FIPS_WITH_3DES_EDE_CBC_SHA

R5704 Any SSL-capable INSTANCE that is FIPS compliant MUST support SSL_RSA_FIPS_WITH_3DES_EDE_CBC_SHA

3.2.2 Recommended Ciphersuites

As the AES encryption algorithm is intended to supersede the 3DES algorithm, it is recommended that TLS-capable implementations implement TLS_RSA_WITH_AES_128_CBC_SHA or the FIPS equivalent, and SSL-capable implementations implement SSL_RSA_WITH_AES_128_CBC_SHA or the FIPS equivalent.

3.2.3 Discouraged Ciphersuites

The ciphersuites defined in the SSL and TLS specifications that use anonymous Diffie-Hellman (i.e. those that have DH_anon in their symbolic name) are vulnerable to man-in-the-middle attacks. It is also recommended that ciphersuites that include MD5 (i.e. those that have MD5 in their symbolic name) be avoided, due to known security weaknesses of the MD5 algorithm. It is recommended that such ciphersuites be avoided.

The Profile recommends against the use of the following ciphersuites due to their lack of confidentiality services:

SSL_RSA_WITH_NULL_SHA
TLS_RSA_WITH_NULL_SHA
SSL_RSA_WITH_NULL_MD5
TLS_RSA_WITH_NULL_MD5

It is also recommended that ciphersuites that use 40 or 56 bit keys be avoided, due to their relative ease of compromise through brute-force attack.

3.2.4 Prohibited Ciphersuites

The Profile does not prohibit the use of any transport layer security ciphersuites, but careful thought should be given prior to the use of any ciphersuites discussed under "Discouraged ciphersuites".

4. SOAP Nodes and Messages

This section of the Basic Security Profile 1.1 incorporates the following specifications by reference, and defines extensibility points within them:

4.1 Security Policy

4.1.1 Out of Band Agreement

Partners in a message exchange must agree which elements must be signed and/or encrypted and which elements may be signed and/or encrypted and which security tokens must be present and may be present.

R3105 A SENDER MAY agree in an out of band fashion with a RECEIVER on required and allowed signed and/or encrypted message content and security tokens.

R3106 A RECEIVER MAY agree in an out of band fashion with a SENDER on required and allowed signed and/or encrypted message content and security tokens.

Some vendor platforms have strict implementation of what message content must be signed and/or encrypted and which security tokens must be present and which may be present. Other vendor platforms are more tolerant to receiving additional signed content in a message. The Profile allows for an out of band agreement between partners on how to address this issue.

4.2 SOAP Envelope

4.2.1 Secure Envelope Validity

The Envelope, Header, or Body elements must not be encrypted. Encrypting these elements would break the SOAP processing model and is therefore prohibited.

R5607 Any SECURE_ENVELOPE MUST still be a valid SOAP Envelope after SOAP Message Security, including encryption, is applied.

4.2.2 wsu:Id Attribute Value Uniqueness

One of the principles of the underlying specifications is that processing of messages should not require schema validation. However, without schema processing it is not possible to determine whether individual attributes are of type ID and must therefore be unique.

R3204 Any SECURE_ENVELOPE MUST NOT contain more than one element specifying the same wsu:Id attribute value.

Since verification of signatures typically requires dereferencing of elements based on ID attribute values, these values are required to be unique within a message.

4.3 Intermediary Processing

4.3.1 Removal of Headers

R3207 A SOAP intermediary INSTANCE MUST NOT remove or modify any HEADER_ELEMENT unless that SOAP intermediary is acting in the role specified by the S11:actor attribute of that HEADER_ELEMENT.

4.4 Basic Profile Clarification

The Basic Security Profile is an extension profile to the Basic Profile. This means it is consistent with the Basic Profile but profiles additional functionality - how to add conformant security features to the Basic Profile when needed.

As an extension of the Basic Profile, the Basic Security Profile is designed to support the addition of security functionality to SOAP messaging, in an interoperable manner. One example of such functionality is the confidentiality of selected SOAP header blocks and SOAP body elements and content through the use of OASIS Web Services Security encryption. The intent of such techniques is to change the nature of the SOAP message so that unintended parties cannot read such content. This means that the secured SOAP message is no longer obviously related to the original WSDL description, and is not intelligible without decryption. Other security mechanisms such as signatures may also modify the content of SOAP envelopes.

The Basic Profile includes requirements on the content of SOAP envelopes (or in Basic Profile 1.0 the format of SOAP messages). Testing conformance to these statements by using a "man-in-the-middle" interceptor as outlined in the WS-I Monitor Tool Functional Specification will not be possible if encryption has been applied to portions of the SOAP envelope and have not yet been decrypted. Even if interception is possible, some messages may have a different structure due to security.

Such SOAP messages still conform to the Basic Profile, since conformance to the Basic Profile means conformance once a receiver has reversed security changes introduced by a message sender. This is not obvious in some Basic Profile requirements, so this document further clarifies these requirements in the normative "Basic Profile Clarifications" section below.

It is helpful to visualize a SOAP message in light of a protocol layering model, such as the ISO seven layer protocol model [ Tanenbaum ]. This model shows how a protocol is in fact composed of different layers, and how to a given layer underlying layers are transparent. The implementation of a given protocol layer at an endpoint may be modeled as that implementation consuming a service of the underlying protocol layer, and providing a service to the layer above it. In this model no protocol layer need be aware of layers above or below it, making the layer implementations independent. This is illustrated in Figure 1.

Traditionally, protocol layers have been distinguished by the use of protocol enveloping, where the message at one layer is conveyed as the body in the next lower layer. The sender passes a message to the lower level protocol implementation that packages it in a protocol envelope and sends it to the corresponding layer in the receiver. The sender and receiver at this lower layer perform whatever processing is necessary for delivery according to the specification of that layer, and finally the receiver passes the message up to the peer of the sender.

SOAP Security may be viewed as a lower layer with respect to the more general SOAP web services application layer. Thus a SOAP sender may pass a SOAP message to a lower layer SOAP security implementation that applies encryption (for example), and sends the message to the destination SOAP Security layer, which removes the encryption before passing the message up to the peer SOAP web services application layer.

Thus a Basic Profile interceptor and compliance monitoring activity should logically occur at a receiver at the interface between the SOAP security implementation and SOAP web services application layer.

This section clarifies the BP1.0 (including Errata), BP1.1, SSBP1.0, and AP1.0 statements that might be unclear when SOAP Message Security is applied in compliance with the Basic Security Profile.

This section lists each possibly confusing BP1.0, BP1.1, SSBP1.0, and AP1.0 requirement and an associated statement to clarify that requirement in the context of the basic security profile.

When these clarifying statements include the phrase "reverse SOAP Message Security" it means to remove various impacts of applying SOAP Message Security that may have been applied since the MESSAGE (BP1.0) or ENVELOPE (BP 1.1) was originally created for that recipient according to the BP. This may mean decrypting relevant portions of the XML or removing XML Signature elements or making other reverse transformations as appropriate to the aspects of SOAP Message Security that were applied in the specific circumstance.

Not all security must be reversed, only that for the intended recipient, as applied to the BP compliant envelope before sent to that recipient.

4.4.1 BP Requirement R1029

This clarifies the Basic Profile's R1029 to reflect the fact that transmission of security related faults may increase the vulnerability to certain attacks and in some cases faults should not be transmitted.

R5814 Where the normal outcome of processing a SECURE_ENVELOPE would have resulted in the transmission of a SOAP Response, but rather a fault is generated instead, a RECEIVER MAY transmit a fault or silently discard the message.

4.4.2 BP Requirement R2301

bp10:R2301 states "The order of the elements in the soap:body of a MESSAGE MUST be the same as that of the wsdl:parts in the wsdl:message that describes it."

bp11:R2301 states "The order of the elements in the soap:body of an ENVELOPE MUST be the same as that of the wsdl:parts in the wsdl:message that describes it."

R5800 bp10:R2301 MUST be true after any SOAP Message Security has been reversed for the MESSAGE.

R5801 bp11:R2301 MUST be true after any SOAP Message Security has been reversed for the ENVELOPE.

4.4.3 BP Requirement R2710

bp10:R2710 states "The operations in a wsdl:binding in a DESCRIPTION MUST result in operation signatures that are different from one another."

bp11:R2710 states "The operations in a wsdl:binding in a DESCRIPTION MUST result in operation signatures that are different from one another."

R5802 bp10:R2710 MUST be true after SOAP Message Security processing has been reversed for the MESSAGE

R5803 bp11:R2710 MUST be true after SOAP Message Security processing has been reversed for the ENVELOPE

4.4.4 BP Requirement R2712

bp10:R2712 states "A document-literal binding MUST be serialized as a MESSAGE with a soap:Body whose child element is an instance of the global element declaration referenced by the corresponding wsdl:message part."

bp11:R2712 states "A document-literal binding MUST be serialized as an ENVELOPE with a soap:Body whose child element is an instance of the global element declaration referenced by the corresponding wsdl:message part."

R5804 bp10:R2712 MUST be true after any SOAP Message Security has been reversed for the MESSAGE

R5805 bp11:R2712 MUST be true after any SOAP Message Security has been reversed for the ENVELOPE

4.4.5 BP Requirement R2724

bp10:R2724 states "If an INSTANCE receives a message that is inconsistent with its WSDL description, it SHOULD generate a soap:Fault with a faultcode of 'Client', unless a 'MustUnderstand' or 'VersionMismatch' fault is generated."

bp11:R2724 states "If an INSTANCE receives an envelope that is inconsistent with its WSDL description, it SHOULD generate a soap:Fault with a faultcode of 'Client', unless a 'MustUnderstand' or 'VersionMismatch' fault is generated."

R5806 For bp10:R2724 "Inconsistent" MUST be taken to mean "Inconsistent after SOAP Message security has been reversed", for the MESSAGE

R5807 For bp11:R2724 "Inconsistent" MUST be taken to mean "Inconsistent after SOAP Message security has been reversed", for the ENVELOPE

4.4.6 BP Requirement R2725

bp10:R2725 states "If an INSTANCE receives a message that is inconsistent with its WSDL description, it MUST check for "VersionMismatch", "MustUnderstand" and "Client" fault conditions in that order."

bp11:R2725 states "If an INSTANCE receives an envelope that is inconsistent with its WSDL description, it MUST check for "VersionMismatch", "MustUnderstand" and "Client" fault conditions in that order."

R5808 With respect to bp10:R2725 the INSTANCE must check for consistency of the MESSAGE per BP 1.0 after reversing SOAP Message Security.

R5809 With respect to bp11:R2725 the INSTANCE must check for consistency of the ENVELOPE per BP 1.1 after reversing SOAP Message Security.

4.4.7 BP Requirement R2729

bp10:R2729 states "A MESSAGE described with an rpc-literal binding that is a response message MUST have a wrapper element whose name is the corresponding wsdl:operation name suffixed with the string 'Response'."

bp11:R2729 states "An ENVELOPE described with an rpc-literal binding that is a response MUST have a wrapper element whose name is the corresponding wsdl:operation name suffixed with the string 'Response'."

R5810 With respect to bp10:R2729 the verification of the wrapper element name of the MESSAGE must be performed after reversing SOAP Message Security.

R5811 With respect to bp11:R2729 the verification of the wrapper element name of the ENVELOPE must be performed after reversing SOAP Message Security.

4.4.8 BP Requirement R2738

bp10:R2738 states "A MESSAGE MUST include all soapbind:headers specified on a wsdl:input or wsdl:output of a wsdl:operation of a wsdl:binding that describes it.

bp11:R2738 states "An ENVELOPE MUST include all soapbind:headers specified on a wsdl:input or wsdl:output of a wsdl:operation of a wsdl:binding that describes it."

R5812 With respect to bp10:R2738 verification of a MESSAGE must occur after SOAP Message Security has been reversed.

R5813 With respect to bp11:R2738 verification of an ENVELOPE must occur after SOAP Message Security has been reversed.

5. SecurityHeaders

5.1 Processing Order

Web Services Security: SOAP Message Security defines the order for processing elements within wsse:Security headers. The Profile provides the following guidance:

5.1.1 In Order of Appearance

Messages may be signed and encrypted, potentially by multiple entities signing and encrypting overlapping elements. A signature applied before encryption has different security properties than encryption applied before a signature. Determining which security properties should be used requires an out-of-band agreement.

With signature before encryption, the signer is known to have created or vouched for the plaintext data. It is not known to the receiver whether the signer performed the encryption. The potential exists for the identity of the signer to remain confidential except to the receiver by encryption of the signature and signer's security token.

With encryption before signature, the signer is known to have created or vouched for the ciphertext data, but it is not known whether the signer was aware of the plaintext. It is known that the signer was aware that the data was encrypted and intended to be delivered to the receiver.

R3212 Any SIGNATURE, ENCRYPTED_KEY, and ENC_REFERENCE_LIST elements MUST be ordered within a SECURITY_HEADER so a receiver will get the correct result by processing the elements in the order they appear.

As signature and encryption elements are added to a security header they must be ordered in a way that ensures that if a receiver of the message processing the elements in the order they appear they will achieve the correct result.

5.2 SOAP Actor Attribute

SOAP defines an actor attribute for use in SOAP headers. The Profile places the following constraints on its use with Security headers:

5.2.1 Avoid Target Ambiguity

The actor attribute allows a security header to be targeted to a specific processing component or node.

R3206 Any SOAP_HEADER MUST NOT contain more than one SECURITY_HEADER with the actor attribute omitted.

R3210 Any SOAP_HEADER MUST NOT contain more than one SECURITY_HEADER with the same actor attribute value.

Correct security header processing is order dependent. Eliminating potential ambiguity caused by ordering dependencies between headers targeted to the same actor eliminates complexity.

6. Timestamps

Web Services Security: SOAP Message Security defines a Timestamp element for use in SOAP messages. The Profile places the following constraints on its use:

6.1 Placement

6.1.1 Not More Than One per Security Header

R3227 A SECURITY_HEADER MUST NOT contain more than one TIMESTAMP.

6.2 Content

6.2.1 Exactly One Created per Timestamp

The wsu:Created element represents the creation time of the security semantics.

R3203 A TIMESTAMP MUST contain exactly one CREATED.

This element is REQUIRED and can only be specified once in a Timestamp element. Within the SOAP processing model, creation is the instant that the Infoset is serialized for transmission.

INCORRECT:

<!-- This example is incorrect because the wsu:Timestamp element is missing a wsu:Created child element -->
<wsu:Timestamp wsu:Id="timestamp">
   <wsu:Expires>2001-10-13T09:00:00Z</wsu:Expires>
</wsu:Timestamp>

CORRECT:

<wsu:Timestamp wsu:Id="timestamp">
   <wsu:Created>2001-09-13T08:42:00Z</wsu:Created>
   <wsu:Expires>2001-10-13T09:00:00Z</wsu:Expires>
</wsu:Timestamp>

6.2.2 Not More Than One Expires per Timestamp

R3224 Any TIMESTAMP MUST NOT contain more than one EXPIRES.

6.2.3 Created Precedes Expires in Timestamp

A timestamp may optionally contain an expires element.

R3221 Any TIMESTAMP containing an EXPIRES MUST contain a CREATED that precedes its sibling EXPIRES.

Preventing multiple expires elements and enforcing the order of elements reduces complexity.

6.2.4 Timestamp Contains Nothing Other Than Create and Expires

R3222 Any TIMESTAMP MUST NOT contain anything other than CREATED or EXPIRES elements.

6.3 Constraints on Created and Expires

6.3.1 Value Precision to Milliseconds

The underlying specifications do not limit the resolution of timestamp values.

R3220 Any CREATED SHOULD NOT contain a seconds value with more than three digits to the right of the decimal (milliseconds).

R3229 Any EXPIRES SHOULD NOT contain a seconds value with more than three digits to the right of the decimal (milliseconds).

Since implementations have practical limits on resolution of time values the Profile requires a reasonable processing capability.

6.3.2 Leap Second Values Prohibited

Leap seconds are allowed by the underlying specifications.

R3213 Any CREATED containing second values MUST specify seconds values less than 60.

R3215 Any EXPIRES containing second values MUST specify seconds values less than 60.

Leap second processing is complex and error prone. The Profile disallows specification of leap seconds.

6.3.3 ValueType Attribute Prohibited

The underlying specifications allow for the specification of a timestamp ValueType.

R3225 Any CREATED MUST NOT include a ValueType attribute.

R3226 Any EXPIRES MUST NOT include a ValueType attribute.

There is no specified set of values for the ValueType attribute so the Basic Security Profile 1.1 disallows its use.

6.3.4 UTC Format Mandatory

The underlying specifications allow for a variety of timestamp formats.

R3217 Any CREATED MUST contain time values in UTC format as specified by the XML Schema type (dateTime).

R3223 Any EXPIRES MUST contain time values in UTC format as specified by the XML Schema type (dateTime).

Limiting timestamp values to UTC time eliminates complexity.

7. Security Token References

7.1 Content

7.1.1 Exactly One SecurityTokenReference Child Element

Web Services Security: SOAP Message Security allows for a single SecurityTokenReference to include multiple reference mechanisms to the same security token. The Profile requires that only one be used.

R3061 A SECURITY_TOKEN_REFERENCE MUST provide exactly one token reference.

Restricting the number of reference mechanisms reduces complexity.

7.2 TokenType Attribute

7.2.1 Value of TokenType Attribute

R3074 Any wsse:11:TokenType Attribute in a SECURITY_TOKEN_REFERENCE MUST specify a value that a TokenType specified by a security token profile for the referenced SECURITY_TOKEN.

Restricting the number of reference mechanisms reduces complexity.

7.3 Direct References

7.3.1 Direct Reference to Security Token Reference Prohibited

The only proper way to refer to an INTERNAL_SECURITY_TOKEN by Direct Reference (even one inside a STR_EMBEDDED) is to refer directly to the INTERNAL_SECURITY_TOKEN.

R3057 Any STR_REFERENCE MUST NOT reference a SECURITY_TOKEN_REFERENCE.

R3064 Any STR_REFERENCE MUST NOT reference an STR_EMBEDDED.

INCORRECT:

<!-- This example is incorrect because the second wsse:SecurityTokenReference element refers to the
     wsse:SecurityTokenReference with an wsu:Id of TheFirstSTR  -->
<wsse:BinarySecurityToken wsu:Id='SomeCert'
                          ValueType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-x509-token-profile-1.0#X509v3"
                          EncodingType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-soap-message-security-1.0#Base64Binary">
lui+Jy4WYKGJW5xM3aHnLxOpGVIpzSg4V486hHFe7sHET/uxxVBovT7JV1A2RnWSWkXm9jAEdsm/...
</wsse:BinarySecurityToken>
<wsse:SecurityTokenReference wsu:Id="TheFirstSTR">
   <wsse:Reference URI='#SomeCert'
                   ValueType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-x509-token-profile-1.0#X509v3" />
</wsse:SecurityTokenReference>
<wsse:SecurityTokenReference>
   <wsse:Reference URI='#TheFirstSTR'
                   ValueType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-x509-token-profile-1.0#X509v3" />
</wsse:SecurityTokenReference>

CORRECT:

<wsse:SecurityTokenReference>
   <wsse:Embedded wsu:Id="TheEmbeddedElementAroundSomeCert">
      <wsse:BinarySecurityToken wsu:Id='SomeCert'
                                ValueType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-x509-token-profile-1.0#X509v3"
                                EncodingType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-soap-message-security-1.0#Base64Binary">
lui+Jy4WYKGJW5xM3aHnLxOpGVIpzSg4V486hHFe7sHET/uxxVBovT7JV1A2RnWSWkXm9jAEdsm/...
      </wsse:BinarySecurityToken>
   </wsse:Embedded>
</wsse:SecurityTokenReference>
<wsse:SecurityTokenReference>
   <wsse:Reference URI='#SomeCert'
                   ValueType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-x509-token-profile-1.0#X509v3" />
</wsse:SecurityTokenReference>

7.3.2 Reference/@ValueType Attribute Mandatory

The ValueType attribute in a security token reference is optional and has no accepted default value. This creates ambiguity between implementations when it is missing. Furthermore, security tokens similarly have ValueType attributes, which creates the possibility of contradiction between the reference and the token. There is no accepted processing model to resolve this.

R3059 Any STR_REFERENCE MUST specify a ValueType attribute with the exception of STR_REFERENCE pointing to a SAML_V2_0_TOKEN or a KERBEROS_TOKEN or an ENCRYPTED_KEY_TOKEN.

R3058 Any STR_REFERENCE ValueType attribute MUST contain a value for the referenced SECURITY_TOKEN specified by the corresponding security token profile.

Requiring that Security Token References carry a ValueType attribute makes it clear what type of security token is being referenced enabling security token specific reference mechanisms and aiding in error detection.

7.3.3 Reference/@URI Attribute Mandatory

Web Services Security: SOAP Message Security treats the URI attribute as optional allowing for extensibility in the reference mechanism. However, the only fully specified mechanism which uses the Reference element requires a URI value.

R3062 Any STR_REFERENCE MUST specify a URI attribute.

Eliminating underspecified functionality removes complexity.

7.4 Key Name References

7.4.1 Key Name References Prohibited

Key Name References may be ambiguous.

R3027 Any SECURITY_TOKEN_REFERENCE MUST NOT contain an STR_KEY_NAME.

In any case where a security token would be referred to by Key Name, it would also be possible to refer to it by a more efficient and/or less ambiguous mechanism (e.g. Direct, Key Identifier and/or Issuer and Serial Number). Thus, the Basic Security Profile 1.1 disallows the use of Key Name References.

INCORRECT:

<!-- This example is incorrect because it uses a ds:KeyName element to refer to an X.509 certificate  -->
<wsse:SecurityTokenReference>
   <ds:KeyName>CN=Security WG, OU=BSP, O=WS-I, C=US</ds:KeyName>
</wsse:SecurityTokenReference>

7.5 Key Identifier References

7.5.1 KeyIdentifier/@ValueType Attribute Mandatory

Having an explicit ValueType removes ambiguity about the format of the KeyIdentifier. The Profile restricts the value to that specified in the security token profile that is associated with the security token. The ValueType attribute in a KeyIdentifier is optional. This can cause ambiguity when it is not explicitly stated. Furthermore, interoperability is discouraged if a ValueType is specified but does not correspond to the value associated with that token as stated in its security token profile.

R3054 Any STR_KEY_IDENTIFIER MUST specify a ValueType attribute.

R3063 Any STR_KEY_IDENTIFIER ValueType attribute MUST contain a value specified within the security token profile associated with the referenced SECURITY_TOKEN.

Having an explicit ValueType removes ambiguity about the format of the KeyIdentifier and enhances processing efficiency. The Profile restricts the value to that specified in the security token profile that is associated with the security token.

INCORRECT:

<!-- This example is incorrect because the wsse:KeyIdentifier element is missing a ValueType attribute -->
<wsse:SecurityTokenReference>
   <wsse:KeyIdentifier EncodingType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-soap-message-security-1.0#Base64Binary">
      MIGfMa0GCSq
   </wsse:KeyIdentifier>
</wsse:SecurityTokenReference>

CORRECT:

<wsse:SecurityTokenReference>
   <wsse:KeyIdentifier EncodingType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-soap-message-security-1.0#Base64Binary"
                       ValueType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-x509-token-profile-1.0#X509SubjectKeyIdentifier" >
      MIGfMa0GCSq
   </wsse:KeyIdentifier>
</wsse:SecurityTokenReference>

7.5.2 KeyIdentifier/@EncodingType Attribute Mandatory

Base64Binary is the only encoding type specified by Web Services Security: SOAP Message Security. Explicit specification of attribute values simplifies XML processing requirements and as a general principle the Basic Security Profile 1.1 requires that attributes be explicitly specified rather than relying on default values.

R3070 Any STR_KEY_IDENTIFIER that refers to a SECURITY_TOKEN other than a SAML_TOKEN MUST specify an EncodingType attribute.

R3071 Any STR_KEY_IDENTIFIER EncodingType attribute MUST have a value of "http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-soap-message-security-1.0#Base64Binary".

A wsse:KeyIdentifier may specify its encoding type. The Profile restricts the encoding type to Base64Binary and requires its explicit specification.

INCORRECT:

<!-- This example is incorrect because the wsse:KeyIdentifier element is missing an EncodingType attribute -->
<wsse:SecurityTokenReference>
   <wsse:KeyIdentifier ValueType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-x509-token-profile-1.0#X509SubjectKeyIdentifier" >
      MIGfMa0GCSq
   </wsse:KeyIdentifier>
</wsse:SecurityTokenReference>

CORRECT:

<wsse:SecurityTokenReference>
   <wsse:KeyIdentifier EncodingType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-soap-message-security-1.0#Base64Binary"
                       ValueType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-x509-token-profile-1.0#X509SubjectKeyIdentifier" >
      MIGfMa0GCSq
   </wsse:KeyIdentifier>
</wsse:SecurityTokenReference>

7.6 Embedded References

7.6.1 Embedded Content

Embedded elements may potentially contain multiple elements, creating ambiguity about which token should be processed. Furthermore, elements may be of a type that is not defined within a security token profile. This can cause problems with interoperability.

R3060 Any STR_EMBEDDED MUST contain only a single child element which is an INTERNAL_SECURITY_TOKEN.

In order to reduce ambiguity surrounding which token to process, the Basic Security Profile 1.1 restricts embedded security tokens to contain exactly one security token element. It also restricts tokens to those defined in a token profile; this establishes a defined scope of profiles and thus allows for interoperability between implementations.

INCORRECT:

<!-- This example is incorrect because the wsse:Embedded element has multiple element children -->
<wsse:SecurityTokenReference>
   <wsse:Embedded wsu:Id="TheEmbeddedElementAroundSomeCerts">
      <wsse:BinarySecurityToken wsu:Id='SomeCert'
                                ValueType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-x509-token-profile-1.0#X509v3"
                                EncodingType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-soap-message-security-1.0#Base64Binary">
lui+Jy4WYKGJW5xM3aHnLxOpGVIpzSg4V486hHFe7sHET/uxxVBovT7JV1A2RnWSWkXm9jAEdsm/...
      </wsse:BinarySecurityToken>
      <wsse:BinarySecurityToken wsu:Id='SomeOtherCert'
                                ValueType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-x509-token-profile-1.0#X509v3"
                                EncodingType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-soap-message-security-1.0#Base64Binary">
lui+Jy4WYKGJW5xM3aHnLxOpGVIpzSg4V486hHFe7sHET/uxxVBovT7JV1A2RnWSWkXm9jAEdsm/...
      </wsse:BinarySecurityToken>
   </wsse:Embedded>
</wsse:SecurityTokenReference>

CORRECT:

<wsse:SecurityTokenReference>
   <wsse:Embedded wsu:Id="TheEmbeddedElementAroundSomeCert">
      <wsse:BinarySecurityToken wsu:Id='SomeCert'
                                ValueType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-x509-token-profile-1.0#X509v3"
                                EncodingType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-soap-message-security-1.0#Base64Binary">
lui+Jy4WYKGJW5xM3aHnLxOpGVIpzSg4V486hHFe7sHET/uxxVBovT7JV1A2RnWSWkXm9jAEdsm/...
      </wsse:BinarySecurityToken>
   </wsse:Embedded>
</wsse:SecurityTokenReference>

7.6.2 Embedded Token Format

Using a single consistent format for security tokens, regardless of reference mechanism, ensures consistent processing.

R3025 Any INTERNAL_SECURITY_TOKEN contained in an STR_EMBEDDED MUST be in the same format as if it were a child of a SECURITY_HEADER.

INCORRECT:

<!-- This example is incorrect because the wsse:Embedded element carries the data for the X.509 certificate
     directly rather than as a wsse:BinarySecurityToken element  -->
<wsse:SecurityTokenReference>
   <wsse:Embedded wsu:Id="SomeCert">
lui+Jy4WYKGJW5xM3aHnLxOpGVIpzSg4V486hHFe7sHET/uxxVBovT7JV1A2RnWSWkXm9jAEdsm/...
   </wsse:Embedded>
</wsse:SecurityTokenReference>

CORRECT:

<wsse:SecurityTokenReference>
   <wsse:Embedded wsu:Id="TheEmbeddedElementAroundSomeCert">
      <wsse:BinarySecurityToken wsu:Id='SomeCert'
                                ValueType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-x509-token-profile-1.0#X509v3"
                                EncodingType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-soap-message-security-1.0#Base64Binary">
lui+Jy4WYKGJW5xM3aHnLxOpGVIpzSg4V486hHFe7sHET/uxxVBovT7JV1A2RnWSWkXm9jAEdsm/...
      </wsse:BinarySecurityToken>
   </wsse:Embedded>
</wsse:SecurityTokenReference>

7.6.3 Security Token Reference in Embedded Prohibited

Embedded elements can contain multiple binary security token elements, which creates ambiguity about which token should be processed. Furthermore, the security token may be a type that is not defined within a security token profile. This can cause problems with interoperability. Using a single consistent format for security tokens, regardless of reference mechanism, ensures consistent processing. Embedded security tokens can potentially chain to other security tokens, which adds complexity to processing and discourages interoperability.

R3056 Any STR_EMBEDDED MUST NOT contain a wsse:SecurityTokenReference child element.

INCORRECT:

<!-- This example is incorrect because the wsse:Embedded element contains a wsse:SecurityTokenReference element -->
<wsse:SecurityTokenReference>
   <wsse:Embedded wsu:Id="TheEmbeddedElementAroundSomeSTR">
      <wsse:SecurityTokenReference>
         <wsse:Reference URI='#SomeCert'
                         ValueType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-x509-token-profile-1.0#X509v3" />
      </wsse:SecurityTokenReference>
   </wsse:Embedded>
</wsse:SecurityTokenReference>

7.7 Internal References

7.7.1 Direct or Embedded References Where Possible

Web Services Security: SOAP Message Security provides a list of reference mechanisms in preferred order (i.e., most specific to least specific). This adds ambiguity and complexity, which discourages interoperability.

R3022 Any SECURITY_TOKEN_REFERENCE that references an INTERNAL_SECURITY_TOKEN which has a wsu:Id attribute MUST contain an STR_REFERENCE or STR_EMBEDDED.

The recommendation does not allow the use of Key Identifier and Key Name references due to possible ambiguities. Direct References and Embedded References are to be used instead of these. This reduces complexity and improves interoperability.

INCORRECT:

<!-- This example is incorrect because it refers to a wsse:BinarySecurityToken element which specifies a wsu:id
     attribute using a wsse:KeyIdentifier element rather than a wsse:Reference or wsse:Embedded element -->
<wsse:Security xmlns:wsse='http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd'
               xmlns:wsu='http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd'
               xmlns:xenc='http://www.w3.org/2001/04/xmlenc#'
               xmlns:ds='http://www.w3.org/2000/09/xmldsig#' >
   <wsse:BinarySecurityToken wsu:Id='SomeCert'
                             ValueType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-x509-token-profile-1.0#X509v3"
                             EncodingType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-soap-message-security-1.0#Base64Binary">
lui+Jy4WYKGJW5xM3aHnLxOpGVIpzSg4V486hHFe7sHET/uxxVBovT7JV1A2RnWSWkXm9jAEdsm/...
   </wsse:BinarySecurityToken>
   <wsse:SecurityTokenReference>
      <wsse:KeyIdentifier EncodingType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-soap-message-security-1.0#Base64Binary"
                          ValueType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-x509-token-profile-1.0#X509SubjectKeyIdentifier">
         MIGfMa0GCSq
      </wsse:KeyIdentifier>
   </wsse:SecurityTokenReference>
</wsse:Security>

CORRECT:

<wsse:Security xmlns:wsse='http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd'
               xmlns:wsu='http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd'
               xmlns:xenc='http://www.w3.org/2001/04/xmlenc#'
               xmlns:ds='http://www.w3.org/2000/09/xmldsig#' >
   <wsse:BinarySecurityToken wsu:Id='SomeCert'
                             ValueType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-x509-token-profile-1.0#X509v3"
                             EncodingType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-soap-message-security-1.0#Base64Binary">
lui+Jy4WYKGJW5xM3aHnLxOpGVIpzSg4V486hHFe7sHET/uxxVBovT7JV1A2RnWSWkXm9jAEdsm/...
   </wsse:BinarySecurityToken>
   <wsse:SecurityTokenReference>
      <wsse:Reference URI='#SomeCert'
                      ValueType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-x509-token-profile-1.0#X509v3" />
   </wsse:SecurityTokenReference>
</wsse:Security>

CORRECT:

<wsse:Security xmlns:wsse='http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd'
               xmlns:wsu='http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd'
               xmlns:xenc='http://www.w3.org/2001/04/xmlenc#'
               xmlns:ds='http://www.w3.org/2000/09/xmldsig#' >
   <wsse:SecurityTokenReference>
      <wsse:Embedded wsu:Id="TheEmbeddedElementAroundSomeCert">
         <wsse:BinarySecurityToken wsu:Id='SomeCert'
                                   ValueType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-x509-token-profile-1.0#X509v3"
                                   EncodingType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-soap-message-security-1.0#Base64Binary">
lui+Jy4WYKGJW5xM3aHnLxOpGVIpzSg4V486hHFe7sHET/uxxVBovT7JV1A2RnWSWkXm9jAEdsm/...
         </wsse:BinarySecurityToken>
      </wsse:Embedded>
   </wsse:SecurityTokenReference>
</wsse:Security>

7.7.2 Direct Preferred to Embedded References

Since multiple security elements may reference a single security token and processing of those elements may result in the removal of the element, consistent use of direct rather than embedded references simplifies processing. Direct references are encouraged, embedded references are discouraged.

R3023 Any SECURITY_TOKEN_REFERENCE that references an INTERNAL_SECURITY_TOKEN that is referenced several times SHOULD contain an STR_REFERENCE rather than an STR_EMBEDDED.

The Profile encourages the consistent use of Direct Reference to security tokens.

INCORRECT:

<!-- This example is incorrect because it uses a wsse:Embedded element for the wsse:BinarySecurityToken
     with the wsu:Id of SomeCert. It is assumed that this token is referred to from several places elsewhere
     in the SOAP envelope (not shown)  -->
<wsse:Security xmlns:wsse='http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd'
               xmlns:wsu='http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd'
               xmlns:xenc='http://www.w3.org/2001/04/xmlenc#'
               xmlns:ds='http://www.w3.org/2000/09/xmldsig#' >
   <wsse:SecurityTokenReference>
      <wsse:Embedded wsu:Id="TheEmbeddedElementAroundSomeCert">
         <wsse:BinarySecurityToken wsu:Id='SomeCert'
                                   ValueType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-x509-token-profile-1.0#X509v3"
                                   EncodingType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-soap-message-security-1.0#Base64Binary">
lui+Jy4WYKGJW5xM3aHnLxOpGVIpzSg4V486hHFe7sHET/uxxVBovT7JV1A2RnWSWkXm9jAEdsm/...
         </wsse:BinarySecurityToken>
      </wsse:Embedded>
   </wsse:SecurityTokenReference>
</wsse:Security>

CORRECT:

<wsse:Security xmlns:wsse='http:

Basic Security Profile Version 1.1

Working Group Approval Draft

2007-02-20

Abstract

Status of this Document

Notice

Feedback

Table of Contents

1. Introduction

1.1 Guiding Principles

2. Document Conventions

2.1 Security Considerations

2.2 Notational Conventions

2.3 Profile Identification and Versioning

3 Profile Conformance

3.1 Conformance Requirements

3.2 Conformance Targets

3.3 Conformance Scope

3.4 Claiming Conformance

3. Transport Layer Mechanisms

3.1 TLS and SSL Versions

3.1.1 SSL 2.0 Prohibited

3.2 TLS and SSL Ciphersuites

3.2.1 Mandatory Ciphersuites

3.2.2 Recommended Ciphersuites

3.2.3 Discouraged Ciphersuites

3.2.4 Prohibited Ciphersuites

4. SOAP Nodes and Messages

4.1 Security Policy

4.1.1 Out of Band Agreement

4.2 SOAP Envelope

4.2.1 Secure Envelope Validity

4.2.2 wsu:Id Attribute Value Uniqueness

4.3 Intermediary Processing

4.3.1 Removal of Headers

4.4 Basic Profile Clarification

4.4.1 BP Requirement R1029

4.4.2 BP Requirement R2301

4.4.3 BP Requirement R2710

4.4.4 BP Requirement R2712

4.4.5 BP Requirement R2724

4.4.6 BP Requirement R2725

4.4.7 BP Requirement R2729

4.4.8 BP Requirement R2738

5. SecurityHeaders

5.1 Processing Order

5.1.1 In Order of Appearance

5.2 SOAP Actor Attribute

5.2.1 Avoid Target Ambiguity

6. Timestamps

6.1 Placement

6.1.1 Not More Than One per Security Header

6.2 Content

6.2.1 Exactly One Created per Timestamp

6.2.2 Not More Than One Expires per Timestamp

6.2.3 Created Precedes Expires in Timestamp

6.2.4 Timestamp Contains Nothing Other Than Create and Expires

6.3 Constraints on Created and Expires

6.3.1 Value Precision to Milliseconds

6.3.2 Leap Second Values Prohibited

6.3.3 ValueType Attribute Prohibited

6.3.4 UTC Format Mandatory

7. Security Token References

7.1 Content

7.1.1 Exactly One SecurityTokenReference Child Element

7.2 TokenType Attribute

7.2.1 Value of TokenType Attribute

7.3 Direct References

7.3.1 Direct Reference to Security Token Reference Prohibited

7.3.2 Reference/@ValueType Attribute Mandatory

7.3.3 Reference/@URI Attribute Mandatory

7.4 Key Name References

7.4.1 Key Name References Prohibited

7.5 Key Identifier References

7.5.1 KeyIdentifier/@ValueType Attribute Mandatory

7.5.2 KeyIdentifier/@EncodingType Attribute Mandatory

7.6 Embedded References

7.6.1 Embedded Content

7.6.2 Embedded Token Format

7.6.3 Security Token Reference in Embedded Prohibited