Basic Security Profile - Version 1.0 (WGD)

This document defines the WS-I Basic Security Profile 1.0, 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 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.

1. Introduction

This document defines the WS-I Basic Security Profile 1.0 (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.0 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.0.

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

Each subsequent section addresses a component of the Basic Security Profile 1.0, 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.0, 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.0 makes a number of security recommendations intended to improve security. Security recommendations are presented as follows:

where "nnnn" is replaced by a number that is unique among the security recommendations in the Basic Security Profile 1.0, thereby forming a unique security recommendation identifier. Each security recommendation contains a SHOULD 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.0 (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.0, 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.

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.0. 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.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.

3 Profile Conformance

Conformance to the Basic Security Profile 1.0 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.0 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.0 and its referenced specifications contradict each other, the Basic Security Profile 1.0'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.0 are considered authoritative for the purposes of determining conformance.

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

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

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.0 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.0 is "http://ws-i.org/profiles/basic-security/core/1.0" , with the following exceptions, which are associated with specific sections:

If a claim of conformance is made as described in CCAM to BSP 1.0 ("http://ws-i.org/profiles/basic-security/core/1.0"), 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/transport/1.0") can be used in isolation or in combination with other conformance URIs.

4. Transport Layer Security

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

4.1 SSL and TLS

The following specifications (or sections thereof) are referred to in this section of the Basic Security Profile 1.0:

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

4.1.1 Use of SSL 2.0

SSL 2.0 has known security issues and all current implementations of HTTP/S support more recent protocols. Therefore the Basic Security Profile 1.0 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

5. SOAP Message Security

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

5.1 Security Tokens

The following specifications (or sections thereof) are referred to in this section of the Basic Security Profile 1.0:

In some areas the Basic Security Profile allows limited flexibility and extensibility in the application of security to messages. Some agreement between the SENDER and RECEIVER over which mechanisms and choices should be used for message exchanges is necessary. Since no security policy description language or negotiation mechanism is in scope for the Basic Security Profile, some out of band agreement must be reached for which security tokens should be used.

The Basic Security Profile 1.0 places the following constraints on the use of Security Tokens:

5.1.1 Binary Security Token EncodingType Attribute

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.0 requires that attributes be explicitly specified rather than relying on default values.

R3029 A SECURITY_TOKEN named wsse:BinarySecurityToken MUST specify an EncodingType attribute.

R3030 An EncodingType attribute of a SECURITY_TOKEN named wsse:BinarySecurityToken MUST have a value of "http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-soap-message-security-1.0#Base64Binary".

A BinarySecurityToken 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:BinarySecurityToken element is missing an EncodingType attribute -->

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

CORRECT:

<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>

5.1.2 Binary Security Token ValueType Attribute

There is no appropriate default for ValueType so the Basic Security Profile 1.0 mandates that an explicit value be provided.

R3031 A SECURITY_TOKEN named wsse:BinarySecurityToken MUST specify a ValueType attribute.

R3032 A ValueType attribute of a SECURITY_TOKEN named wsse:BinarySecurityToken MUST have a value specified by the related security token profile.

R3033 A SECURITY_TOKEN named wsse:BinarySecurityToken containing a single X.509 Certificate MUST specify a ValueType attribute with the value "http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-x509-token-profile-1.0#X509v3".

Web Services Security: SOAP Message Security allows for a BinarySecurityToken to optionally specify its ValueType. The Profile restricts the ValueType to one of those specified by a security token profile and requires its specification.

INCORRECT:

<!-- This example is incorrect because the wsse:BinarySecurityToken element is missing a ValueType attribute -->

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

INCORRECT:

<!-- This example is incorrect because the ValueType attribute on the wsse:BinarySecurityToken element has an incorrect value. -->

<wsse:BinarySecurityToken wsu:Id='SomeCert'
                          ValueType="http://www.mta.org/NYC#SubwayToken"
                          EncodingType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-soap-message-security-1.0#Base64Binary">
lui+Jy4WYKGJW5xM3aHnLxOpGVIpzSg4V486hHFe7sHET/uxxVBovT7JV1A2RnWSWkXm9jAEdsm/...
</wsse:BinarySecurityToken>

CORRECT:

<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>

5.2 SecurityTokenReferences

The following specifications (or sections thereof) are referred to in this section of the Basic Security Profile 1.0:

5.2.1 Internal References

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 When a SECURITY_TOKEN_REFERENCE references an INTERNAL_SECURITY_TOKEN which has a wsu:Id attribute, the reference MUST use either a Direct Reference or an Embedded Reference.

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>

5.2.2 Shorthand XPointer References

Constraining the number of referencing mechanisms reduces complexity and thus improves interoperability. The wsse:BinarySecurityToken has a wsu:Id attribute allowing references to this token to use the relatively efficient and unambiguous Shorthand XPointer Reference mechanism.

R5204 When a SECURITY_TOKEN_REFERENCE uses a Direct Reference to an INTERNAL_SECURITY_TOKEN, it MUST use a Shorthand XPointer Reference.

The Profile requires the use of Shorthand XPointer Reference to ensure that the URI efficiently references the correct token.

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>
 <xenc:EncryptedKey>
   <xenc:EncryptionMethod Algorithm='http://www.w3.org/2001/04/xmlenc#rsa-1_5' />
   <ds:KeyInfo>
    <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>
   </ds:KeyInfo>
   <xenc:CipherData>
     <xenc:CipherValue>
       XZEEVABD3L9G+VNTCDiDTE7WB1a4kILtz5f9FT747eE=       
     </xenc:CipherValue>
   </xenc:CipherData>
 </xenc:EncryptedKey>
</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#' >
 <rel:license xmlns:rel='urn:mpeg:mpeg21:2003:01-REL-R-NS'
              wsu:Id='SomeLic' 
              licenseId='uuid:3D680C71-177B-40cc-84C1-123B02503524' >
 . . .
 </rel:license>
 <ds:Signature>
   . . .
   <ds:KeyInfo>
    <wsse:SecurityTokenReference>
     <wsse:Reference
       URI='#SomeLic'
       ValueType="http://docs.oasis-open.org/wss/2004/##/oasis-####-wss-REL-token-profile-1.0#license" />
    </wsse:SecurityTokenReference>
   </ds:KeyInfo>
 </ds:Signature>
</wsse:Security>

5.2.3 References to Preceding Security Tokens

Security token references are intended to provide access to security tokens residing anywhere in a document. However, token placement can have a significant affect on processing efficiency when the document is processed in a stream-oriented fashion. For example, resolving a forward reference to a token may require significant subsequent document parsing that could otherwise be eliminated. This need to satisfy random access to security tokens adds complexity to implementations that works against interoperability.

R5205 An INTERNAL_SECURITY_TOKEN that is not an embedded security token MUST precede the first SECURITY_TOKEN_REFERENCE that references it.

Ensuring that a security token element appears before it is referenced, when processing in document order, means that implementations have access to the token content referenced from a wsse:SecurityTokenReference element when it is needed to verify a signature or perform decryption.

INCORRECT:

<!-- This example is incorrect because the wsse:BinarySecurityToken with the wsu:Id of SomeCert appears after it is 
     referenced from within the xenc:EncryptedKey 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#' >
 <xenc:EncryptedKey>
   <xenc:EncryptionMethod Algorithm='http://www.w3.org/2001/04/xmlenc#rsa-1_5' />
   <ds:KeyInfo>
     <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>
   </ds:KeyInfo>
   <xenc:CipherData>
     <xenc:CipherValue>
       XZEEVABD3L9G+VNTCDiDTE7WB1a4kILtz5f9FT747eE=       
     </xenc:CipherValue>
   </xenc:CipherData>
 </xenc:EncryptedKey>
 <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: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>
 <xenc:EncryptedKey>
   <xenc:EncryptionMethod Algorithm='http://www.w3.org/2001/04/xmlenc#rsa-1_5' />
   <ds:KeyInfo>
     <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>
   </ds:KeyInfo>
   <xenc:CipherData>
     <xenc:CipherValue>
       XZEEVABD3L9G+VNTCDiDTE7WB1a4kILtz5f9FT747eE=       
     </xenc:CipherValue>
   </xenc:CipherData>
 </xenc:EncryptedKey>
</wsse:Security>

5.2.4 Direct Preferred to Embedded for Internal 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 Each SECURITY_TOKEN_REFERENCE that refers to an INTERNAL_SECURITY_TOKEN that is referenced several times SHOULD be a direct reference rather than an embedded reference.

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://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>

5.2.5 Direct Required When Possible for External References

Since multiple security elements may reference a single external security token, consistent use of direct references simplifies processing. Direct references are encouraged.

R3024 When a SECURITY_TOKEN_REFERENCE references an EXTERNAL_SECURITY_TOKEN that can be referred to using a Direct Reference, a Direct Reference MUST be used.

The Profile encourages the use of Direct Reference in order to minimize ambiguity.

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:Reference URI='http://www.ws-i.org/CertStore/Examples/BSP.PEM'
                      ValueType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-x509-token-profile-1.0#X509v3" />
   </wsse:SecurityTokenReference>
</wsse:Security>

5.2.6 Format of Embedded References

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

R3025 When a wsse:Embedded element in a SECURITY_TOKEN_REFERENCE is used to specify an INTERNAL_SECURITY_TOKEN, its format MUST be the same as if the token 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>

5.2.7 Key Identifier for External References

Web Services Security: SOAP Message Security provides a list of reference mechanisms in preferred order (i.e., most specific to least specific). Direct References are prefered, but when they cannot be used Key Identifier or Issuer and Serial Number is required.

R3026 When a SECURITY_TOKEN_REFERENCE references an EXTERNAL_SECURITY_TOKEN that cannot be referred to using a Direct Reference but can be referred to using a Key Identifier or ds:X509Data/ds:X509IssuerSerial, a Key Identifier or ds:X509Data/ds:X509IssuerSerial MUST be used.

In the event that Direct References are not possible, the Basic Security Profile 1.0 encourages the usage of mechanisms that are most likely to be unique.

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>

CORRECT:

<wsse:SecurityTokenReference>
   <ds:X509Data>
      <ds:X509IssuerSerial>
         <ds:X509IssuerName>CN=Security WG, OU=BSP, O=WS-I, C=US</ds:X509IssuerName>
         <ds:X509SerialNumber>54A4E9</ds:X509SerialNumber>
      </ds:X509IssuerSerial>
   </ds:X509Data>
</wsse:SecurityTokenReference>

5.2.8 Key Name References Prohibited

Key Name References may be ambiguous.

R3027 A SECURITY_TOKEN_REFERENCE MUST NOT use a Key Name to reference a SECURITY_TOKEN.

In any case where a security token would be refered 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.0 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>

5.2.9 KeyIdentifier/@ValueType Attribute

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 A wsse:KeyIdentifier element in a SECURITY_TOKEN_REFERENCE MUST specify a ValueType attribute.

R3063 A ValueType attribute on a wsse:KeyIdentifier element in a SECURITY_TOKEN_REFERENCE 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>

5.2.10 KeyIdentifier/@EncodingType Attribute

R3070 A wsse:KeyIdentifier element in a SECURITY_TOKEN_REFERENCE MUST specify an EncodingType attribute.

R3071 An EncodingType attribute on a wsse:KeyIdentifier element in a SECURITY_TOKEN_REFERENCE 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>

5.2.11 References from within Embedded Tokens

Embedded security tokens can potentially chain to other security tokens, which adds complexity to processing and discourages interoperability.

R3055 A wsse:Embedded element in a SECURE_ENVELOPE MUST NOT contain a wsse:SecurityTokenReference child element.

Eliminating redirection from within embedded elements reduces required complexity in handling embedded security tokens.

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>

5.2.12 Embedded Token Content

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

R3060 A wsse:Embedded element in a SECURE_ENVELOPE MUST contain a single child element containing a security token defined in a security token profile.

In order to reduce ambiguity surrounding which token to process, the Basic Security Profile 1.0 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>

5.2.13 Reference from wsse:SecurityTokenReference to wsse:SecurityTokenReference

Security Token References are expected to refer to security tokens, not to other security token references. Hence the Basic Security Profile 1.0 disallows chained references.

R3056 A SECURITY_TOKEN_REFERENCE MUST NOT use a Direct Reference to another SECURITY_TOKEN_REFERENCE that does not have a wsse:Embedded child element.

R3064 When a SECURITY_TOKEN_REFERENCE uses a Direct Reference to an INTERNAL_SECURITY_TOKEN contained within an wsse:Embedded element of another SECURITY_TOKEN_REFERENCE, the reference MUST be to the contained INTERNAL_SECURITY_TOKEN not to the wsse:Embedded element.

If more than one Security Token Reference intends to refer to the same security token, they can use the same reference mechanism and therefore don't need to chain references. Chaining of references creates unnecessary complexity.

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>

5.2.14 wsse:SecurityTokenReference/Reference ValueType Attribute

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 A wsse:Reference element in a SECURITY_TOKEN_REFERENCE MUST specify a ValueType attribute.

R3058 A wsse:Reference element in a SECURITY_TOKEN_REFERENCE MUST specify a ValueType attribute that matches a ValueType specified by a security token profile for the the referenced SECURITY_TOKEN.

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.

5.2.15 wsse:SecurityTokenReference content

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 have exactly one child element.

Restricting the number of reference mechanisms reduces complexity.

5.2.16 wsse:SecurityTokenReference/Reference requires URI attribute

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 A wsse:Reference element in a SECURITY_TOKEN_REFERENCE MUST specify a URI attribute.

Eliminating underspecified functionality removes complexity.

5.2.17 wsse:SecurityTokenReference Dereferencing Transform

The Security Token Dereferencing Transform allows for the optional specification of a canonicalization algorithm.

R3065 When a SIGNATURE uses the SecurityTokenReference Dereferencing Transform, the ds:CanonicalizationMethod element MUST be present and wrapped in a wsse:TransformationParameters element.

Consistent processing of data to be signed, including security token content, reduces complexity.

5.2.18 Security Token References across security headers prohibited

The potential exists for the same security token to be referenced from multiple security headers.

R3066 A SECURITY_TOKEN_REFERENCE MUST NOT use a Shorthand XPointer Reference to refer to an INTERNAL_SECURITY_TOKEN located in another SECURITY_HEADER.

Since processing of security header elements can result in the removal of those elements, references to elements in another header may not correctly resolve. If an internal security token is referenced from multiple security headers it should be copied into each referencing header.

5.3 Timestamps

The following specifications (or sections thereof) are referred to in this section of the Basic Security Profile 1.0:

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

5.3.1 wsu:Timestamp/wsu:Created

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

R3203 A TIMESTAMP MUST have exactly one wsu:Created element child.

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>

5.3.2 Occurence constraints on wsu:Created and wsu:Expires

A timestamp may optionally contain an expires element.

R3224 A TIMESTAMP MUST NOT contain more than one wsu:Expires element.

R3221 If a TIMESTAMP contains a wsu:Expires element it MUST appear after the wsu:Created element.

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

5.3.3 Leap Seconds Not Allowed

Leap seconds are allowed by the underlying specifications.

R3213 A TIMESTAMP MUST NOT include wsu:Created or wsu:Expires values that specify leap seconds.

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

5.3.4 Timestamp ValueType

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

R3225 A wsu:Created element within a TIMESTAMP MUST NOT include a ValueType attribute.

R3226 A wsu:Expires element within a TIMESTAMP MUST NOT include a ValueType attribute.

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

5.3.5 Timestamp Format

The underlying specifications allow for a variety of timestamp formats.

R3217 A TIMESTAMP MUST only contain time values in UTC format as specified by the XML Schema type (dateTime).

Limiting timestamp values to UTC time eliminates complexity.

5.3.6 Timestamp Resolution

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

R3220 A RECEIVER MUST be capable of processing wsu:Created and wsu:Expires values upto and including milliseconds.

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

5.3.7 wsu:Timestamp inside wsse:Security header

The underlying specifications do not specify semantics for timestamps other than those that are children of the security header.

R3218 A SECURITY_HEADER MUST NOT contain a wsu:timestamp that is not its immediate child.

R3219 A SECURITY_HEADER MUST NOT contain more than one TIMESTAMP.

The Profile does not allow inclusion of timestamp elements with unspecified semantics.

5.4 wsu:Id References

The following specifications (or sections thereof) are referred to in this section of the Basic Security Profile 1.0:

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

5.4.1 wsu:Id Attribute 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 Two wsu:Id attributes within any SECURE_ENVELOPE MUST NOT have the same 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.

5.5 wsse:Security Processing Order

The following specifications (or sections thereof) are referred to in this section of the Basic Security Profile 1.0:

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

5.5.1 Order of Processing

Messages may be signed and encrypted, potentially with by multiple entities signing and encrypting overlapping elements. A signature applied before encryption has different security properties than encryption applied before a signature. 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 Within a SECURITY_HEADER, all SIGNATURE, ENCRYPTED_KEY, and ENCRYPTION_REFERENCE_LIST elements MUST be ordered 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 ordering 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.6 SOAP Actor

The following specifications (or sections thereof) are referred to in this section of the Basic Security Profile 1.0:

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

5.6.1 SOAP Actor Value

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

R3206 Within a SECURE_ENVELOPE there MUST be at most one SECURITY_HEADER with the actor attribute omitted.

R3210 Within a SECURE_ENVELOPE there MUST NOT be 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. Username Token Profile

This section of the Basic Security Profile 1.0 incorporates the following specifications by reference:

6.1 Token Usage

6.1.1 wsse:UsernameToken/wsse:Password/@Type

Passwords may be present in a variety of formats. The Type attribute specifies the format of the Password value.

R4201 A wsse:UsernameToken/wsse:Password element in a SECURITY_HEADER MUST specify a Type attribute.

To avoid ambiguity, the Type attribute must be specified on the wsse:Password element of a wsse:UsernameToken.

INCORRECT:

<!-- This example is incorrect because the wsse:Password element is missing a Type attribute with a value of 
     http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-username-token-profile-1.0#PasswordText -->

<wsse:UsernameToken
   xmlns:wsse='http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd' >
   <wsse:Username>Bert</wsse:Username>
   <wsse:Password>Ernie</wsse:Password>
</wsse:UsernameToken>

INCORRECT:

<
<!-- This example is incorrect because the wsse:Password element is missing a Type attribute with a value of 
     http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-username-token-profile-1.0#PasswordDigest -->

<wsse:UsernameToken
   xmlns:wsse='http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd' >
   <wsse:Username>Bert</wsse:Username>
   <wsse:Password>B5twk47KwSrjeg==</wsse:Password>
</wsse:UsernameToken>

CORRECT:

<wsse:UsernameToken
   xmlns:wsse='http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd' >
   <wsse:Username>Bert</wsse:Username>
   <wsse:Password
      Type='http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-username-token-profile-1.0#PasswordText'>
      Ernie
   </wsse:Password>
</wsse:UsernameToken>

CORRECT:

<wsse:UsernameToken xmlns:wsse='http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd' >
   <wsse:Username>Bert</wsse:Username>
   <wsse:Password
      Type='http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-username-token-profile-1.0#PasswordDigest'>
      B5twk47KwSrjeg==
   </wsse:Password>
</wsse:UsernameToken>

6.1.2 PasswordDigest

The underlying specifications specify a Type value for password digests but there is ambiguity in the algorithm to be used to calculate the digest.

R4212 When a wsse:Password element with a Type attribute with a value of "http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-username-token-profile-1.0#PasswordDigest" is used within a SECURITY_TOKEN, its value MUST be computed using the following formula, where "+" indicates concatenation: Password_Digest = Base64 ( SHA-1 ( nonce + created + password ) ). That is, concatenate the nonce, creation timestamp, and the password (or shared secret or password equivalent), digest the combination using the SHA-1 hash algorithm, then include the Base64 encoding of that result as the password (digest). Any elements that are not present are simply omitted from the concatenation.

The Profile describes the digest calculation details to eliminate ambiguity.

6.1.3 ValueType attribute

The underlying specifications do not fully describe the proper ValueType for UsernameToken.

R4214 When a SECURITY_TOKEN named wsse:UsernameToken is referenced by a SECURITY_TOKEN_REFERENCE then the wsse:SecurityTokenReference/wsse:Reference/@ValueType attribute MUST have a value of "http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-soap-message-security-1.0#UsernameToken".

The Profile requires a specific value for the ValueType.

6.1.4 EncodingType attribute

R4220 A SECURITY_TOKEN named wsse:UsernameToken MUST specify an EncodingType attribute.

R4221 An EncodingType attribute of a SECURITY_TOKEN named wsse:UsernameToken MUST have a value of "http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-soap-message-security-1.0#Base64Binary".

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

6.1.5 Reference by KeyIdentifier

The underlying specifications do not describe a mechanism for generating a KeyIdentifier for a UsernameToken.

R4215 When a SECURITY_TOKEN_REFERENCE refers to a wsse:UsernameToken, a KeyIdentifier reference MUST NOT be used.

The Profile disallows the use of unspecified mechanisms for generation of KeyIdentifier values.

6.1.6 Key Derivation

The Username Token profile does not currently define a key derivation algorithm. The OASIS WSS TC is expected to address this issue in a subsequent specification.

7. X.509 Certificate Token Profile

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

7.1 Token Types

The following specifications (or sections thereof) are referred to in this section of the Basic Security Profile 1.0:

Web Services Security: X.509 Token Profile defines 3 token types: X509v3; x509PKIPathv1; and PKCS7. The Profile places the following constraints on their use:

7.1.1 Certificate Path Format

The underlying specifications allow certificate path information to be provided via either X509PKIPathv1 or PKCS7 formats.

R5201 When certificate path information is provided, a SENDER MUST provide one of the X509PKIPathv1 or PKCS7 token types.

R5202 When certificate path information is provided, a SENDER SHOULD provide the X509PKIPathv1 token type.

R5203 When certificate path information is provided, a RECEIVER MUST accept X509PKIPathv1 and PKCS7 token types.

Interoperability issues may arise if different forms of certificate path information are used when not expected. X509PKIPathv1 is preferred because it allows more efficient certificate path processing. PKCS7 is a more mature and widely implemented standard so it is also allowed. Section 3.1 of X.509 Token Profile incorrectly defines #X509PKIPathv1 as a PKIPath. Section 3.1 should define #X509PKIPathv1 as a PkiPath (note case), which X.509 defect report 279 defines as an ordered collection of certificates beginning with the most significant.

7.1.2 KeyIdentifier

The underlying specifications do not fully describe the proper ValueType for X.509 SubjectKeyIdentifier.

R5206 When the wsse:KeyIdentifier element is used within a SECURITY_TOKEN_REFERENCE to specify a reference to an X.509 Certificate Token, the wsse:KeyIdentifier element MUST have a ValueType attribute with the value "http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-x509-token-profile-1.0#X509SubjectKeyIdentifier"

R5208 When the wsse:KeyIdentifier element is used within a SECURITY_TOKEN_REFERENCE to specify a reference to an X.509 Certificate Token its contents MUST be the value of the certificate's X.509 SubjectKeyIdentifier extension.

The Profile requires a specific value for the ValueType.

7.1.3 KeyIdentifier EncodingType

This requirement addresses the provisions of SOAP Message Security 1.0 Errata that recommends that the optional EncodingType attribute be encoded in base64.

R5207 When the wsse:KeyIdentifier element is used within a SECURITY_TOKEN_REFERENCE to specify a reference to an X.509 Certificate Token, the wsse:KeyIdentifier element MUST have an EncodingType attribute with the value "http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-soap-message-security-1.0#Base64Binary"

The Profile requires specifying the encoding type and restricts it to base64.

8. XML-Signature

Web Services Security: SOAP Message Security builds on XML Signature, defining usage of various elements from XML Signature and a processing model. The Profile places the constraints defined in this section on the use of XML Signature with Web Services Security: SOAP Message Security. The Profile places no constraints on other use of XML Signature.

This section of the Basic Security Profile 1.0 incorporates the following specifications by reference:

8.1 General Constraints on XML Signature

8.1.1 Signature Content

Partners in a message exchange must agree which elements must be signed and which elements may be signed.

R3105 SENDERs and RECEIVERs can agree in out of band fashion on required and allowed signed message content.

Some vendors have strict implementation of what message content must be signed. Some other vendors are more tolerent to receiving additional signed content in a message. The Profile allows for an out of band agreement between vendors on how to address this issue.

8.1.2 Signature Types

Due to the nature of the SOAP processing model, which is based on recognising the elements that are children of soap:Header and/or soap:Body, use of enveloping signatures, where the signed XML is encapsulated in a ds:Signature element, is inappropriate. Enveloped signatures, where the ds:Signature element is a descendant of the signed element, limit the ability of intermediaries to process messages and should be avoided unless said limitation is the desired effect.

R3102 A SIGNATURE MUST NOT be an Enveloping Signature as defined by the XML Signature specification.

R3103 A SIGNATURE SHOULD be a Detached Signature as defined by the XML Signature specification.

R3104 A SIGNATURE SHOULD NOT be an Enveloped Signature as defined by the XML Signature Specification.

Detached signatures are encouraged. Enveloped signatures are discouraged. Enveloping signatures are not allowed.

INCORRECT:

<!-- This example is incorrect because it contains an enveloping signature around the SomeSecurityToken element -->

<ds:Signature Id='TheSig' xmlns:ds='http://www.w3.org/2000/09/xmldsig#'>
   <ds:SignedInfo>
      <ds:CanonicalizationMethod Algorithm='http://www.w3.org/2001/10/xml-exc-c14n#" '>
         <c14n:InclusiveNamespaces xmlns:c14n='http://www.w3.org/2001/10/xml-exc-c14n#' PrefixList='wsse soap' />
      </ds:CanonicalizationMethod>
      <ds:SignatureMethod Algorithm='http://www.w3.org/2000/09/xmldsig#rsa-sha1' />
      <ds:Reference URI='#SigPropBody'>
         <ds:Transforms>
            <ds:Transform Algorithm='http://www.w3.org/2001/10/xml-exc-c14n#'>
               <c14n:InclusiveNamespaces xmlns:c14n='http://www.w3.org/2001/10/xml-exc-c14n#' PrefixList='' />
            </ds:Transform>
         </ds:Transforms>
         <ds:DigestMethod Algorithm='http://www.w3.org/2000/09/xmldsig#sha1' />
         <ds:DigestValue>i3qi5GjhHnfoBn/jOjQp2mq0Na4=</ds:DigestValue>
      </ds:Reference>
   </ds:SignedInfo>
   <ds:SignatureValue>oxNwoqGbzqg1YBliz+PProgcjw8=</ds:SignatureValue>
   <ds:KeyInfo>
      <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>
   </ds:KeyInfo>
   <ds:Object>
      <ds:SignatureProperties>
         <ds:SignatureProperty Id='SigPropBody' Target='#TheSig'>
            <SomeSecurityToken/>
         </ds:SignatureProperty>
      </ds:SignatureProperties>
   </ds:Object>
</ds:Signature>

CORRECT:

<ds:Signature xmlns:ds='http://www.w3.org/2000/09/xmldsig#'>
   <ds:SignedInfo>
      <ds:CanonicalizationMethod Algorithm='http://www.w3.org/2001/10/xml-exc-c14n#" '>
         <c14n:InclusiveNamespaces xmlns:c14n='http://www.w3.org/2001/10/xml-exc-c14n#'
                                   PrefixList='wsse soap' />
      </ds:CanonicalizationMethod>
      <ds:SignatureMethod Algorithm='http://www.w3.org/2000/09/xmldsig#rsa-sha1' />
      <ds:Reference URI='#TheBody'>
         <ds:Transforms>
            <ds:Transform Algorithm='http://www.w3.org/2001/10/xml-exc-c14n#'>
               <c14n:InclusiveNamespaces xmlns:c14n='http://www.w3.org/2001/10/xml-exc-c14n#'
                                         PrefixList='soap wsu m' />
            </ds:Transform>
         </ds:Transforms>
         <ds:DigestMethod Algorithm='http://www.w3.org/2000/09/xmldsig#sha1' />
         <ds:DigestValue>i3qi5GjhHnfoBn/jOjQp2mq0Na4=</ds:DigestValue>
      </ds:Reference>
   </ds:SignedInfo>
   <ds:SignatureValue>PipXJ2Sfc+LTDnq4pM5JcIYt9gg=</ds:SignatureValue>
   <ds:KeyInfo>
      <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>
   </ds:KeyInfo>
</ds:Signature>

8.2 Element References in XML Signature

The following specifications (or sections thereof) are referred to in this section of the Basic Security Profile 1.0:

Element references are used to specify which portions of a SECURE_ENVELOPE are integrity protected. The Basic Security Profile 1.0 places the following constraints on the use of element references:

8.2.1 Reference to Elements by Shorthand XPointer (XMLDSIG)

Processing of Shorthand XPointer References requires knowledge of which attributes are IDs. Since the underlying specifications strive to allow message processing without schema processing, some non-schema aware method for identifying ID attributes must be used.

R3001 When a ds:Reference in a SIGNATURE refers to an element that carries a wsu:Id attribute or a Local ID attribute defined by XML Signature or XML Encryption, a Shorthand XPointer Reference MUST be used to refer to that element.

R3003 When a ds:Reference/@URI in a SIGNATURE is a Shorthand XPointer Reference to an XML Signature element, the reference value MUST be a Local ID defined by XML Signature.

R3004 When a ds:Reference/@URI in a SIGNATURE is a Shorthand XPointer Reference to an XML Encryption element, the reference value MUST be a Local ID defined by XML Encryption.

R3005 When a ds:Reference/@URI in a SIGNATURE is a Shorthand XPointer Reference to an element not defined by XML Signature or XML Encryption, the reference value SHOULD be a wsu:Id.

The underlying specifications define well known ID attributes. Limiting references to those well known attributes reduces complexity and the reliance on schema processing.

8.2.2 Reference to Elements by XPath Expression

Elements that do not have an attribute of type ID cannot be referred to by Shorthand XPointer References so a different referencing mechanism is needed.

R3002 When referring to an element in a SECURE_ENVELOPE that does NOT carry an attribute of type ID from a ds:Reference in a SIGNATURE the XPath Filter 2.0 Transform (http://www.w3.org/2002/06/xmldsig-filter2) MUST be used to refer to that element.

The XPath Filter 2.0 transform is more efficient than the original XPath transform from XML Digital Signature Syntax and Processing.

INCORRECT:

<!-- This example is incorrect because it uses the http://www.w3.org/TR/1999/REC-xpath-19991116 transform instead of the http://www.w3.org/2002/06/xmldsig-filter2 transform -->


<soap:Envelope xmlns:soap='http://schemas.xmlsoap.org/soap/envelope' >
 <soap:Header>
   <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'>
     <wsse:BinarySecurityToken wsu:Id='SomeCert'
                               ValueType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-x509-token-profile-1.0#X509v3">
lui+Jy4WYKGJW5xM3aHnLxOpGVIpzSg4V486hHFe7sHET/uxxVBovT7JV1A2RnWSWkXm9jAEdsm/...
     </wsse:BinarySecurityToken>
     <ds:Signature xmlns:ds='http://www.w3.org/2000/09/xmldsig#'>
       <ds:SignedInfo>
         <ds:CanonicalizationMethod Algorithm='http://www.w3.org/2001/10/xml-exc-c14n#" '>
           <c14n:InclusiveNamespaces xmlns:c14n='http://www.w3.org/2001/10/xml-exc-c14n#'
                                     PrefixList='wsse soap wsu' />
         </ds:CanonicalizationMethod>
         <ds:SignatureMethod Algorithm='http://www.w3.org/2000/09/xmldsig#rsa-sha1' />
         <ds:Reference URI=''>
           <ds:Transforms>
             <ds:Transform Algorithm='http://www.w3.org/TR/1999/REC-xpath-19991116'>
               <ds:XPath>/soap:Envelope/soap:Body/*</ds:XPath>
             </ds:Transform>
             <ds:Transform Algorithm='http://www.w3.org/2001/10/xml-exc-c14n#'>
               <c14n:InclusiveNamespaces xmlns:c14n='http://www.w3.org/2001/10/xml-exc-c14n#'
                                         PrefixList='soap wsu m' />
             </ds:Transform>
           </ds:Transforms>
           <ds:DigestMethod Algorithm='http://www.w3.org/2000/09/xmldsig#sha1' />
           <ds:DigestValue>VEPKwzfPGOxh2OUpoK0bcl58jtU=</ds:DigestValue>
         </ds:Reference>
       </ds:SignedInfo>
       <ds:SignatureValue>+diIuEyDpV7qxVoUOkb5rj61+Zs=</ds:SignatureValue>
       <ds:KeyInfo>
         <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>
       </ds:KeyInfo>
     </ds:Signature>
   </wsse:Security>
 </soap:Header>
 <soap:Body xmlns:wsu='http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd'
            wsu:Id='TheBody'>
   <m:SomeElement xmlns:m='http://example.org/ws' />
 </soap:Body>
</soap:Envelope>

CORRECT:

<soap:Envelope xmlns:soap='http://schemas.xmlsoap.org/soap/envelope' >
  <soap:Header>
    <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'>
      <wsse:BinarySecurityToken wsu:Id='SomeCert'
                                ValueType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-x509-token-profile-1.0#X509v3">
lui+Jy4WYKGJW5xM3aHnLxOpGVIpzSg4V486hHFe7sHET/uxxVBovT7JV1A2RnWSWkXm9jAEdsm/...
      </wsse:BinarySecurityToken>
      <ds:Signature xmlns:ds='http://www.w3.org/2000/09/xmldsig#'>
        <ds:SignedInfo>
          <ds:CanonicalizationMethod Algorithm='http://www.w3.org/2001/10/xml-exc-c14n#" '>
            <c14n:InclusiveNamespaces xmlns:c14n='http://www.w3.org/2001/10/xml-exc-c14n#'
                                      PrefixList='wsse soap wsu' />
          </ds:CanonicalizationMethod>
          <ds:SignatureMethod Algorithm='http://www.w3.org/2000/09/xmldsig#rsa-sha1' />
          <ds:Reference URI=''>
            <ds:Transforms>
              <ds:Transform Algorithm='http://www.w3.org/2002/06/xmldsig-filter2'
                            xmlns:dsxp='http://www.w3.org/2002/06/xmldsig-filter2'>
                <dsxp:XPath Filter='intersect'>/soap:Envelope/soap:Body/*</dsxp:XPath>
              </ds:Transform>
              <ds:Transform Algorithm='http://www.w3.org/2001/10/xml-exc-c14n#'>
                <c14n:InclusiveNamespaces xmlns:c14n='http://www.w3.org/2001/10/xml-exc-c14n#'
                                          PrefixList='soap wsu m' />
              </ds:Transform>
            </ds:Transforms>
            <ds:DigestMethod Algorithm='http://www.w3.org/2000/09/xmldsig#sha1' />
            <ds:DigestValue>VEPKwzfPGOxh2OUpoK0bcl58jtU=</ds:DigestValue>
          </ds:Reference>
        </ds:SignedInfo>
        <ds:SignatureValue>+diIuEyDpV7qxVoUOkb5rj61+Zs=</ds:SignatureValue>
        <ds:KeyInfo>
          <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>
        </ds:KeyInfo>
      </ds:Signature>
    </wsse:Security>
  </soap:Header>
  <soap:Body xmlns:wsu='http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd'
             wsu:Id='TheBody'>
    <m:SomeElement xmlns:m='http://example.org/ws' />
  </soap:Body>
</soap:Envelope>

8.3 XML Signature Algorithms

8.3.1 Use Exclusive C14N

Unless proper canonicalization is performed, verification of signatures may not work due to changes to the elements in the containing scope.

R5404 Any ds:CanonicalizationMethod/@Algorithm attribute in a SIGNATURE MUST have a value of "http://www.w3.org/2001/10/xml-exc-c14n#" indicating that is uses Exclusive C14N without comments for canonicalization.

R5406 Any ds:CanonicalizationMethod element within a SIGNATURE that has an @Algorithm attribute whose value is "http://www.w3.org/2001/10/xml-exc-c14n#" MUST have a c14n:InclusiveNamespaces child element with an @PrefixList attribute unless the PrefixList is empty.

R5407 Any ds:Transform element within a SIGNATURE that has an @Algorithm attribute whose value is "http://www.w3.org/2001/10/xml-exc-c14n#" MUST have a c14n:InclusiveNamespaces child element with an @PrefixList attribute unless the PrefixList is empty.

R5405 Any c14n:InclusiveNamespaces/@PrefixList attribute within a SIGNATURE MUST contain the prefix of all in-scope namespaces for the element being signed and its descendants that are not visibly utilized, per Exclusive XML Canonicalization Version 1.0.

R5408 Any c14n:InclusiveNamespaces/@PrefixList attribute within a SIGNATURE MUST contain the string "#default" if a default namespace is in-scope for the element being signed but is not visibly utilized, per Exclusive XML Canonicalization Version 1.0.

R5413 When the STR-Transform is used the ds:Transform/wsse:TransformationParameters/ds:CanonicalizationMethod/ec:InclusiveNamespaces element MUST be provided.

R5414 A RECEIVER MUST be capable of accepting and processing a ec:InclusiveNamespaces/@PrefixList containing prefixes in any order within the string.

R5415 A RECEIVER MUST be capable of accepting and processing a ec:InclusiveNamespaces/@PrefixList containing arbitrary whitespace before, after and between the prefixes within the string.

The use of Exclusive Canonicalization with c14n:InclusiveNamespaces/@Prefix addresses problems with both Inclusive Canonicalization and Exclusive Canonicalization without c14n:InclusiveNamespaces/@Prefix.

INCORRECT:

<!-- This example is incorrect because it uses the http://www.w3.org/TR/2001/REC-xml-c14n-20010315
canonicalization algorithm -->

<ds:CanonicalizationMethod Algorithm='http://www.w3.org/TR/2001/REC-xml-c14n-20010315' />

INCORRECT:

<!-- This example is incorrect because the ds:CanonicalizationMethod elements are missing a c14n:InclusiveNamespaces child element -->

<ds:CanonicalizationMethod Algorithm='http://www.w3.org/2001/10/xml-exc-c14n#" ' />

INCORRECT:

<!-- This example is incorrect because the PrefixList of the first c14n:InclusiveNamespaces element does not contain the 
     correct list of prefixes. It should contain the soap and wsu prefixes in addition to the wsse prefix. -->

<soap:Envelope xmlns:soap='http://schemas.xmlsoap.org/soap/envelope' >
  <soap:Header>
    <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'>
      <wsse:BinarySecurityToken wsu:Id='SomeCert'
                                ValueType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-x509-token-profile-1.0#X509v3">
lui+Jy4WYKGJW5xM3aHnLxOpGVIpzSg4V486hHFe7sHET/uxxVBovT7JV1A2RnWSWkXm9jAEdsm/...
      </wsse:BinarySecurityToken>
      <ds:Signature xmlns:ds='http://www.w3.org/2000/09/xmldsig#'>
        <ds:SignedInfo>
          <ds:CanonicalizationMethod Algorithm='http://www.w3.org/2001/10/xml-exc-c14n#" '>
            <c14n:InclusiveNamespaces xmlns:c14n='http://www.w3.org/2001/10/xml-exc-c14n#'
                                      PrefixList='wsse' />
          </ds:CanonicalizationMethod>
          <ds:SignatureMethod Algorithm='http://www.w3.org/2000/09/xmldsig#rsa-sha1' />
          <ds:Reference URI='#TheBody'>
            <ds:Transforms>
              <ds:Transform Algorithm='http://www.w3.org/2001/10/xml-exc-c14n#'>
                <c14n:InclusiveNamespaces xmlns:c14n='http://www.w3.org/2001/10/xml-exc-c14n#'
                                          PrefixList='soap wsu m' />
              </ds:Transform>
            </ds:Transforms>
            <ds:DigestMethod Algorithm='http://www.w3.org/2000/09/xmldsig#sha1' />
            <ds:DigestValue>VEPKwzfPGOxh2OUpoK0bcl58jtU=</ds:DigestValue>
          </ds:Reference>
        </ds:SignedInfo>
        <ds:SignatureValue>+diIuEyDpV7qxVoUOkb5rj61+Zs=</ds:SignatureValue>
        <ds:KeyInfo>
          <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>
        </ds:KeyInfo>
      </ds:Signature>
    </wsse:Security>
  </soap:Header>
  <soap:Body xmlns:wsu='http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd'
             wsu:Id='TheBody'>
    <m:SomeElement xmlns:m='http://example.org/ws' />
  </soap:Body>
</soap:Envelope>

CORRECT:

<soap:Envelope xmlns:soap='http://schemas.xmlsoap.org/soap/envelope' >
  <soap:Header>
    <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'>
      <wsse:BinarySecurityToken wsu:Id='SomeCert'
                                ValueType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-x509-token-profile-1.0#X509v3">
lui+Jy4WYKGJW5xM3aHnLxOpGVIpzSg4V486hHFe7sHET/uxxVBovT7JV1A2RnWSWkXm9jAEdsm/...
      </wsse:BinarySecurityToken>
      <ds:Signature xmlns:ds='http://www.w3.org/2000/09/xmldsig#'>
        <ds:SignedInfo>
          <ds:CanonicalizationMethod Algorithm='http://www.w3.org/2001/10/xml-exc-c14n#" '>
            <c14n:InclusiveNamespaces xmlns:c14n='http://www.w3.org/2001/10/xml-exc-c14n#'
                                      PrefixList='wsse soap wsu' />
          </ds:CanonicalizationMethod>
          <ds:SignatureMethod Algorithm='http://www.w3.org/2000/09/xmldsig#rsa-sha1' />
          <ds:Reference URI='#TheBody'>
            <ds:Transforms>
              <ds:Transform Algorithm='http://www.w3.org/2001/10/xml-exc-c14n#'>
                <c14n:InclusiveNamespaces xmlns:c14n='http://www.w3.org/2001/10/xml-exc-c14n#'
                                          PrefixList='soap wsu m' />
              </ds:Transform>
            </ds:Transforms>
            <ds:DigestMethod Algorithm='http://www.w3.org/2000/09/xmldsig#sha1' />
            <ds:DigestValue>VEPKwzfPGOxh2OUpoK0bcl58jtU=</ds:DigestValue>
          </ds:Reference>
        </ds:SignedInfo>
        <ds:SignatureValue>+diIuEyDpV7qxVoUOkb5rj61+Zs=</ds:SignatureValue>
        <ds:KeyInfo>
          <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>
        </ds:KeyInfo>
      </ds:Signature>
    </wsse:Security>
  </soap:Header>
  <soap:Body xmlns:wsu='http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd'
             wsu:Id='TheBody'>
    <m:SomeElement xmlns:m='http://example.org/ws' />
  </soap:Body>
</soap:Envelope>

8.3.2 Transforms Element

At a minimum an XML Canonicalization Algorithm needs to be specified for each Reference, necessitating a ds:Transforms element.

R5410 Any ds:Reference element in a SIGNATURE MUST have a ds:Transforms child element.

8.3.3 Transform Element

Canonicalization is critical to ensuring signatures are processed correctly, thus each ds:Reference will need at least one ds:Transform to specify the Exclusive C14N Canonicalization transform or a transform which itself incorporates Exclusive C14N Canonicalization.

R5411 Any ds:Transforms element in a SIGNATURE MUST have at least one ds:Transform child element.

R5412 Any ds:Transforms element in a SIGNATURE MUST have as its last child a ds:Transform element which specifies "http://www.w3.org/2001/10/xml-exc-c14n#" or "http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-soap-message-security-1.0#STR-Transform" or "http://docs.oasis-open.org/wss/2004/XX/oasis-2004XX-wss-swa-profile-1.0#Attachment-Content-Signature-Transform" or "http://docs.oasis-open.org/wss/2004/XX/oasis-2004XX-wss-swa-profile-1.0#Attachment-Complete-Signature-Transform"

INCORRECT:

<!-- This example is incorrect because the ds:Reference element does not have a ds:Transforms child element -->

<ds:Reference URI='#TheBody'>
   <ds:DigestMethod Algorithm='http://www.w3.org/2000/09/xmldsig#sha1' />
   <ds:DigestValue>VEPKwzfPGOxh2OUpoK0bcl58jtU=</ds:DigestValue>
</ds:Reference>

CORRECT:

<ds:Reference URI='#TheBody'>
   <ds:Transforms>
      <ds:Transform Algorithm='http://www.w3.org/2001/10/xml-exc-c14n#'>
         <c14n:InclusiveNamespaces xmlns:c14n='http://www.w3.org/2001/10/xml-exc-c14n#'
                                   PrefixList='' />
      </ds:Transform>
   </ds:Transforms>
   <ds:DigestMethod Algorithm='http://www.w3.org/2000/09/xmldsig#sha1' />
   <ds:DigestValue>+VTJraRYFT3pl7Z4uAWhmr5+bf4=</ds:DigestValue>
</ds:Reference>

8.3.4 Digest Algorithm

The SHA1 Digest algorithm is widely-implemented and interoperable hence the requirement that it be used for signature digests.

R5420 Any ds:DigestMethod/@Algorithm element in a SIGNATURE MUST have the value "http://www.w3.org/2000/09/xmldsig#sha1"

8.3.5 Key Signature Algorithms

The two algorithms listed are widely-implemented and interoperable. Two algorithms are needed, one symmetric, one asymmetric.

R5421 Any ds:SignatureMethod/@Algorithm element in a SIGNATURE MUST have a value of "http://www.w3.org/2000/09/xmldsig#hmac-sha1" or "http://www.w3.org/2000/09/xmldsig#rsa-sha1"

8.3.6 Transform Algorithm

These algorithms are chosen for their cryptographic strength, utility or because they address some security concern.

R5423 Any ds:Transform/@Algorithm attribute in a SIGNATURE MUST have a value of "http://www.w3.org/2001/10/xml-exc-c14n#" or "http://www.w3.org/2002/06/xmldsig-filter2" or "http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-soap-message-security-1.0#STR-Transform" or "http://www.w3.org/2000/09/xmldsig#enveloped-signature" or "http://docs.oasis-open.org/wss/2004/XX/oasis-2004XX-wss-swa-profile-1.0#Attachment-Content-Signature-Transform" or "http://docs.oasis-open.org/wss/2004/XX/oasis-2004XX-wss-swa-profile-1.0#Attachment-Complete-Signature-Transform"

CORRECT:

<soap:Envelope xmlns:soap='http://schemas.xmlsoap.org/soap/envelope' >
  <soap:Header>
    <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'>
      <wsse:BinarySecurityToken wsu:Id='SomeCert'
                                ValueType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-x509-token-profile-1.0#X509v3">
lui+Jy4WYKGJW5xM3aHnLxOpGVIpzSg4V486hHFe7sHET/uxxVBovT7JV1A2RnWSWkXm9jAEdsm/...
      </wsse:BinarySecurityToken>
      <xenc:EncryptedKey xmlns:xenc='http://www.w3.org/2001/04/xmlenc#' >
        <xenc:EncryptionMethod Algorithm='http://www.w3.org/2001/04/xmlenc#rsa-1_5' />
        <ds:KeyInfo xmlns:ds='http://www.w3.org/2000/09/xmldsig#'>
          <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>
        </ds:KeyInfo>
        <xenc:CipherData>
          <xenc:CipherValue>
            XZEEVABD3L9G+VNTCDiDTE7WB1a4kILtz5f9FT747eE=       
          </xenc:CipherValue>
        </xenc:CipherData>
      </xenc:EncryptedKey>
      <ds:Signature xmlns:ds='http://www.w3.org/2000/09/xmldsig#'>
        <ds:SignedInfo>
          <ds:CanonicalizationMethod Algorithm='http://www.w3.org/2001/10/xml-exc-c14n#" '>
            <c14n:InclusiveNamespaces xmlns:c14n='http://www.w3.org/2001/10/xml-exc-c14n#'
                                      PrefixList='wsse soap' />
          </ds:CanonicalizationMethod>
          <ds:SignatureMethod Algorithm='http://www.w3.org/2000/09/xmldsig#hmac-sha1' />
          <ds:Reference URI='#TheBody'>
            <ds:Transforms>
              <ds:Transform Algorithm='http://www.w3.org/2001/10/xml-exc-c14n#'>
                <c14n:InclusiveNamespaces xmlns:c14n='http://www.w3.org/2001/10/xml-exc-c14n#'
                                          PrefixList='' />
              </ds:Transform>
            </ds:Transforms>
            <ds:DigestMethod Algorithm='http://www.w3.org/2000/09/xmldsig#sha1' />
            <ds:DigestValue>+VTJraRYFT3pl7Z4uAWhmr5+bf4=</ds:DigestValue>
          </ds:Reference>
        </ds:SignedInfo>
        <ds:SignatureValue>+diIuEyDpV7qxVoUOkb5rj61+Zs=</ds:SignatureValue>
      </ds:Signature>
    </wsse:Security>
  </soap:Header>
  <soap:Body xmlns:wsu='http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd'
             wsu:Id='TheBody'>
    <m:SomeElement xmlns:m='http://example.org/ws' />
  </soap:Body>
</soap:Envelope>

CORRECT:

<soap:Envelope xmlns:soap='http://schemas.xmlsoap.org/soap/envelope' >
  <soap:Header>
    <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'>
      <wsse:BinarySecurityToken wsu:Id='SomeCert'
                                ValueType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-x509-token-profile-1.0#X509v3">
lui+Jy4WYKGJW5xM3aHnLxOpGVIpzSg4V486hHFe7sHET/uxxVBovT7JV1A2RnWSWkXm9jAEdsm/...
      </wsse:BinarySecurityToken>
      <ds:Signature xmlns:ds='http://www.w3.org/2000/09/xmldsig#'>
        <ds:SignedInfo>
          <ds:CanonicalizationMethod Algorithm='http://www.w3.org/2001/10/xml-exc-c14n#" '>
            <c14n:InclusiveNamespaces xmlns:c14n='http://www.w3.org/2001/10/xml-exc-c14n#'
                                      PrefixList='wsse soap' />
          </ds:CanonicalizationMethod>
          <ds:SignatureMethod Algorithm='http://www.w3.org/2000/09/xmldsig#rsa-sha1' />
          <ds:Reference URI='#TheBody'>
            <ds:Transforms>
              <ds:Transform Algorithm='http://www.w3.org/2001/10/xml-exc-c14n#'>
                <c14n:InclusiveNamespaces xmlns:c14n='http://www.w3.org/2001/10/xml-exc-c14n#'
                                          PrefixList='' />
              </ds:Transform>
            </ds:Transforms>
            <ds:DigestMethod Algorithm='http://www.w3.org/2000/09/xmldsig#sha1' />
            <ds:DigestValue>+VTJraRYFT3pl7Z4uAWhmr5+bf4=</ds:DigestValue>
          </ds:Reference>
        </ds:SignedInfo>
        <ds:SignatureValue>+diIuEyDpV7qxVoUOkb5rj61+Zs=</ds:SignatureValue>
        <ds:KeyInfo>
          <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>
        </ds:KeyInfo>
      </ds:Signature>
    </wsse:Security>
  </soap:Header>
  <soap:Body xmlns:wsu='http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd'
             wsu:Id='TheBody'>
    <m:SomeElement xmlns:m='http://example.org/ws' />
  </soap:Body>
</soap:Envelope>

Editors' note:Update the SwA Profile URIs when final.

8.4 XML Signature Syntax

XML-Signature Syntax and Processing defines many elements and attributes. The Basic Security Profile 1.0 places the following constraints on the syntax of signatures:

8.4.1 ds:HMACOutputLength

The ds:HMACOutputLength provides an input parameter to the HMAC-SHA1 algorithm specifying how many bits of the output to use. Disallowing use of this element results in ALL the bits of the output being used.

R5401 The ds:HMACOutputLength element MUST NOT appear in a SIGNATURE.

INCORRECT:

<!-- This example is incorrect because the ds:SignatureMethod element has a ds:HMACOutputLength child element -->
<ds:SignatureMethod Algorithm='http://www.w3.org/2000/09/xmldsig#hmac-sha1'>
   <ds:HMACOutputLength>128</ds:HMACOutputLength>
</ds:SignatureMethod>

CORRECT:

<ds:SignatureMethod Algorithm='http://www.w3.org/2000/09/xmldsig#hmac-sha1' />

8.4.2 ds:KeyInfo with ds:Signature

The ds:KeyInfo element allows for many different child elements. The Profile mandates a single element, wsse:SecurityTokenReference, which is needed to reference security tokens.

R5402 A ds:KeyInfo element in a SIGNATURE MUST have exactly one child element.

R5409 The child element of a ds:KeyInfo element in a SIGNATURE MUST be a SECURITY_TOKEN_REFERENCE element.

CORRECT:

<ds:KeyInfo xmlns:ds='http://www.w3.org/2000/09/xmldsig#' >
   <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>
</ds:KeyInfo>

8.4.3 ds:Manifest

The ds:Manifest element is designed for specific application level use cases that do not apply to the use of XML Signature in SOAP Message Security.

R5403 A SIGNATURE MUST NOT contain a ds:Manifest element.

INCORRECT:

<!-- This example is incorrect because the ds:Signature element has a ds:Manifest grandchild element -->

<ds:Signature xmlns:ds='http://www.w3.org/2000/09/xmldsig#'>
   <ds:SignedInfo>
      <ds:CanonicalizationMethod Algorithm='http://www.w3.org/2001/10/xml-exc-c14n#" '>
         <c14n:InclusiveNamespaces xmlns:c14n='http://www.w3.org/2001/10/xml-exc-c14n#'
                                   PrefixList='wsse soap' />
      </ds:CanonicalizationMethod>
      <ds:SignatureMethod Algorithm='http://www.w3.org/2000/09/xmldsig#rsa-sha1' />
      <ds:Reference URI='#TheManifest'>
         <ds:Transforms>
            <ds:Transform Algorithm='http://www.w3.org/2001/10/xml-exc-c14n#'>
               <c14n:InclusiveNamespaces xmlns:c14n='http://www.w3.org/2001/10/xml-exc-c14n#'
                                         PrefixList='' />
            </ds:Transform>
         </ds:Transforms>
         <ds:DigestMethod Algorithm='http://www.w3.org/2000/09/xmldsig#sha1' />
         <ds:DigestValue>OVuYKGY6KCGB0l0XHS3krj8vjek=</ds:DigestValue>
      </ds:Reference>
   </ds:SignedInfo>
   <ds:SignatureValue>L7X0Zw23/zYQnX4+Z+p0gCygKQ0=</ds:SignatureValue>
   <ds:KeyInfo>
      <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>
   </ds:KeyInfo>
   <ds:Object>
      <ds:Manifest Id='TheManifest'>
         <ds:Reference URI='#TheBody'>
            <ds:Transforms>
               <ds:Transform Algorithm='http://www.w3.org/2001/10/xml-exc-c14n#'>
                  <c14n:InclusiveNamespaces xmlns:c14n='http://www.w3.org/2001/10/xml-exc-c14n#'
                                            PrefixList='' />
               </ds:Transform>
            </ds:Transforms>
            <ds:DigestMethod Algorithm='http://www.w3.org/2000/09/xmldsig#sha1' />
            <ds:DigestValue>+VTJraRYFT3pl7Z4uAWhmr5+bf4=</ds:DigestValue>
         </ds:Reference>
      </ds:Manifest>
   </ds:Object>
</ds:Signature>

8.4.4 Encrypting signatures

If the value of a ds:DigestValue element in a SIGNATURE needs to be encrypted the entire parent ds:Signature element MUST be encrypted.

R5440 A SIGNATURE MUST NOT have any xenc:EncryptedData elements amongst its descendants.

9. XML Encryption

Web Services Security: SOAP Message Security builds on XML Encryption, defining usage of various elements from XML Encryption and a processing model. The Basic Security Profile 1.0 places the constraints defined in this section on the use of XML Encryption with Web Services Security: SOAP Message Security. The Basic Security Profile 1.0 places no constraints on other use of XML Encryption.

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

9.1 XML Encryption Processing Model

9.1.1 xenc:ReferenceList

Some encryption steps might not produce an xenc:ReferenceList. For those that do produce an xenc:ReferenceList, there must be a separate xenc:ReferenceList for each such encryption step. When there is a xenc:ReferenceList either as a child of wsse:Security or as a child of xenc:EncryptedKey it must list all the corresponding xenc:EncryptedData elements by using xenc:DataReference elements.

R3205 Each ENCRYPTION_REFERENCE_LIST produced as part of an encryption step MUST use a single key.

R3215 An ENCRYPTION_REFERENCE_LIST MUST contain an xenc:DataReference element for each ENCRYPTED_DATA produced in the associated encryption step.

R3214 An ENCRYPTED_KEY_REFERENCE_LIST MUST contain a xenc:DataReference for each ENCRYPTED_DATA produced in the associated encryption step.

9.1.2 xenc:EncryptedKey

To facilitate ease of processing, keys are required to appear inside wsse:Security headers and to appear before they are required for decryption of elements inside a wsse:Security header.

R3208 An ENCRYPTED_KEY MUST precede any ENCRYPTED_DATA in the same SECURITY_HEADER referenced by the associated ENCRYPTED_KEY_REFERENCE_LIST.

INCORRECT:

<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">
lui+Jy4WYKGJW5xM3aHnLxOpGVIpzSg4V486hHFe7sHET/uxxVBovT7JV1A2RnWSWkXm9jAEdsm/...
  </wsse:BinarySecurityToken>
  <xenc:EncryptedData Id='Enc1'>
    <xenc:EncryptionMethod Algorithm='http://www.w3.org/2001/04/xmlenc#tripledes-cbc' />
    <xenc:CipherData>
      <xenc:CipherValue>
9jFtYcLSlDZQBMjKfT7ctg6Jy+6sC8YORhiPeTvOjug7ozY2SRHGuLt8G/vf2f/f4IdF0ewiDOpq...
   </xenc:CipherValue>
 </xenc:CipherData>
</xenc:EncryptedData>
<xenc:EncryptedKey>
  <xenc:EncryptionMethod Algorithm='http://www.w3.org/2001/04/xmlenc#rsa-1_5' />
  <ds:KeyInfo>
    <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>
  </ds:KeyInfo>
  <xenc:CipherData>
    <xenc:CipherValue>
      XZEEVABD3L9G+VNTCDiDTE7WB1a4kILtz5f9FT747eE=
    </xenc:CipherValue>
    <xenc:ReferenceList>
      <xenc:DataReference URI='#Enc1' />
    </xenc:ReferenceList>
  </xenc:CipherData>
</xenc:EncryptedKey>
</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">
lui+Jy4WYKGJW5xM3aHnLxOpGVIpzSg4V486hHFe7sHET/uxxVBovT7JV1A2RnWSWkXm9jAEdsm/...
  </wsse:BinarySecurityToken>
  <xenc:EncryptedKey>
   <xenc:EncryptionMethod Algorithm='http://www.w3.org/2001/04/xmlenc#rsa-1_5' />
   <ds:KeyInfo>
     <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>
   </ds:KeyInfo>
   <xenc:CipherData>
     <xenc:CipherValue>
       XZEEVABD3L9G+VNTCDiDTE7WB1a4kILtz5f9FT747eE=       
     </xenc:CipherValue>
   </xenc:CipherData>
   <xenc:ReferenceList>
     <xenc:DataReference URI='#Enc1' />
   </xenc:ReferenceList>
  </xenc:EncryptedKey>
  <xenc:EncryptedData Id='Enc1'>
   <xenc:EncryptionMethod Algorithm='http://www.w3.org/2001/04/xmlenc#tripledes-cbc' />
   <xenc:CipherData>
     <xenc:CipherValue>
9jFtYcLSlDZQBMjKfT7ctg6Jy+6sC8YORhiPeTvOjug7ozY2SRHGuLt8G/vf2f/f4IdF0ewiDOpq...
     </xenc:CipherValue>
   </xenc:CipherData>
  </xenc:EncryptedData>
</wsse:Security>

9.2 XML Encryption Syntax

The following specifications (or sections thereof) are referred to in this section of the Basic Security Profile 1.0:

XML Encryption Syntax and Processing defines many elements and attributes. The Basic Security Profile 1.0 places the following constraints on their use:

9.2.1 Placement

Mandating that an xenc:EncryptedKey element contain a refernce list detailing which message parts were encrypted under that key aids message processing.

R3216 Any ENCRYPTED_KEY that is used in an encryption step MUST contain a ENCRYPTED_KEY_REFERENCE_LIST.

INCORRECT:

<!-- This example is incorrect because the xenc:EncryptedKey element is missing an xenc:ReferenceList child 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">
lui+Jy4WYKGJW5xM3aHnLxOpGVIpzSg4V486hHFe7sHET/uxxVBovT7JV1A2RnWSWkXm9jAEdsm/...
  </wsse:BinarySecurityToken>
  <xenc:EncryptedKey>
    <xenc:EncryptionMethod Algorithm='http://www.w3.org/2001/04/xmlenc#rsa-1_5' />
    <ds:KeyInfo>
      <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>
    </ds:KeyInfo>
    <xenc:CipherData>
      <xenc:CipherValue>
        XZEEVABD3L9G+VNTCDiDTE7WB1a4kILtz5f9FT747eE=       
      </xenc:CipherValue>
    </xenc:CipherData>
  </xenc:EncryptedKey>
  <xenc:ReferenceList>
    <xenc:DataReference URI='#Enc1' />
  </xenc:ReferenceList>
  <xenc:EncryptedData Id='Enc1'>
    <xenc:EncryptionMethod Algorithm='http://www.w3.org/2001/04/xmlenc#tripledes-cbc' />
    <xenc:CipherData>
      <xenc:CipherValue>
9jFtYcLSlDZQBMjKfT7ctg6Jy+6sC8YORhiPeTvOjug7ozY2SRHGuLt8G/vf2f/f4IdF0ewiDOpq...
      </xenc:CipherValue>
    </xenc:CipherData>
  </xenc:EncryptedData>
</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">
lui+Jy4WYKGJW5xM3aHnLxOpGVIpzSg4V486hHFe7sHET/uxxVBovT7JV1A2RnWSWkXm9jAEdsm/...
  </wsse:BinarySecurityToken>
  <xenc:EncryptedKey>
    <xenc:EncryptionMethod Algorithm='http://www.w3.org/2001/04/xmlenc#rsa-1_5' />
    <ds:KeyInfo>
      <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>
    </ds:KeyInfo>
    <xenc:CipherData>
      <xenc:CipherValue>
        XZEEVABD3L9G+VNTCDiDTE7WB1a4kILtz5f9FT747eE=       
      </xenc:CipherValue>
    </xenc:CipherData>
    <xenc:ReferenceList>
      <xenc:DataReference URI='#Enc1' />
    </xenc:ReferenceList>
  </xenc:EncryptedKey>
  <xenc:EncryptedData Id='Enc1'>
    <xenc:EncryptionMethod Algorithm='http://www.w3.org/2001/04/xmlenc#tripledes-cbc' />
    <xenc:CipherData>
      <xenc:CipherValue>
9jFtYcLSlDZQBMjKfT7ctg6Jy+6sC8YORhiPeTvOjug7ozY2SRHGuLt8G/vf2f/f4IdF0ewiDOpq...
      </xenc:CipherValue>
    </xenc:CipherData>
  </xenc:EncryptedData>
</wsse:Security>

9.2.2 Prohibited xenc:EncryptedKey attributes

These prohibited attributes are not needed for xenc:EncryptedKey elements used to secure SOAP messages.

R3209 Any ENCRYPTED_KEY MUST NOT specify a Type attribute.

R5622 Any ENCRYPTED_KEY MUST NOT specify a MimeType attribute.

R5623 Any ENCRYPTED_KEY MUST NOT specify a Encoding attribute.

9.2.3 xenc:EncryptedData contents

The ds:KeyInfo element is useful for determining the security token with which the relevant key material is associated.

R5629 An ENCRYPTED_DATA which is not referenced from an ENCRYPTED_KEY MUST contain a ds:KeyInfo

9.2.4 xenc:EncryptedData attributes

All xenc:EncryptedData elements will be refered to from an xenc:Reference list. Such references use shorthand XPointers, hence this requirement.

R5624 Any ENCRYPTED_DATA MUST have an Id attribute.

9.2.5 References from xenc:EncryptedData

Security token references are intended to refer directly to security tokens. This requirement prohibits cases where a reference is made to a ds:KeyInfo which in turn contains another reference.

R3211 Any SECURITY_TOKEN_REFERENCE inside an ENCRYPTED_DATA MUST NOT reference a ds:KeyInfo element.

9.2.6 xenc:EncryptionMethod mandatory

Specifying the encryption algorithm used to perform the encryption makes messages more self-describing and aids interoperability.

R5601 Any ENCRYPTED_DATA MUST have an xenc:EncryptionMethod child element.

R5603 Any ENCRYPTED_KEY MUST have an xenc:EncryptionMethod child element.

INCORRECT:

<!-- This example is incorrect because the xenc:EncryptedKey element is missing an xenc:EncryptionMethod child element -->

<xenc:EncryptedKey>
   <ds:KeyInfo>
      <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>
   </ds:KeyInfo>
   <xenc:CipherData>
      <xenc:CipherValue>
         XZEEVABD3L9G+VNTCDiDTE7WB1a4kILtz5f9FT747eE=       
      </xenc:CipherValue>
   </xenc:CipherData>
   <xenc:ReferenceList>
      <xenc:DataReference URI='#Enc1' />
   </xenc:ReferenceList>
</xenc:EncryptedKey>

INCORRECT:

<!-- This example is incorrect because the xenc:EncryptedData element is missing an xenc:EncryptionMethod child element -->

<xenc:EncryptedData Id='Enc1'>
   <xenc:CipherData>
      <xenc:CipherValue>
9jFtYcLSlDZQBMjKfT7ctg6Jy+6sC8YORhiPeTvOjug7ozY2SRHGuLt8G/vf2f/f4IdF0ewiDOpq...
      </xenc:CipherValue>
   </xenc:CipherData>
</xenc:EncryptedData>

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">
lui+Jy4WYKGJW5xM3aHnLxOpGVIpzSg4V486hHFe7sHET/uxxVBovT7JV1A2RnWSWkXm9jAEdsm/...
  </wsse:BinarySecurityToken>
  <xenc:EncryptedKey>
    <xenc:EncryptionMethod Algorithm='http://www.w3.org/2001/04/xmlenc#rsa-1_5' />
    <ds:KeyInfo>
      <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>
    </ds:KeyInfo>
    <xenc:CipherData>
      <xenc:CipherValue>
        XZEEVABD3L9G+VNTCDiDTE7WB1a4kILtz5f9FT747eE=       
      </xenc:CipherValue>
    </xenc:CipherData>
    <xenc:ReferenceList>
      <xenc:DataReference URI='#Enc1' />
    </xenc:ReferenceList>
  </xenc:EncryptedKey>
  <xenc:EncryptedData Id='Enc1'>
    <xenc:EncryptionMethod Algorithm='http://www.w3.org/2001/04/xmlenc#tripledes-cbc' />
    <xenc:CipherData>
      <xenc:CipherValue>
9jFtYcLSlDZQBMjKfT7ctg6Jy+6sC8YORhiPeTvOjug7ozY2SRHGuLt8G/vf2f/f4IdF0ewiDOpq...
      </xenc:CipherValue>
    </xenc:CipherData>
  </xenc:EncryptedData>
</wsse:Security>

9.2.7 xenc:EncryptedKey/@Recipient

This attribute is prohibited because the soap:actor attribute conveys the same information.

R5602 Any ENCRYPTED_KEY MUST NOT contain a Recipient attribute.

INCORRECT:

<!-- This example is incorrect because the xenc:EncryptedKey element has a Recipient attribute  -->

<xenc:EncryptedKey Recipient='Bert'>
   <xenc:EncryptionMethod Algorithm='http://www.w3.org/2001/04/xmlenc#rsa-1_5' />
   <ds:KeyInfo>
      <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>
   </ds:KeyInfo>
   <xenc:CipherData>
      <xenc:CipherValue>
         XZEEVABD3L9G+VNTCDiDTE7WB1a4kILtz5f9FT747eE=       
      </xenc:CipherValue>
   </xenc:CipherData>
   <xenc:ReferenceList>
      <xenc:DataReference URI='#Enc1' />
   </xenc:ReferenceList>
</xenc:EncryptedKey>

9.2.8 ds:KeyInfo with Encryption

The ds:KeyInfo element allows for many different child elements. The Profile mandates a single element, wsse:SecurityTokenReference, which is needed to reference security tokens.

R5424 A ds:KeyInfo element in an ENCRYPTED_KEY MUST have exactly one child element.

R5425 A ds:KeyInfo element in an ENCRYPTED_DATA MUST have exactly one child element.

R5426 The child element of a ds:KeyInfo element in an ENCRYPTED_KEY MUST be a SECURITY_TOKEN_REFERENCE.

R5427 The child element of a ds:KeyInfo element in an ENCRYPTED_DATA MUST be a SECURITY_TOKEN_REFERENCE.

9.2.9 xenc:EncryptedData

In order for the data to be protected from inspection, it must be replaced with the corresponding encrypted content.

R5606 Within a SECURE_ENVELOPE, encrypted element or element content encrypted as a result of an encryption step MUST be replaced by a corresponding ENCRYPTED_DATA.

9.2.10 SOAP Envelope

Encrypting any of the listed elements would break the SOAP processing model and so is prohibited.

R5607 When encryption is used, the SECURE_ENVELOPE MUST still be a valid SOAP Envelope. Specifically, the Envelope, Header, or Body elements MUST NOT be encrypted.

9.3 Element References in XML Encryption

9.3.1 Reference to Elements by Shorthand XPointer (XMLENC)

The above requirements ensure that Shorthand XPointer References are used where approriate and that they refer to the correct attribute values.

R5608 When referring from an xenc:DataReference or xenc:KeyReference in an ENCRYPTION_REFERENCE_LIST to an element that carries a wsu:Id attribute or a Local ID attribute defined by either XML Signature or XML Encryption, a Shorthand XPointer Reference MUST be used to refer to that element.

R5613 When referring from a an xenc:DataReference or xenc:KeyReference in an ENCRYPTED_KEY_REFERENCE_LIST to an element that carries a wsu:Id attribute or a Local ID attribute defined by either XML Signature or XML Encryption, a Shorthand XPointer Reference MUST be used to refer to that element.

R3006 When a xenc:DataReference/@URI or xenc:KeyReference/@URI in a ENCRYPTION_REFERENCE_LIST is a Shorthand XPointer Reference to an XML Signature element, the reference value MUST be a Local ID defined by XML Signature.

R3007 When a xenc:DataReference/@URI or xenc:KeyReference in a ENCRYPTED_KEY_REFERENCE_LIST is a Shorthand XPointer Reference to an XML Signature element, the reference value MUST be a Local ID defined by XML Signature.

R5609 When an xenc:DataReference/@URI or xenc:KeyReference/@URI in an ENCRYPTION_REFERENCE_LIST is a Shorthand XPointer Reference to an XML Encryption element, the reference value MUST be a Local ID defined by XML Encryption.

R5610 When an xenc:DataReference/@URI or xenc:KeyReference/@URI in an ENCRYPTED_KEY_REFERENCE_LIST is a Shorthand XPointer Reference to an XML Encryption element, the reference value MUST be a Local ID defined by XML Encryption.

R5611 When an xenc:DataReference/@URI or xenc:KeyReference/@URI in an ENCRYPTION_REFERENCE_LIST is a Shorthand XPointer Reference to an element not defined by XML Signature or XML Encryption, the reference value SHOULD be a wsu:Id.

R5612 When an xenc:DataReference/@URI or xenc:KeyReference/@URI in an ENCRYPTED_KEY_REFERENCE_LIST is a Shorthand XPointer Reference to an element not defined by XML Signature or XML Encryption, the reference value SHOULD be a wsu:Id.

9.4 XML Encryption Algorithms

9.4.1 Data Encryption Algorithms

Data encryption algorithms are used for encrypting elements and element content. Industries, organizations, and application domains are currently choosing from a variety of data encryption algorithms based on reasons including performance, security characteristics, and regulatory compliance. A set of the most commonly chosen and widely deployed data encryption algorithms are supported by the Basic Security Profile in order to avoid disenfranchising existing applications. At some point in the future, if and when consensus is reached for a single data encryption algorithm the Basic Security Profile 1.0 may be revised to constrain instances to use only that algorithm.

R5620 Any xenc:EncryptionMethod/@Algorithm attribute in an ENCRYPTED_DATA MUST have a value of "http://www.w3.org/2001/04/xmlenc#tripledes-cbc", "http://www.w3.org/2001/04/xmlenc#aes128-cbc" or "http://www.w3.org/2001/04/xmlenc#aes256-cbc"

The 3DES algorithm ("http://www.w3.org/2001/04/xmlenc#tripledes-cbc") is widely implemented and deployed in existing practice. The AES algorithm is relatively new and becoming widely implemented and deployed. The 128-bit variation of AES ("http://www.w3.org/2001/04/xmlenc#aes128-cbc") is relatively faster but weaker than the 256-bit variation ("http://www.w3.org/2001/04/xmlenc#aes256-cbc").

9.4.2 Key Transport Algorithms

Key transport algorithms are used for encrypting symmetric encryption keys, such as data encryption keys, with asymmetric encryption keys. This technique allows for encryption of relatively large amount of data with efficient symmetric encryption and securely transmitting the associated relatively small symmetric encryption key. Industries, organizations, and application domains are currently choosing from a variety of key transport algorithms based on reasons including performance, security characteristics, and regulatory compliance. A set of the most commonly chosen and widely deployed key transport algorithms are supported by the Basic Security Profile in order to avoid disenfranchising existing applications. At some point in the future, if and when consensus is reached for a single key transport algorithm the Basic Security Profile 1.0 may be revised to constrain instances to use only that algorithm.

R5621 When used for Key Transport, any xenc:EncryptionMethod/@Algorithm attribute in an ENCRYPTED_KEY MUST have a value of "http://www.w3.org/2001/04/xmlenc#rsa-1_5" or "http://www.w3.org/2001/04/xmlenc#rsa-oaep-mgf1p"

The RSA (PKCS#1.5) algorithm ("http://www.w3.org/2001/04/xmlenc#rsa-1_5") is widely implemented and deployed in existing practice. The RSA-OAEP algorithm ("http://www.w3.org/2001/04/xmlenc#rsa-oaep-mgf1p") is relatively new and becoming widely implemented and deployed.

9.4.3 Key Wrap Algorithms

Key wrap algorithms are used for encrypting symmetric encryption keys, such as data encryption keys, with symmetric encryption keys. Industries, organizations, and application domains are currently choosing from a variety of key wrap algorithms based on reasons including performance, security characteristics, and regulatory compliance. A set of the most commonly chosen and widely deployed key wrap algorithms are supported by the Basic Security Profile in order to avoid disenfranchising existing applications. At some point in the future, if and when consensus is reached for a single key wrap algorithm the Basic Security Profile 1.0 may be revised to constrain instances to use only that algorithm.

R5625 When used for Key Wrap, any xenc:EncryptionMethod/@Algorithm attribute in an ENCRYPTED_KEY MUST have a value of "http://www.w3.org/2001/04/xmlenc#kw-tripledes", "http://www.w3.org/2001/04/xmlenc#kw-aes128", or "http://www.w3.org/2001/04/xmlenc#kw-aes256"

The 3DES algorithm ("http://www.w3.org/2001/04/xmlenc#kw-tripledes") is widely implemented and deployed in existing practice. The AES algorithm is relatively new and becoming widely implemented and deployed. The 128-bit variation of AES ("http://www.w3.org/2001/04/xmlenc#kw-aes128") is relatively faster but weaker than the 256-bit variation ("http://www.w3.org/2001/04/xmlenc#kw-aes256").

10. Algorithms

This section provides guidance, and in some cases requirements, concerning the use of various categories of algorithms.

10.1 Transport Level Security Algorithms

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.

10.1.1 Mandatory ciphersuites

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

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

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

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

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

10.1.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.

10.1.3 Discouraged ciphersuites

The ciphersuites defined in the SSL and TLS specifications that use anonymous Diffie-Helman ( i.e. those that have DH_anon in their symbolic name ) are vulnerable to man-in-the-middle attacks. 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.

10.1.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".

11. Relationship of Basic Security Profile as an Extension to Basic Profile

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 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 of the Basic Security Profile 1.0 incorporates the following specifications by reference:

11.1 Basic Profile Clarifications

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.

11.1.1 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

11.1.2 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

11.1.3 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

11.1.4 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

11.1.5 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.

11.1.6 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.

11.1.7 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.

11.1.8 BP Requirement R1029

This clarifies the Basic Profile's R1029 to reflect the fact that transmission of security related faults may increase the vulnerablility 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.

12. Attachment Security

This section of the Basic Security Profile 1.0 incorporates the following specifications by reference:

The section provides guidance for protecting attachments when they are used with SOAP Messages. As is explained in Section 3 Conformance all features described in the Basic Security Profile 1.0, including support for attachments and security for attachments in any form by any instance is not required.

SSL/TLS may be used to provide authentication, integrity and confidentiality protection, on a hop-by-hop basis, for an entire HTTP Message. This includes HTTP Headers, the SOAP Envelope, and all MIME_PARTs.

SSL/TLS does not provide protection, except between adjacent HTTP Nodes, for HTTP Messages when the SOAP Message Path contains SOAP Intermediaries. An instance should not use SSL/TLS without WSS with Message Exchange Patterns (MEPs) that may contain SOAP intermediaries or when these security functions are required to be performed independently of the connection.

WSS may be used to provide authentication, integrity and confidentiality protection for a subset of the SOAP Message and associated attachments. WSS provides protection for SOAP Messages and attachments when the SOAP Message Path contains SOAP Intermediaries. An instance should use WSS with MEPs that may contain SOAP Intermediaries or when these security functions are required to be performed independently of the transport layer connection.

An instance may use SSL/TLS in conjunction with WSS if warranted by application security requirements. This combination provides integrity and confidentiality protection for the entire HTTP Message (on a hop-by-hop basis) including HTTP Headers, SOAP Envelope, and all MIME_PARTs.

Application level security mechanisms, including XML Signature, XML Encryption, PKCS#7, S/MIME, etc. for attachment data may also be used by a instance where appropriate, but statements regarding the interoperability of such mechanisms are out of scope for the Basic Security Profile 1.0.

The Basic Security Profile 1.0 describes one attachment security mechanism and URI.

12.1 SOAP with Attachments

The following specifications (or sections thereof) are referred to in this section of the Basic Security Profile 1.0:

12.1.1 Conformance

The Basic Security Profile is an extension profile to the Basic Profile, and thus this requirement makes it explicit that when using the WSS SwA profile in conformance to the BSP SwA profile section that the messages containing attachments must conform to the WS-I Attachments Profile 1.0. This is consistent with the WSS SwA profile and good practice.

R6001 The SECURE_MESSAGE MUST conform to Attachments Profile 1.0.

12.1.2 Relationship between Parts

The WSS SwA profile outlines how attachments may be secured when conveyed in conjunction with a primary SOAP envelope. The SOAP envelope is contained in a distinct MIME part. Attachment parts can contain arbitrary content as indicated by the MIME-Type, and an attachment could contain content with nested MIME parts. In order to enable interoperable processing at the SOAP messaging layer it is important to only secure the top-level MIME attachments that are in the same Multipart structure as the MIME part conveying the primary SOAP envelope.

R6002 A signed and/or encrypted MIME_PART MUST be at the same MIME level as the root MIME_PART containing the SECURE_ENVELOPE.

12.1.3 Encryption and Root Part

It is essential that SOAP processors (intermediaries and ultimate SOAP receiver) be able to process the primary SOAP envelope. For this reason, the MIME part containing the primary SOAP envelope must not be secured using the WSS SwA profile mechanisms. This includes encryption, since an encrypted SOAP structure cannot be processed, and signing, since this would preclude intermediary processing of the SOAP message, since this often involves adding, or removing headers. Note that WSS security may be applied to portions of the primary SOAP envelope in conformance with the BSP, but not by using attachment security mechanisms.

R6003 A root MIME_PART MUST NOT be referenced by a REFERENCE, ENCRYPTION_REFERENCE_LIST, or ENCRYPTED_KEY_REFERENCE_LIST.

12.2 Signed Attachments

12.2.1 Reference to Signed Attachments

The WSS SwA profile requires that cid: references be used to refer to MIME attachment parts for signing. This BSP statement reiterates that requirement for testability.

R6100 A REFERENCE to a signed MIME_PART MUST use a URI attribute of the form "cid:partToBeSigned".

12.2.2 Attachment Transforms

The WSS SwA profile requires that a ds:Reference to an attachment part that is signed must use a transform specifying either the Attachment-Complete-Signature-Transform or the Attachment-Content-Signature-Transform URIs. This statement reiterates that requirement for testability.

R6101 A REFERENCE to a MIME_PART MUST use a transform specifying by the URI "...#Attachment-Content-Signature-Transform" or "...#Attachment-Complete-Signature-Transform". This transform and URI will be specified before the final version of the Basic Security Profile 1.0 is released. The anticipated venue to define this Transform is the OASIS WSS TC.

12.2.3 XML C14N

Signature digest calculations require that the exact same input be provided to the digest algorithm both when the signature is created and when it is verified. Canonicalization is required to ensure the same literal representation despite changes due to message transformation during transport. XML exclusive canonicalization is required as part of the Attachment-Complete-Signature-Transform or Attachment-Content-Signature-Transform processing. A separate transform for canonicalization should not be provided since it is already included as part of the processing associated with these transforms.

R6102 A REFERENCE to a MIME_PART containing XML MUST NOT specify an explicit XML canonicalization transform in the ds:Reference transforms list

R6103 The output of the Attachment-Content-Signature-Transform or the XML octet stream portion of the output of the Attachment-Complete-Signature-Transform must be consistent with Exclusive XML canonicalization without comments having been performed when creating that output.

12.2.4 Digest values

Signature digest calculations require that the exact same input be provided to the digest algorithm both when the signature is created and when it is verified. Canonicalization is required to ensure the same literal representation despite changes due to message transformation during transport, for example line ending changes. MIME canonicalization algorithms are required for interoperability by WSS SwA profile. This statement reiterates that requirement for testability.

R6104 A REFERENCE to a MIME_PART not containing XML MUST include a ds:DigestValue calculated using MIME canonicalization according to the requirements of the MIME Type.

12.2.5 Content-Type

Signature digest calculations require that the exact same input be provided to the digest algorithm both when the signature is created and when it is verified. Canonicalization is required to ensure the same literal representation despite changes due to message transformation during transport. It is essential to determine the correct type of canonicalization to perform, based on the MIME_PART content type. For this reason it is required that the Content-Type be explicitly stated with a Content-Type MIME header.

R6106 A MIME_PART referenced by a REFERENCE which specifies "...#Attachment-Complete-Signature-Transform" MUST have a Content-Type MIME-header.

R6107 A MIME_PART referenced by a REFERENCE which specifies "...#Attachment-Content-Signature-Transform" MUST have a Content-Type MIME-header.

12.3 Encrypted Attachments

12.3.1 References to Encrypted Attachments

The WSS SwA profile requires that an EncryptedData element in the primary SOAP envelope be used to reference the encrypted MIME part. This statement reiterates that requirement for testability.

R6200 An encrypted MIME_PART MUST be referenced using an ENCRYPTED_DATA.

12.3.2 Type attribute

The WSS SwA profile requires that an EncryptedData element in the primary SOAP envelope that references an encrypted MIME part specify the Type as either AttachmentFoo-Content-Only or AttachmentFoo-Complete so that it can be processed correctly upon decryption. This statement reiterates that requirement for testability.

R6201 An ENCRYPTED_DATA that references a MIME_PART MUST include a Type attribute with the value "...#AttachmentFoo-Content-Only" or "...#AttachmentFoo-Complete".

12.3.3 Reference URIs

The WSS SwA profile requires that the EncryptedData element in the primary SOAP envelope that references an encrypted MIME part must reference the Cipherdata using the same cid: as the original attachment cid:, simplifying processing. This statement reiterates that requirement for testability.

R6202 An ENCRYPTED_DATA that references a MIME_PART MUST contain a xenc:CipherData/xenc:CipherReference element with a URI attribute having the same URI as the original MIME_PART.

12.3.4 Content

The WSS SwA profile specifies that when an attachment is encrypted, the resulting EncryptedData element be placed in the wsse:Security header in the primary SOAP envelope and that the cipherdata be placed in the attachment part. This statement reiterates the requirement of replacing the content of the attachment with the cipherdata, for testability.

R6203 The content of a MIME_PART encrypted according to the WSS SwA profile MUST be replaced by the cipher value that results from encrypting the MIME part and is referenced from the CipherReference in the EncryptedData element.

13. Security Considerations

13.1 SOAPAction Header

13.1.1 SOAPAction header

C2010 A RECEIVER SHOULD NOT rely on the value of the SOAPAction HTTP header when processing a SECURE_ENVELOPE.

13.2 Clock Synchronization

13.3 Security Token Substitution

13.3.1 Security Token Substitution

C5440 When the signer's SECURITY_TOKEN is an INTERNAL_SECURITY_TOKEN, the SIGNATURE MAY include a ds:Reference that refers to the signer's SECURITY_TOKEN in order to prevent substitution with another SECURITY_TOKEN that uses the same key. C

C5441 When the signer's SECURITY_TOKEN is an EXTERNAL_SECURITY_TOKEN, the SIGNATURE MAY include a ds:Reference that refers to the SECURITY_TOKEN_REFERENCE that refers to the signer's SECURITY_TOKEN using the Security Token Dereferencing Transform in order to prevent substitution of another SECURITY_TOKEN that uses the same key. C

13.3.2

C5442 When an encryption key to be used in subsequent messages is provided in an INTERNAL_SECURITY_TOKEN, a SIGNATURE MAY include a ds:Reference that refers to the signer's SECURITY_TOKEN in order to prevent substitution with another SECURITY_TOKEN that uses the same key. C

13.4 Uniqueness of ID attributes

13.5 Signing Security Tokens

13.6 Signing Username Tokens

13.7 Signing Binary Tokens

13.8 Signing XML Tokens

13.9 Replay of Username Token

A sender that includes a Nonce child in a UsernameToken element should anticipate that the receiver may refuse to process the message due to either an accidental collision or transport layer delays. Therefore, if it decides to retry transmission, it should do so with a new Nonce.

Unless other mechanisms are used to protect against replay of the username token, service providers should retain nonces in a store that is shared between all SOAP nodes (and within a distributed SOAP node all "components") that can be authorized using the same passwords.

The policy that allows service providers to forget nonces may be based on any considerations that the service considers relevant. When a nonce is forgotten the server should ensure that in the future it rejects UsernameTokens with a Created time that is earlier than the forgotten nonce.

13.9.1 Replay of Username Token

C4210 Any SECURITY_TOKEN named wsse:UsernameToken that contains a wsse:Nonce element and a wsse:Password element with a Type attribute value of "http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-username-token-profile-1.0#PasswordText" SHOULD be referenced by a ds:Reference in a SIGNATURE in order to prevent replay.

C4211 Any SECURITY_TOKEN named wsse:UsernameToken that contains a wsu:Created element and a wsse:Password element with a Type attribute value of "http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-username-token-profile-1.0#PasswordText" SHOULD be referenced by a ds:Reference in a SIGNATURE in order to prevent replay.

13.10 Use of Digest vs. Cleartext Password

A sending application utilizing password authentication must decide whether to use a cleartext password or a password digest (The sender needs to know via some out-of-band mechanism and/or prior arrangement which mechanisms the receiver supports). The digest should always be preferred if it can be used, as the digest algorithm does not reveal the password and can protect against replay of the password. (It does not however, protect against offline guessing or brute force attacks.)

Password digests can only be used in situations where both sender and receiver can start with the same secret value (e.g., the cleartext password or a hash of the password). The following are criteria for considering when to use digests vs. cleartext:

2. If the receiver can access a value that can be derived by the sender directly from the cleartext password (e.g., the receiver has access to a SHA1 hash of the password), the derived value (e.g. the hash) may be used in the digest.

3. If the sender needs extra information to derive the value available to the receiver, it will not be feasible to use password digest, even though the information is not intentionally secret. For example, UNIX systems add a salt value to each password before hashing it. It is infeasible for the sender to discover the salt value required for a specific username.

4. If the receiver does not have access to any password value, derived or otherwise, but merely the ability to test a username/password combination for validity, a digest may not be used. An example of this is when the username/password combination is presented to a database, directory or mainframe system for verification.

When sending any form of a password, cleartext or digest, confidentiality services are strongly recommended to prevent its value from being revealed or from offline guessing.

13.11 Encryption with Signatures

When a message contains a data value which does not have a significant number of probable variations and that data is signed and then encrypted, it is recommended that the sender either include some suitably random value such as a wsse:Nonce in the data, or encrypt the related ds:DigestValue element in order to protect the confidentiality of the data.

An adversary can compute the digest for each data values and compare them against the digests in the signature thereby deducing the encrypted data value. This type of attack is most likely to be successful when there are a relatively small set of probable data values. Therefore the threat can be mitigated by introduction of some random value into the original data or encryption of the digest.

13.11.1 Encrypt DigestValue

C5630 A SIGNATURE computed over data that is subsequently encrypted SHOULD also be encrypted in order to prevent plaintext guessing attacks when the probable set of data values is small.

13.12 Possible Operational Errors

Under SOAP processing rules, there is no way a sender can be sure that a message containing a security header addressed to a given Role/Actor will ever reach a node that is taking on that Role/Actor. If not, the specified security processing will not occur.

Under SOAP processing rules, there is no way a sender can determine in what order nodes taking on specific Role/Actor's will be reached. If signatures and encryptions specified in different security headers overlap, verification and decryption operations may fail as a result of being processed in the wrong order. (Generally overlapping signatures will verify regardless of the order of verification.) This problem can be avoided by never specifying overlapping operations in distinct headers, however application requirements may not prevent this. For example, many senders may wish to include the entire Body under a signature, possibly before or after encrypting portions of it.

Under SOAP processing rules, there is no way a sender can determine which particular secrets are possessed by a node taking on a given Role/Actor. If a node is required to perform decryption or verify an HMAC and it does not posses the necessary secret, it will be unable to perform these operations. This will not only impact its operation, but in the case it is an intermedairy may make it possible for nodes receiving the message subsequently from performing security processing correctly due to overlapping operations, even when that node does posses the necessary secrets.

If a namespace that is in fact visibly used within some text to be Canonicalized via the Exclusive C14N Algorithm is included in the InclusiveNamespaces PrefixList, then under some valid transformations of the transmitted document signature verification may spuriously fail, because the Canonicalized form shifts the location of of a namespace declaration. This case is expected to be rare in practice.

Appendix A: Referenced Specifications

The following specifications' requirements are incorporated into the Basic Security Profile 1.0 by reference, except where superseded by the Profile:

Appendix B: Extensibility Points

This section identifies extensibility points, as defined in "Scope of the Basic Security Profile 1.0," for the Basic Security Profile 1.0's component specifications.

These mechanisms are out of the scope of the Basic Security Profile 1.0; their use may affect interoperability, and may require private agreement between the parties to a Web service.

Appendix C: Acknowledgements

This document is the work of the WS-I Basic Security Profiles Working Group, whose members have included:

Steve Anderson (OpenNetwork), Paula Austel (IBM), Siddharth Bajaj (Verisign), Frank Balluffi (Deutsche Bank), Abbie Barbir (Nortel), David Baum (Kantega AS), Randy Bias (Grand Central Communications), Tim Bond (webMethods, Inc.), Heidi Buelow (Quovadx), David Burdett (Commerce One, Inc.), Ted Burghart (Hitachi, Ltd.) Symon Chang (Commerce One, Inc.), Richard Chennault, (Kaiser Permanente), Dipak Chopra (SAP AG), Jamie Clark (OASIS), Edward Cobb (BEA Systems, Inc.), David Cohen (Merrill Lynch), Brett Cooper, (Accenture), Ugo Corda (SeeBeyond Technology), Paul Cotton (Microsoft Corporation), Suresh Damodaran, (Rosettanet), Mark Davis (Sarvega, Inc.), Alex Deacon (Verisign), Thomas DeMartini (ContentGuard, Inc.), Blake Dournaee (Sarvega, Inc.), Rob Drew (Charlse Schwab), Gregory Elkins (Reed Elsevier), Mark Ericson (Mindreef), Jon Oyvind Eriksen (Kantega AS), Chris Ferris (IBM), Bob Freund, (Hitachi), Edwin Goei (Sun Microsystems), Grant Goodale (Reactivity, Inc.), Marc Goodner (SAP AG), Phil Goodwin (Sun Microsystems), Marc Graveline (Cognos, Inc.), Eric Gravengaard (Reactivity, Inc.), Thomas Gross (IBM), Martin Gudgin (Microsoft Corporation), Marc Hadley (Sun Microsystems), Mark Hapner (Sun Microsystems), Nathan Harris (Kaiser Permanente), Bret Hartman (Datapower Technology, Inc.), Frederick Hirsch (Nokia), Jason Hogg (Microsoft Corporation), Maryann Hondo (IBM), Lawrence Hsiung (Quovadx), Tony Huber (Commerce Quest), Jim Hughes (Hewlett-Packard), Michael Hui (Computer Associates), Brian Jackson (Avanade, Inc.), Steve Jenisch (SAS Institute), Erik Johnson (Epicor), Chris Kaler (Microsoft Corporation), Anish Karmarkar (Oracle Corporation), Dana Kaufman, (Forum Systems), Manveen Kaur (Sun Microsystems), Slava Kavsan (RSA Security), Paul Knight (Nortel Networks), Chris Kurt (Microsoft Corporation), Kelvin Lawrence (IBM), Hal Lockhart (BEA Systems), Brad Lund (Intel Corporation), Jim Luth (OPC Foundation), Paul Madsen (Entrust, Inc.), Eve Maler (Sun Microsystems), Skip Marler (Parasoft), Axl Mattheus (Sun Microsystems), Michael McIntosh (IBM), Craig Milhiser, (Ascential), Chris Miller (Accenture), Dale Moberg (Cyclone Commerce), Ron Monzillo (Sun Microsystems), K. Scott Morrison, (Layer 7) Tim Moses (Entrust, Inc.), Tony Nadalin (IBM), Nataraj Nagaratnam (IBM), Andrew Nash (RSA Security), Hsin Ning (Bestning Technologies), Eisaku Nishiyama (Hitachi, Ltd.), Mark Nottingham (BEA Systems, Inc.), TJ Pannu (ContentGuard, Inc.), Martine Pean (Quovadx), Robert Philpott (RSA Security), Dave Prout (BT), Joe Pruitt (F5 Networks, Inc.), Eric Rejkovic (Oracle Corporation), Matt Recupito (Accenture), Jason Rouault (Hewlett-Packard), Rich Salz (Datapower Technology, Inc.), Matt Sanchez (Webify Solutions, Inc. ), Jerry Schwarz (Oracle Corporation), Senthil Sengodan (Nokia), Shawn Sharp (Cyclone Commerce), Aslak Siira (F5 Networks, Inc.), David Solo (Citigroup, Inc. ), Davanum Srinivas (Computer Associates), Raghavan Srinivas (Sun Microsystems), John Stanton (Defense Information Systems Agency), Andrew Stone (Accenture), Julie Surer (MITRE), Wes Swenson (Forum Systems), Dino Vitale (Citigroup, Inc.), Jonathan Wenocur (Datapower Technology, Inc.), Pete Wenzel (SeeBeyond Technology), Ian White (Micro Focus)

Basic Security Profile Version 1.0

Working Group Draft

2005-06-14

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

4. Transport Layer Security

4.1 SSL and TLS

4.1.1 Use of SSL 2.0

5. SOAP Message Security

5.1 Security Tokens

5.1.1 Binary Security Token EncodingType Attribute

5.1.2 Binary Security Token ValueType Attribute

5.2 SecurityTokenReferences

5.2.1 Internal References

5.2.2 Shorthand XPointer References

5.2.3 References to Preceding Security Tokens

5.2.4 Direct Preferred to Embedded for Internal References

5.2.5 Direct Required When Possible for External References

5.2.6 Format of Embedded References

5.2.7 Key Identifier for External References

5.2.8 Key Name References Prohibited

5.2.9 KeyIdentifier/@ValueType Attribute

5.2.10 KeyIdentifier/@EncodingType Attribute

5.2.11 References from within Embedded Tokens

5.2.12 Embedded Token Content

5.2.13 Reference from wsse:SecurityTokenReference to wsse:SecurityTokenReference

5.2.14 wsse:SecurityTokenReference/Reference ValueType Attribute

5.2.15 wsse:SecurityTokenReference content

5.2.16 wsse:SecurityTokenReference/Reference requires URI attribute

5.2.17 wsse:SecurityTokenReference Dereferencing Transform

5.2.18 Security Token References across security headers prohibited

5.3 Timestamps

5.3.1 wsu:Timestamp/wsu:Created

5.3.2 Occurence constraints on wsu:Created and wsu:Expires

5.3.3 Leap Seconds Not Allowed

5.3.4 Timestamp ValueType

5.3.5 Timestamp Format

5.3.6 Timestamp Resolution

5.3.7 wsu:Timestamp inside wsse:Security header

5.4 wsu:Id References

5.4.1 wsu:Id Attribute Uniqueness

5.5 wsse:Security Processing Order

5.5.1 Order of Processing

5.6 SOAP Actor

5.6.1 SOAP Actor Value

6. Username Token Profile

6.1 Token Usage

6.1.1 wsse:UsernameToken/wsse:Password/@Type

6.1.2 PasswordDigest

6.1.3 ValueType attribute

6.1.4 EncodingType attribute

6.1.5 Reference by KeyIdentifier

6.1.6 Key Derivation

7. X.509 Certificate Token Profile

7.1 Token Types

7.1.1 Certificate Path Format

7.1.2 KeyIdentifier

7.1.3 KeyIdentifier EncodingType

8. XML-Signature

8.1 General Constraints on XML Signature

8.1.1 Signature Content

8.1.2 Signature Types

8.2 Element References in XML Signature

8.2.1 Reference to Elements by Shorthand XPointer (XMLDSIG)

8.2.2 Reference to Elements by XPath Expression

8.3 XML Signature Algorithms