WS-I

Basic Security Profile Version 1.0

Working Group Draft

Date: 2004/05/12 10:20:46

This version:
http://www.ws-i.org/Profiles/BasicSecurityProfile-1.0-2004-05-12.html
Latest version:
http://www.ws-i.org/Profiles/BasicSecurityProfile-1.0.html
Editors:
Abbie Barbir, Nortel Networks
Martin Gudgin, Microsoft
Michael McIntosh, IBM
Administrative contact:
secretary@ws-i.org

Abstract

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

Feedback on this document should be directed to wsi_secprofile_comment@lists.ws-i.org.

Table of Contents

1. Introduction
1.1. Guiding Principles
1.2. Notational Conventions
2. Scope of the Profile
3. Profile Conformance
3.1. Conformance of Artifacts
3.2. Conformance of Message Senders
3.3. Conformance of Message Receivers
3.4. Claiming Conformance
4. Transport Layer Security
4.1. SSL and TLS
4.1.1. Use of SSL 2.0
4.2. Security Considerations
4.2.1. SOAPAction Header
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. Use of wsse:SecurityTokenReference
5.2.2. Internal References
5.2.3. Shorthand XPointer References
5.2.4. References to Preceding Security Tokens
5.2.5. Direct Preferred to Embedded for Internal References
5.2.6. Direct Required When Possible for External References
5.2.7. Format of Embedded References
5.2.8. Key Identifier for External References
5.2.9. Key Name References Prohibited
5.2.10. ds:KeyInfo/wsse:SecurityTokenReference in XML Signatures
5.2.11. ds:KeyInfo/wsse:SecurityTokenReference in XML Encryption
5.2.12. KeyIdentifier/@ValueType Attribute
5.2.13. Children of wsse:Embedded
5.2.14. Reference from wsse:SecurityTokenReference to wsse:SecurityTokenReference
5.2.15. wsse:SecurityTokenReference/Reference ValueType Attribute
5.2.16. wsse:SecurityTokenReference constraints
5.2.17. wsse:SecurityTokenReference Dereferencing Transform
5.3. Timestamps
5.3.1. wsu:Timestamp
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. wsse:Nonce
6.1.4. ValueType attribute
6.1.5. Reference by KeyIdentifier
6.1.6. Key Derivation
6.1.7. Sign UsernameToken
7. X.509 Certificate Token Profile
7.1. Token Types
7.1.1. Certificate Path
7.1.2. KeyIdentifier
7.1.3. Use of SecurityTokenReference
8. XML-Signature
8.1. General Constraints on XML Signature
8.1.1. Types of Signatures
8.2. Element References in XML Signature
8.2.1. Reference to element with ID attribute
8.2.2. Reference to element without ID attribute
8.3. XML Signature Algorithms
8.3.1. Use Exclusive C14N
8.3.2. Transform required
8.3.3. Permitted algorithms
8.4. XML Signature Syntax
8.4.1. ds:HMACOutputLength
8.4.2. ds:KeyInfo
8.4.3. ds:Manifest
8.5. Security Considerations
8.5.1. Sign Security Token
9. XML Encryption
9.1. XML Encryption Processing Model
9.1.1. xenc:ReferenceList
9.1.2. xenc:EncryptedKey
9.2. XML Encryption Syntax
9.2.1. Placement
9.2.2. xenc:EncryptedKey attributes
9.2.3. xenc:EncryptedData attributes
9.2.4. References from xenc:EncryptedData
9.2.5. xenc:EncryptionMethod mandatory
9.2.6. xenc:EncryptedKey/@Recipient
9.2.7. ds:KeyInfo/xenc:AgreementMethod prohibited
9.2.8. xenc:EncryptedData
9.2.9. SOAP Envelope
9.3. XML Encryption Algorithms
9.3.1. Permitted Algorithms
9.4. Security Considerations
9.4.1. Encrypt DigestValue
10. Algorithms
10.1. Transport Level Security Algorithms
10.1.1. Mandatory ciphersuites
10.1.2. Recommended ciphersuites
10.1.3. Discouraged ciphersuites
10.1.4. Prohibited ciphersuites
11. Relationship of Basic Security Extension Profile to Basic Profile
11.1. Basic Profile Clarifications
11.1.1. BP Requirement R2301
11.1.2. BP Requirement R2710
11.1.3. BP Requirement R2712
11.1.4. BP Requirement R2724
11.1.5. BP Requirement R2725
11.1.6. BP Requirement R2729
11.1.7. BP Requirement R2738
12. Attachment Security
12.1. SOAP with Attachments
12.1.1. Conformance
12.1.2. Scope
12.2. Signed Attachments
12.2.1. Reference
12.2.2. Transform
12.2.3. Encoding
12.3. Encrypted Attachments
12.3.1. Reference
12.3.2. Content
12.3.3. Transform
13. Security Considerations
Appendix I: Referenced Specifications
Appendix II: Extensibility Points
Appendix III: Acknowledgements

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 introduces the Profile, and relates the philosophy that it takes with regard to interoperability.

Section 2, "Scope of the Profile," delimits the areas where the Profile improves interoperability.

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

Each subsequent section addresses a component of the Profile, and consists of two parts; an overview detailing the component specifications and their extensibility points, followed by subsections that address individual parts of the component specifications. Note that there is no relationship between the section numbers in this document and those in the referenced specifications.

1.1 Guiding Principles

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

No guarantee of interoperability
Although it is impossible to completely guarantee the interoperability of a particular service, the Profile attempts to increase interoperability by addressing the most common problems that implementation experience has revealed to date.
Focus profiling effort
The focus of the profile is the specifications that are explicitly defined as in-scope for the profile. Other specifications are profiled to the minimal extent necessary to allow meaningful profiling of the scoped specifications. This allows an in-depth profile of the scoped specifications with reduced constraining of other specifications.
Application semantics
Although communication of application semantics can be facilitated by the technologies that comprise the Profile, assuring the common understanding of those semantics is not addressed by it.
Testability
When possible, the Profile makes statements that are testable. However, such testability is not required. Preferably, testing is achieved in a non-intrusive manner (e.g., examining artifacts "on the wire"). Note: Due to the nature of cryptographic security, non-intrusive testing may not be possible.
Strength of requirements
The Profile makes strong requirements (e.g., MUST, MUST NOT) wherever feasible; if there are legitimate cases where such a requirement cannot be met, conditional requirements (e.g., SHOULD, SHOULD NOT) are used. Optional and conditional requirements introduce ambiguity and mismatches between implementations.
Restriction vs. relaxation
When amplifying the requirements of referenced specifications (including the Basic Profile 1.0 ), the Profile may restrict them, but does not relax them (e.g., change a MUST to a MAY).
Multiple mechanisms
If a referenced specification allows multiple mechanisms to be used interchangeably, the Profile selects those that are well-understood, widely implemented and useful. Extraneous or underspecified mechanisms and extensions introduce complexity and therefore reduce interoperability.
Future compatibility
When possible, the Profile aligns its requirements with in-progress revisions to the specifications it references (e.g., Web Services Security). This aids implementers by enabling a graceful transition, and assures that WS-I does not 'fork' from these efforts. When the Profile cannot address an issue in a specification it references, this information is communicated to the appropriate body to assure its consideration.
Compatibility with deployed services
Backwards compatibility with deployed Web services is not a goal for the Profile, but due consideration is given to it; the Profile does not introduce a change to the requirements of a referenced specification unless doing so addresses specific interoperability issues.
Focus on interoperability
Although there are potentially a number of inconsistencies and design flaws in the referenced specifications, the Profile only addresses those that affect interoperability.
Conformance targets
Where possible, the Profile places requirements on artifacts (e.g., WSDL descriptions, SOAP messages) rather than the producing or consuming software's behaviors or roles. Artifacts are concrete, making them easier to verify and therefore making conformance easier to understand and less error-prone.
Lower-layer interoperability
The BSP Profile speaks to interoperability at the web-services layer only; it assumes that interoperability of lower-layer protocols ( e.g. TCP, HTTP ) and technologies (e.g. encryption and signature algorithms ) is adequate and well-understood. WS-I does not attempt to assure the interoperability of these protocols and technologies as a whole. This assures that WS-I's expertise in and focus on Web services standards is used effectively.
Do no harm
Interoperability of security technologies does not in and of itself ensure security, and the act of combining new technologies and protocols is especially susceptible to security threats. The profile takes steps to avoid introducing new security threats.

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

Rnnnn Statement text here.

where "nnnn" is replaced by the statement number. Each statement contains exactly one requirement level keyword (e.g., "MUST") and one conformance target keyword (e.g., "SECURE_ENVELOPE").

Some statements clarify the referenced specification(s), but do not place additional constraints upon implementations. For convenience, clarifications are annotated in the following manner: C

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. Scope of the Profile

The scope of the Profile delineates the technologies that it addresses; in other words, the Profile only attempts to improve interoperability within its own scope. Initially, the Profile's scope is bounded by the specifications referenced by it; for a complete list of the Profile's referenced specifications, see Appendix I.

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 as an extensibility point, such a mechanism or parameter is outside the scope of the Profile, and its use is not subject to claims of conformance to this Profile.

Because the use of extensibility points may impair interoperability, their use should be negotiated or documented in some fashion by the parties to a Web service; for example, this could take the form of an out-of-band agreement.

Note that the Profile may still place requirements on the use of an extensibility point, without constraining its range. Also, specific uses of extensibility points may be further restricted by other profiles, to improve their interoperability when used in conjunction with the Profile.

For a complete list of the Profile's extensibility points, see Appendix II.

3. Profile Conformance

Conformance to the Profile is defined by adherence to the set of requirements for a specific target, within the scope of the Profile.

The scope of the Profile is defined above ("Scope of the Profile"); conformance to the Profile is dependent upon conformance to those referenced specifications that are in-scope, except when in conflict with the Profile's Requirements, which take precedence for purposes of conformance.

This Profile consists of Statements providing guidance and constraints on Message Artifacts (such as security headers, signatures and security tokens) and on the behavior of Senders and Receivers.

Requirements state the criteria for conformance to the Profile within its stated scope. They embody refinements, interpretations and clarifications that improve interoperability therein. 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. Requirement identifiers are actually QNames and should be interpreted as if a default namespace whose URI is "http://ws-i.org.profiles/basic-security/core/1.0" is 'in-scope'. For example, the tuple for R9999 would be {"http://ws-i.org.profiles/basic-security/core/1.0" , R9999}

Additional text may be included in the Profile to illuminate requirements (e.g., rationale and examples); however, requirement statements alone should be considered in determining conformance.

Targets allow for the description of conformance in different contexts, to allow conformance testing and certification of artifacts (such as SOAP messages), message senders and message receivers. The sections below describe the Profile's conformance targets.

To allow services to advertise conformance to the Profile, messages can be annotated with conformance claims, which use a URI to assert conformance with a particular profile.

The conformance claim URI for section 6 of this Profile is "http://ws-i.org/profiles/basic-security/username-token/1.0".

The conformance claim URI for section 7 of this Profile is "http://ws-i.org/profiles/basic-security/x.509-certificate-token/1.0".

The conformance claim URI for section 12.1 of this Profile is "http://ws-i.org/profiles/basic-security/swa/1.0".

The conformance claim URI for all other sections of this Profile is "http://ws-i.org.profiles/basic-security/core/1.0".

Editors' note:The conformance claim URI for this Profile is subject to change upon publication.

3.1 Conformance of Artifacts

The most basic level of conformance is that of an artifact. An instance of an artifact is considered conformant when all of the requirements associated with it are met. The Profile makes requirement statements about one kind of artifact:

A message is considered conformant when all of its contained Artifacts are conformant with all Statements related to SECURE_ENVELOPE or SECURE_MESSAGE as appropriate in the Profile. Use of Artifacts for which there are no Statements in the Profile does not effect conformance.

3.2 Conformance of Message Senders

A Sender is considered conformant when all of the Messages it produces are conformant and its behavior is conformant with all Statements related to SENDER in the Profile.

3.3 Conformance of Message Receivers

A Receiver is considered conformant when it is capable of consuming conformant Messages containing the Artifacts that it supports and its behavior is conformant with all Statements related to RECEIVER in the Profile. A conformant Receiver need not accept all possible conformant Messages. A conformant Receiver may choose not to support Artifacts that provide unneeded or undesired functionality. When a Receiver supports a specific Artifact, and the Profile contains Statements related to that Artifact, a conformant Receiver must accept all required conformant forms of that Artifact.

3.4 Claiming Conformance

Claims of conformance to the Profile can be made using the mechanisms described in the Profile Conformance Framework. Specifically, claims can be made using the following conformance attachment mechanisms, as long as the requirements in this profile associated with the listed targets have been met:

Note that conformance does not apply to a service as a whole; only ports are considered when determining conformance of instances. Therefore, the Profile places no constraints on wsdl:service definitions. In particular, they can contain multiple wsdl:port elements, each of which may or may not be conformant.

4. Transport Layer Security

This section of the Profile 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 Profile;

SSL and TLS are both used as underlying protocols for HTTP/S. This 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 this profile 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

4.2 Security Considerations

The following specifications (or sections thereof) are referred to in this section of the Profile;

HTTP Headers are not protected when SSL or TLS is used. This profile places the following constraints on the use of HTTP Headers:

4.2.1 SOAPAction Header

C2010 A SECURE_ENVELOPE SHOULD NOT be transmitted in an HTTP message containing a SOAPAction header in order to prevent processing based on this potentially unsecured value.

5. SOAP Message Security

This section of the Profile 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 Profile;

Editors' note:The requirement statements in this section might be moved to a separate document in future.

This Profile 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 default values simplifies XML processing requirements.

R3029 Any wsse:BinarySecurityToken in a SECURE_ENVELOPE MUST have an EncodingType attribute.

R3030 An EncodingType attribute on a wsse:BinarySecurityToken element in a SECURE_ENVELOPE 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.

For example,

INCORRECT: 

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

<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/
hs+f3NwvK23bh46mNmnCQVsUYHbYAREZpykrd/eRwNgx8T+ByeFhmSviW77n6yTcI7XU7xZT54S9
hTSyBLN2Sce1dEQpQXh5ssZK9aZTMrsFT1NBvNHC3Qq7w0Otr5V4axH3MXffsuI9WzxPCfHdalN4
rLRfNY318pc6bn00zAMw0omUWwBEJZxxBGGUc9QY3VjwNALgGDaEAT7gpURkCI85HjdnSA5SM4cY
7jAsYX/CIpEkRJcBULlTEFrBZIBYDPzRWlSdsJRJngF7yCoGWJ+/HYOyP8P4OM59FDi0kM8GwOE0
WgYrJHH92qaVhoiPTLi7
   </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/
hs+f3NwvK23bh46mNmnCQVsUYHbYAREZpykrd/eRwNgx8T+ByeFhmSviW77n6yTcI7XU7xZT54S9
hTSyBLN2Sce1dEQpQXh5ssZK9aZTMrsFT1NBvNHC3Qq7w0Otr5V4axH3MXffsuI9WzxPCfHdalN4
rLRfNY318pc6bn00zAMw0omUWwBEJZxxBGGUc9QY3VjwNALgGDaEAT7gpURkCI85HjdnSA5SM4cY
7jAsYX/CIpEkRJcBULlTEFrBZIBYDPzRWlSdsJRJngF7yCoGWJ+/HYOyP8P4OM59FDi0kM8GwOE0
WgYrJHH92qaVhoiPTLi7
   </wsse:BinarySecurityToken>
</wsse:Security>

5.1.2 Binary Security Token ValueType Attribute

Base64Binary is the only encoding type specified by Web Services Security: SOAP Message Security. Explicit specification of default values simplifies XML processing requirements.

R3031 Any wsse:BinarySecurityToken element in a SECURE_ENVELOPE MUST have a ValueType attribute.

R3032 A ValueType attribute on a wsse:BinarySecurityToken element in a SECURE_ENVELOPE MUST have a value specified within the appropriate token profile.

A BinarySecurityToken may specify its value type. The Profile restricts the value type to one of those specified by a security token profile and requires its specification.

For example,

INCORRECT: 

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

<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'
                             EncodingType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-soap-message-security-1.0#Base64Binary">
lui+Jy4WYKGJW5xM3aHnLxOpGVIpzSg4V486hHFe7sHET/uxxVBovT7JV1A2RnWSWkXm9jAEdsm/
hs+f3NwvK23bh46mNmnCQVsUYHbYAREZpykrd/eRwNgx8T+ByeFhmSviW77n6yTcI7XU7xZT54S9
hTSyBLN2Sce1dEQpQXh5ssZK9aZTMrsFT1NBvNHC3Qq7w0Otr5V4axH3MXffsuI9WzxPCfHdalN4
rLRfNY318pc6bn00zAMw0omUWwBEJZxxBGGUc9QY3VjwNALgGDaEAT7gpURkCI85HjdnSA5SM4cY
7jAsYX/CIpEkRJcBULlTEFrBZIBYDPzRWlSdsJRJngF7yCoGWJ+/HYOyP8P4OM59FDi0kM8GwOE0
WgYrJHH92qaVhoiPTLi7
   </wsse:BinarySecurityToken>
</wsse:Security>

INCORRECT: 

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

<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://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/
hs+f3NwvK23bh46mNmnCQVsUYHbYAREZpykrd/eRwNgx8T+ByeFhmSviW77n6yTcI7XU7xZT54S9
hTSyBLN2Sce1dEQpQXh5ssZK9aZTMrsFT1NBvNHC3Qq7w0Otr5V4axH3MXffsuI9WzxPCfHdalN4
rLRfNY318pc6bn00zAMw0omUWwBEJZxxBGGUc9QY3VjwNALgGDaEAT7gpURkCI85HjdnSA5SM4cY
7jAsYX/CIpEkRJcBULlTEFrBZIBYDPzRWlSdsJRJngF7yCoGWJ+/HYOyP8P4OM59FDi0kM8GwOE0
WgYrJHH92qaVhoiPTLi7
   </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/
hs+f3NwvK23bh46mNmnCQVsUYHbYAREZpykrd/eRwNgx8T+ByeFhmSviW77n6yTcI7XU7xZT54S9
hTSyBLN2Sce1dEQpQXh5ssZK9aZTMrsFT1NBvNHC3Qq7w0Otr5V4axH3MXffsuI9WzxPCfHdalN4
rLRfNY318pc6bn00zAMw0omUWwBEJZxxBGGUc9QY3VjwNALgGDaEAT7gpURkCI85HjdnSA5SM4cY
7jAsYX/CIpEkRJcBULlTEFrBZIBYDPzRWlSdsJRJngF7yCoGWJ+/HYOyP8P4OM59FDi0kM8GwOE0
WgYrJHH92qaVhoiPTLi7
   </wsse:BinarySecurityToken>
</wsse:Security>

5.2 SecurityTokenReferences

The following specifications (or sections thereof) are referred to in this section of the Profile;

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

5.2.1 Use of wsse:SecurityTokenReference

Consistent use of a single security token reference method increases the likelihood of interoperability.

R3021 When a Security Token is referenced within a wsse:Security header in a SECURE_ENVELOPE, it MUST be referenced by using a wsse:SecurityTokenReference element.

There are many methods to refer to security tokens. The Profile requires use of wsse:SecurityTokenReference.

For example,

INCORRECT: 

<!-- This example is incorrect because it carries an inline X509 certificate using an ds:X509Data element inside the 
     ds:KeyInfo element rather than refering to a wsse:BinarySecurityToken element using the wsse:SecurityTokenReference 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/
hs+f3NwvK23bh46mNmnCQVsUYHbYAREZpykrd/eRwNgx8T+ByeFhmSviW77n6yTcI7XU7xZT54S9
hTSyBLN2Sce1dEQpQXh5ssZK9aZTMrsFT1NBvNHC3Qq7w0Otr5V4axH3MXffsuI9WzxPCfHdalN4
rLRfNY318pc6bn00zAMw0omUWwBEJZxxBGGUc9QY3VjwNALgGDaEAT7gpURkCI85HjdnSA5SM4cY
7jAsYX/CIpEkRJcBULlTEFrBZIBYDPzRWlSdsJRJngF7yCoGWJ+/HYOyP8P4OM59FDi0kM8GwOE0
WgYrJHH92qaVhoiPTLi7
   </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>i3qi5GjhHnfoBn/jOjQp2mq0Na4=</ds:DigestValue>
         </ds:Reference>
      </ds:SignedInfo>
      <ds:SignatureValue>PipXJ2Sfc+LTDnq4pM5JcIYt9gg=</ds:SignatureValue>
      <ds:KeyInfo>
         <ds:X509Data>
            <ds:X509Certificate>
lui+Jy4WYKGJW5xM3aHnLxOpGVIpzSg4V486hHFe7sHET/uxxVBovT7JV1A2RnWSWkXm9jAEdsm/
hs+f3NwvK23bh46mNmnCQVsUYHbYAREZpykrd/eRwNgx8T+ByeFhmSviW77n6yTcI7XU7xZT54S9
hTSyBLN2Sce1dEQpQXh5ssZK9aZTMrsFT1NBvNHC3Qq7w0Otr5V4axH3MXffsuI9WzxPCfHdalN4
rLRfNY318pc6bn00zAMw0omUWwBEJZxxBGGUc9QY3VjwNALgGDaEAT7gpURkCI85HjdnSA5SM4cY
7jAsYX/CIpEkRJcBULlTEFrBZIBYDPzRWlSdsJRJngF7yCoGWJ+/HYOyP8P4OM59FDi0kM8GwOE0
WgYrJHH92qaVhoiPTLi7
           </ds:X509Certificate>
         </ds:X509Data>
      </ds:KeyInfo>
   </ds:Signature>
</wsse:Security>

INCORRECT: 

<!-- This example is incorrect because it refers to an external X509 certificate using ds:X509IssueSerial element 
     inside a ds:KeyInfo element rather than using a wsse:SecurityTokenReference element inside the ds:KeyInfo 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/
hs+f3NwvK23bh46mNmnCQVsUYHbYAREZpykrd/eRwNgx8T+ByeFhmSviW77n6yTcI7XU7xZT54S9
hTSyBLN2Sce1dEQpQXh5ssZK9aZTMrsFT1NBvNHC3Qq7w0Otr5V4axH3MXffsuI9WzxPCfHdalN4
rLRfNY318pc6bn00zAMw0omUWwBEJZxxBGGUc9QY3VjwNALgGDaEAT7gpURkCI85HjdnSA5SM4cY
7jAsYX/CIpEkRJcBULlTEFrBZIBYDPzRWlSdsJRJngF7yCoGWJ+/HYOyP8P4OM59FDi0kM8GwOE0
WgYrJHH92qaVhoiPTLi7
   </wsse:BinarySecurityToken>
   <xenc:EncryptedKey>
      <xenc:EncryptionMethod Algorithm='http://www.w3.org/2001/04/xmlenc#rsa-oaep-mgf1p' />
      <ds:KeyInfo>
         <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>
      </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#' >
   <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/
hs+f3NwvK23bh46mNmnCQVsUYHbYAREZpykrd/eRwNgx8T+ByeFhmSviW77n6yTcI7XU7xZT54S9
hTSyBLN2Sce1dEQpQXh5ssZK9aZTMrsFT1NBvNHC3Qq7w0Otr5V4axH3MXffsuI9WzxPCfHdalN4
rLRfNY318pc6bn00zAMw0omUWwBEJZxxBGGUc9QY3VjwNALgGDaEAT7gpURkCI85HjdnSA5SM4cY
7jAsYX/CIpEkRJcBULlTEFrBZIBYDPzRWlSdsJRJngF7yCoGWJ+/HYOyP8P4OM59FDi0kM8GwOE0
WgYrJHH92qaVhoiPTLi7
   </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>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>
</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/
hs+f3NwvK23bh46mNmnCQVsUYHbYAREZpykrd/eRwNgx8T+ByeFhmSviW77n6yTcI7XU7xZT54S9
hTSyBLN2Sce1dEQpQXh5ssZK9aZTMrsFT1NBvNHC3Qq7w0Otr5V4axH3MXffsuI9WzxPCfHdalN4
rLRfNY318pc6bn00zAMw0omUWwBEJZxxBGGUc9QY3VjwNALgGDaEAT7gpURkCI85HjdnSA5SM4cY
7jAsYX/CIpEkRJcBULlTEFrBZIBYDPzRWlSdsJRJngF7yCoGWJ+/HYOyP8P4OM59FDi0kM8GwOE0
WgYrJHH92qaVhoiPTLi7
   </wsse:BinarySecurityToken>
   <xenc:EncryptedKey>
      <xenc:EncryptionMethod Algorithm='http://www.w3.org/2001/04/xmlenc#rsa-oaep-mgf1p' />
      <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.2 Internal References

Reference by Key Identifier may be ambiguous.

R3022 When a wsse:SecurityTokenReference element in a SECURE_ENVELOPE references a Security Token contained within that message, and that Security Token carries an attribute of type ID, it MUST be referred to using either a Direct Reference or an Embedded Reference.

Direct and Embedded are preferred over Key Identifier References.

For example,

INCORRECT: 

<!-- This example is incorrect because it refers to a wsse:BinarySecurityToken element 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/
hs+f3NwvK23bh46mNmnCQVsUYHbYAREZpykrd/eRwNgx8T+ByeFhmSviW77n6yTcI7XU7xZT54S9
hTSyBLN2Sce1dEQpQXh5ssZK9aZTMrsFT1NBvNHC3Qq7w0Otr5V4axH3MXffsuI9WzxPCfHdalN4
rLRfNY318pc6bn00zAMw0omUWwBEJZxxBGGUc9QY3VjwNALgGDaEAT7gpURkCI85HjdnSA5SM4cY
7jAsYX/CIpEkRJcBULlTEFrBZIBYDPzRWlSdsJRJngF7yCoGWJ+/HYOyP8P4OM59FDi0kM8GwOE0
WgYrJHH92qaVhoiPTLi7
   </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-soap-message-security-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/
hs+f3NwvK23bh46mNmnCQVsUYHbYAREZpykrd/eRwNgx8T+ByeFhmSviW77n6yTcI7XU7xZT54S9
hTSyBLN2Sce1dEQpQXh5ssZK9aZTMrsFT1NBvNHC3Qq7w0Otr5V4axH3MXffsuI9WzxPCfHdalN4
rLRfNY318pc6bn00zAMw0omUWwBEJZxxBGGUc9QY3VjwNALgGDaEAT7gpURkCI85HjdnSA5SM4cY
7jAsYX/CIpEkRJcBULlTEFrBZIBYDPzRWlSdsJRJngF7yCoGWJ+/HYOyP8P4OM59FDi0kM8GwOE0
WgYrJHH92qaVhoiPTLi7
   </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/
hs+f3NwvK23bh46mNmnCQVsUYHbYAREZpykrd/eRwNgx8T+ByeFhmSviW77n6yTcI7XU7xZT54S9
hTSyBLN2Sce1dEQpQXh5ssZK9aZTMrsFT1NBvNHC3Qq7w0Otr5V4axH3MXffsuI9WzxPCfHdalN4
rLRfNY318pc6bn00zAMw0omUWwBEJZxxBGGUc9QY3VjwNALgGDaEAT7gpURkCI85HjdnSA5SM4cY
7jAsYX/CIpEkRJcBULlTEFrBZIBYDPzRWlSdsJRJngF7yCoGWJ+/HYOyP8P4OM59FDi0kM8GwOE0
WgYrJHH92qaVhoiPTLi7
         </wsse:BinarySecurityToken>
      </wsse:Embedded>
   </wsse:SecurityTokenReference>
</wsse:Security>

5.2.3 Shorthand XPointer References

The wsse:BinarySecurityToken has a wsu:Id attribute allowing references to use shorthand XPointers.

R5204 When a wsse:SecurityTokenReference element in a SECURE_ENVELOPE uses a Direct Reference to a Security Token contained within that message, it MUST use a shorthand XPointer reference to the element containing the Security Token.

For example,

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/
hs+f3NwvK23bh46mNmnCQVsUYHbYAREZpykrd/eRwNgx8T+ByeFhmSviW77n6yTcI7XU7xZT54S9
hTSyBLN2Sce1dEQpQXh5ssZK9aZTMrsFT1NBvNHC3Qq7w0Otr5V4axH3MXffsuI9WzxPCfHdalN4
rLRfNY318pc6bn00zAMw0omUWwBEJZxxBGGUc9QY3VjwNALgGDaEAT7gpURkCI85HjdnSA5SM4cY
7jAsYX/CIpEkRJcBULlTEFrBZIBYDPzRWlSdsJRJngF7yCoGWJ+/HYOyP8P4OM59FDi0kM8GwOE0
WgYrJHH92qaVhoiPTLi7
 </wsse:BinarySecurityToken>
 <xenc:EncryptedKey>
   <xenc:EncryptionMethod Algorithm='http://www.w3.org/2001/04/xmlenc#rsa-oaep-mgf1p' />
   <ds:KeyInfo>
    <wsse:SecurityTokenReference>
     <wsse:Reference URI='#SomeCert' />
    </wsse:SecurityTokenReference>
   </ds:KeyInfo>
   <xenc:CipherData>
     <xenc:CipherValue>
       XZEEVABD3L9G+VNTCDiDTE7WB1a4kILtz5f9FT747eE=       
     </xenc:CipherValue>
   </xenc:CipherData>
 </xenc:EncryptedKey>
</wsse:Security>

5.2.4 References to Preceding Security Tokens

Ensuring that a security token appears before it is referenced means that the implementations already have the token to hand when it is needed to verify a signature or perform decryption.

R5205 When a wsse:BinarySecurityToken element is included in a SECURE_ENVELOPE it MUST precede the first wsse:SecurityTokenReference element that references it.

Any wsse:BinarySecurityToken element must appear before a referencing wsse:SecurityTokenReference element in document order.

For example,

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-oaep-mgf1p' />
   <ds:KeyInfo>
     <wsse:SecurityTokenReference>
       <wsse:Reference URI='#SomeCert' />
     </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/
hs+f3NwvK23bh46mNmnCQVsUYHbYAREZpykrd/eRwNgx8T+ByeFhmSviW77n6yTcI7XU7xZT54S9
hTSyBLN2Sce1dEQpQXh5ssZK9aZTMrsFT1NBvNHC3Qq7w0Otr5V4axH3MXffsuI9WzxPCfHdalN4
rLRfNY318pc6bn00zAMw0omUWwBEJZxxBGGUc9QY3VjwNALgGDaEAT7gpURkCI85HjdnSA5SM4cY
7jAsYX/CIpEkRJcBULlTEFrBZIBYDPzRWlSdsJRJngF7yCoGWJ+/HYOyP8P4OM59FDi0kM8GwOE0
WgYrJHH92qaVhoiPTLi7
 </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/
hs+f3NwvK23bh46mNmnCQVsUYHbYAREZpykrd/eRwNgx8T+ByeFhmSviW77n6yTcI7XU7xZT54S9
hTSyBLN2Sce1dEQpQXh5ssZK9aZTMrsFT1NBvNHC3Qq7w0Otr5V4axH3MXffsuI9WzxPCfHdalN4
rLRfNY318pc6bn00zAMw0omUWwBEJZxxBGGUc9QY3VjwNALgGDaEAT7gpURkCI85HjdnSA5SM4cY
7jAsYX/CIpEkRJcBULlTEFrBZIBYDPzRWlSdsJRJngF7yCoGWJ+/HYOyP8P4OM59FDi0kM8GwOE0
WgYrJHH92qaVhoiPTLi7
 </wsse:BinarySecurityToken>
 <xenc:EncryptedKey>
   <xenc:EncryptionMethod Algorithm='http://www.w3.org/2001/04/xmlenc#rsa-oaep-mgf1p' />
   <ds:KeyInfo>
     <wsse:SecurityTokenReference>
       <wsse:Reference URI='#SomeCert' />
     </wsse:SecurityTokenReference>
   </ds:KeyInfo>
   <xenc:CipherData>
     <xenc:CipherValue>
       XZEEVABD3L9G+VNTCDiDTE7WB1a4kILtz5f9FT747eE=       
     </xenc:CipherValue>
   </xenc:CipherData>
 </xenc:EncryptedKey>
</wsse:Security>

5.2.5 Direct Preferred to Embedded for Internal References

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

R3023 When a wsse:SecurityTokenReference element in a SECURE_ENVELOPE references a Security Token contained within that message, and that Security Token might be referenced in several places within the message, it SHOULD be referred to using a Direct Reference rather than an Embedded Reference.

Direct references are encouraged. Embedded references are discouraged.

For example,

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/
hs+f3NwvK23bh46mNmnCQVsUYHbYAREZpykrd/eRwNgx8T+ByeFhmSviW77n6yTcI7XU7xZT54S9
hTSyBLN2Sce1dEQpQXh5ssZK9aZTMrsFT1NBvNHC3Qq7w0Otr5V4axH3MXffsuI9WzxPCfHdalN4
rLRfNY318pc6bn00zAMw0omUWwBEJZxxBGGUc9QY3VjwNALgGDaEAT7gpURkCI85HjdnSA5SM4cY
7jAsYX/CIpEkRJcBULlTEFrBZIBYDPzRWlSdsJRJngF7yCoGWJ+/HYOyP8P4OM59FDi0kM8GwOE0
WgYrJHH92qaVhoiPTLi7
         </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/
hs+f3NwvK23bh46mNmnCQVsUYHbYAREZpykrd/eRwNgx8T+ByeFhmSviW77n6yTcI7XU7xZT54S9
hTSyBLN2Sce1dEQpQXh5ssZK9aZTMrsFT1NBvNHC3Qq7w0Otr5V4axH3MXffsuI9WzxPCfHdalN4
rLRfNY318pc6bn00zAMw0omUWwBEJZxxBGGUc9QY3VjwNALgGDaEAT7gpURkCI85HjdnSA5SM4cY
7jAsYX/CIpEkRJcBULlTEFrBZIBYDPzRWlSdsJRJngF7yCoGWJ+/HYOyP8P4OM59FDi0kM8GwOE0
WgYrJHH92qaVhoiPTLi7
   </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>

Editors' note: The "incorrect" example above is used to show correct use of embedded reference with R3022, but since embedded references are discouraged here, it is used to show incorrect token reference.

5.2.6 Direct Required When Possible for External References

R3024 When a wsse:SecurityTokenReference element in a SECURE_ENVELOPE references a Security Token not contained within that message, and that security Token can be referred to using a Direct Reference, it MUST be referred to using a Direct Reference.

For example,

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/
hs+f3NwvK23bh46mNmnCQVsUYHbYAREZpykrd/eRwNgx8T+ByeFhmSviW77n6yTcI7XU7xZT54S9
hTSyBLN2Sce1dEQpQXh5ssZK9aZTMrsFT1NBvNHC3Qq7w0Otr5V4axH3MXffsuI9WzxPCfHdalN4
rLRfNY318pc6bn00zAMw0omUWwBEJZxxBGGUc9QY3VjwNALgGDaEAT7gpURkCI85HjdnSA5SM4cY
7jAsYX/CIpEkRJcBULlTEFrBZIBYDPzRWlSdsJRJngF7yCoGWJ+/HYOyP8P4OM59FDi0kM8GwOE0
WgYrJHH92qaVhoiPTLi7
   </wsse:BinarySecurityToken>
   <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.7 Format of Embedded References

R3025 When a wsse:Embedded element in a SECURE_ENVELOPE is used to specify a security token inline within a wsse:SecurityTokenReference element, the format of the contained security token MUST be the same as if the security token was a child of a wsse:Security element.

For example,

INCORRECT: 

<!-- This example is incorrect because the wsse:Embedded element carries the date for the X509 certificate directly 
     rather than as a wsse:BinarySecurityToken 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:SecurityTokenReference>
      <wsse:Embedded wsu:Id="SomeCert">
lui+Jy4WYKGJW5xM3aHnLxOpGVIpzSg4V486hHFe7sHET/uxxVBovT7JV1A2RnWSWkXm9jAEdsm/
hs+f3NwvK23bh46mNmnCQVsUYHbYAREZpykrd/eRwNgx8T+ByeFhmSviW77n6yTcI7XU7xZT54S9
hTSyBLN2Sce1dEQpQXh5ssZK9aZTMrsFT1NBvNHC3Qq7w0Otr5V4axH3MXffsuI9WzxPCfHdalN4
rLRfNY318pc6bn00zAMw0omUWwBEJZxxBGGUc9QY3VjwNALgGDaEAT7gpURkCI85HjdnSA5SM4cY
7jAsYX/CIpEkRJcBULlTEFrBZIBYDPzRWlSdsJRJngF7yCoGWJ+/HYOyP8P4OM59FDi0kM8GwOE0
WgYrJHH92qaVhoiPTLi7
      </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: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/
hs+f3NwvK23bh46mNmnCQVsUYHbYAREZpykrd/eRwNgx8T+ByeFhmSviW77n6yTcI7XU7xZT54S9
hTSyBLN2Sce1dEQpQXh5ssZK9aZTMrsFT1NBvNHC3Qq7w0Otr5V4axH3MXffsuI9WzxPCfHdalN4
rLRfNY318pc6bn00zAMw0omUWwBEJZxxBGGUc9QY3VjwNALgGDaEAT7gpURkCI85HjdnSA5SM4cY
7jAsYX/CIpEkRJcBULlTEFrBZIBYDPzRWlSdsJRJngF7yCoGWJ+/HYOyP8P4OM59FDi0kM8GwOE0
WgYrJHH92qaVhoiPTLi7
         </wsse:BinarySecurityToken>
      </wsse:Embedded>
   </wsse:SecurityTokenReference>
</wsse:Security>

5.2.8 Key Identifier for External References

R3026 When a wsse:SecurityTokenReference element in a SECURE_ENVELOPE references a Security Token not contained within that message, and that Security Token cannot be referred to using a Direct Reference but can be referred to using a Key Identifier, it MUST be referred to using a Key Identifier.

For example,

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/
hs+f3NwvK23bh46mNmnCQVsUYHbYAREZpykrd/eRwNgx8T+ByeFhmSviW77n6yTcI7XU7xZT54S9
hTSyBLN2Sce1dEQpQXh5ssZK9aZTMrsFT1NBvNHC3Qq7w0Otr5V4axH3MXffsuI9WzxPCfHdalN4
rLRfNY318pc6bn00zAMw0omUWwBEJZxxBGGUc9QY3VjwNALgGDaEAT7gpURkCI85HjdnSA5SM4cY
7jAsYX/CIpEkRJcBULlTEFrBZIBYDPzRWlSdsJRJngF7yCoGWJ+/HYOyP8P4OM59FDi0kM8GwOE0
WgYrJHH92qaVhoiPTLi7
   </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-soap-message-security-1.0#X509SubjectKeyIdentifier" >
         MIGfMa0GCSq
      </wsse:KeyIdentifier>
   </wsse:SecurityTokenReference>
</wsse:Security>

5.2.9 Key Name References Prohibited

R3027 A wsse:SecurityTokenReference element in a SECURE_ENVELOPE MUST NOT use a Key Name to reference a Security Token.

For example,

INCORRECT: 

<!-- This example is incorrect because it uses a ds:X509IssuerName element to refer to an X509 certificate  -->

<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/
hs+f3NwvK23bh46mNmnCQVsUYHbYAREZpykrd/eRwNgx8T+ByeFhmSviW77n6yTcI7XU7xZT54S9
hTSyBLN2Sce1dEQpQXh5ssZK9aZTMrsFT1NBvNHC3Qq7w0Otr5V4axH3MXffsuI9WzxPCfHdalN4
rLRfNY318pc6bn00zAMw0omUWwBEJZxxBGGUc9QY3VjwNALgGDaEAT7gpURkCI85HjdnSA5SM4cY
7jAsYX/CIpEkRJcBULlTEFrBZIBYDPzRWlSdsJRJngF7yCoGWJ+/HYOyP8P4OM59FDi0kM8GwOE0
WgYrJHH92qaVhoiPTLi7
   </wsse:BinarySecurityToken>
   <wsse:SecurityTokenReference>
      <ds:X509Data>
         <ds:X509IssuerSerial>
            <ds:X509IssuerName>CN=Security WG, OU=BSP, O=WS-I, C=US</ds:X509IssuerName>
            <ds:X509IssuerSerial>54A4E9</ds:X509IssuerSerial>
         </ds:X509IssuerSerial>
      </ds:X509Data>
   </wsse:SecurityTokenReference>
</wsse:Security>

INCORRECT: 

<!-- This example is incorrect because it uses a ds:KeyName element to refer to an X509 certificate  -->

<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/
hs+f3NwvK23bh46mNmnCQVsUYHbYAREZpykrd/eRwNgx8T+ByeFhmSviW77n6yTcI7XU7xZT54S9
hTSyBLN2Sce1dEQpQXh5ssZK9aZTMrsFT1NBvNHC3Qq7w0Otr5V4axH3MXffsuI9WzxPCfHdalN4
rLRfNY318pc6bn00zAMw0omUWwBEJZxxBGGUc9QY3VjwNALgGDaEAT7gpURkCI85HjdnSA5SM4cY
7jAsYX/CIpEkRJcBULlTEFrBZIBYDPzRWlSdsJRJngF7yCoGWJ+/HYOyP8P4OM59FDi0kM8GwOE0
WgYrJHH92qaVhoiPTLi7
   </wsse:BinarySecurityToken>
   <wsse:SecurityTokenReference>
      <ds:KeyName>CN=Security WG, OU=BSP, O=WS-I, C=US</ds:KeyName>
   </wsse:SecurityTokenReference>
</wsse:Security>

5.2.10 ds:KeyInfo/wsse:SecurityTokenReference in XML Signatures

R3052 If a ds:Signature element within a wsse:Security header in a SECURE_ENVELOPE contains a ds:KeyInfo then a wsse:SecurityTokenReference element MUST be used to refer to the security token used for the signature.

For example,

INCORRECT: 

<!-- This example is incorrect because it uses a ds:X509Data element to provide token information rather than using 
     a wsse:SecurityTokenReference 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#' >
   <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>i3qi5GjhHnfoBn/jOjQp2mq0Na4=</ds:DigestValue>
         </ds:Reference>
      </ds:SignedInfo>
      <ds:SignatureValue>PipXJ2Sfc+LTDnq4pM5JcIYt9gg=</ds:SignatureValue>
      <ds:KeyInfo>
         <ds:X509Data>
            <ds:X509Certificate>
lui+Jy4WYKGJW5xM3aHnLxOpGVIpzSg4V486hHFe7sHET/uxxVBovT7JV1A2RnWSWkXm9jAEdsm/
hs+f3NwvK23bh46mNmnCQVsUYHbYAREZpykrd/eRwNgx8T+ByeFhmSviW77n6yTcI7XU7xZT54S9
hTSyBLN2Sce1dEQpQXh5ssZK9aZTMrsFT1NBvNHC3Qq7w0Otr5V4axH3MXffsuI9WzxPCfHdalN4
rLRfNY318pc6bn00zAMw0omUWwBEJZxxBGGUc9QY3VjwNALgGDaEAT7gpURkCI85HjdnSA5SM4cY
7jAsYX/CIpEkRJcBULlTEFrBZIBYDPzRWlSdsJRJngF7yCoGWJ+/HYOyP8P4OM59FDi0kM8GwOE0
WgYrJHH92qaVhoiPTLi7
            </ds:X509Certificate>
         </ds:X509Data>
      </ds:KeyInfo>
   </ds:Signature>
</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/
hs+f3NwvK23bh46mNmnCQVsUYHbYAREZpykrd/eRwNgx8T+ByeFhmSviW77n6yTcI7XU7xZT54S9
hTSyBLN2Sce1dEQpQXh5ssZK9aZTMrsFT1NBvNHC3Qq7w0Otr5V4axH3MXffsuI9WzxPCfHdalN4
rLRfNY318pc6bn00zAMw0omUWwBEJZxxBGGUc9QY3VjwNALgGDaEAT7gpURkCI85HjdnSA5SM4cY
7jAsYX/CIpEkRJcBULlTEFrBZIBYDPzRWlSdsJRJngF7yCoGWJ+/HYOyP8P4OM59FDi0kM8GwOE0
WgYrJHH92qaVhoiPTLi7
   </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>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>
</wsse:Security>

5.2.11 ds:KeyInfo/wsse:SecurityTokenReference in XML Encryption

R3053 If an xenc:EncryptedData or xenc:EncryptedKey element within a wsse:Security header in a SECURE_ENVELOPE contains a ds:KeyInfo then a wsse:SecurityTokenReference element MUST be used to refer to the relevant Security Token.

For example,

INCORRECT: 

<!-- This example is incorrect because it uses a ds:X509Data element to provide token information rather than using 
     a wsse:SecurityTokenReference 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-oaep-mgf1p' />
      <ds:KeyInfo>
         <ds:X509Data>
            <ds:X509Certificate>
lui+Jy4WYKGJW5xM3aHnLxOpGVIpzSg4V486hHFe7sHET/uxxVBovT7JV1A2RnWSWkXm9jAEdsm/
hs+f3NwvK23bh46mNmnCQVsUYHbYAREZpykrd/eRwNgx8T+ByeFhmSviW77n6yTcI7XU7xZT54S9
hTSyBLN2Sce1dEQpQXh5ssZK9aZTMrsFT1NBvNHC3Qq7w0Otr5V4axH3MXffsuI9WzxPCfHdalN4
rLRfNY318pc6bn00zAMw0omUWwBEJZxxBGGUc9QY3VjwNALgGDaEAT7gpURkCI85HjdnSA5SM4cY
7jAsYX/CIpEkRJcBULlTEFrBZIBYDPzRWlSdsJRJngF7yCoGWJ+/HYOyP8P4OM59FDi0kM8GwOE0
WgYrJHH92qaVhoiPTLi7
            </ds:X509Certificate>
         </ds:X509Data>
      </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#' >
   <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/
hs+f3NwvK23bh46mNmnCQVsUYHbYAREZpykrd/eRwNgx8T+ByeFhmSviW77n6yTcI7XU7xZT54S9
hTSyBLN2Sce1dEQpQXh5ssZK9aZTMrsFT1NBvNHC3Qq7w0Otr5V4axH3MXffsuI9WzxPCfHdalN4
rLRfNY318pc6bn00zAMw0omUWwBEJZxxBGGUc9QY3VjwNALgGDaEAT7gpURkCI85HjdnSA5SM4cY
7jAsYX/CIpEkRJcBULlTEFrBZIBYDPzRWlSdsJRJngF7yCoGWJ+/HYOyP8P4OM59FDi0kM8GwOE0
WgYrJHH92qaVhoiPTLi7
   </wsse:BinarySecurityToken>
   <xenc:EncryptedKey>
      <xenc:EncryptionMethod Algorithm='http://www.w3.org/2001/04/xmlenc#rsa-oaep-mgf1p' />
      <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.12 KeyIdentifier/@ValueType Attribute

R3054 Any wsse:KeyIdentifier element in a SECURE_ENVELOPE MUST have a ValueType attribute.

R3063 A ValueType attribute on a wsse:KeyIdentifier element in a SECURE_ENVELOPE MUST have a value specified within the appropriate token profile.

For example,

INCORRECT: 

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

<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/
hs+f3NwvK23bh46mNmnCQVsUYHbYAREZpykrd/eRwNgx8T+ByeFhmSviW77n6yTcI7XU7xZT54S9
hTSyBLN2Sce1dEQpQXh5ssZK9aZTMrsFT1NBvNHC3Qq7w0Otr5V4axH3MXffsuI9WzxPCfHdalN4
rLRfNY318pc6bn00zAMw0omUWwBEJZxxBGGUc9QY3VjwNALgGDaEAT7gpURkCI85HjdnSA5SM4cY
7jAsYX/CIpEkRJcBULlTEFrBZIBYDPzRWlSdsJRJngF7yCoGWJ+/HYOyP8P4OM59FDi0kM8GwOE0
WgYrJHH92qaVhoiPTLi7
   </wsse:BinarySecurityToken>
   <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>
</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/
hs+f3NwvK23bh46mNmnCQVsUYHbYAREZpykrd/eRwNgx8T+ByeFhmSviW77n6yTcI7XU7xZT54S9
hTSyBLN2Sce1dEQpQXh5ssZK9aZTMrsFT1NBvNHC3Qq7w0Otr5V4axH3MXffsuI9WzxPCfHdalN4
rLRfNY318pc6bn00zAMw0omUWwBEJZxxBGGUc9QY3VjwNALgGDaEAT7gpURkCI85HjdnSA5SM4cY
7jAsYX/CIpEkRJcBULlTEFrBZIBYDPzRWlSdsJRJngF7yCoGWJ+/HYOyP8P4OM59FDi0kM8GwOE0WgYrJHH92qaVhoiPTLi7
   </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-soap-message-security-1.0#X509SubjectKeyIdentifier" >
         MIGfMa0GCSq
      </wsse:KeyIdentifier>
   </wsse:SecurityTokenReference>
</wsse:Security>

5.2.13 Children of wsse:Embedded

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

R3060 A wsse:Embedded element in a SECURE_ENVELOPE MUST contain a single child element for a security token from an appropriate token profile.

For example,

INCORRECT: 

<!-- This example is incorrect because the wsse:Embedded element contains a wsse:SecurityTokenReference 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/
hs+f3NwvK23bh46mNmnCQVsUYHbYAREZpykrd/eRwNgx8T+ByeFhmSviW77n6yTcI7XU7xZT54S9
hTSyBLN2Sce1dEQpQXh5ssZK9aZTMrsFT1NBvNHC3Qq7w0Otr5V4axH3MXffsuI9WzxPCfHdalN4
rLRfNY318pc6bn00zAMw0omUWwBEJZxxBGGUc9QY3VjwNALgGDaEAT7gpURkCI85HjdnSA5SM4cY
7jAsYX/CIpEkRJcBULlTEFrBZIBYDPzRWlSdsJRJngF7yCoGWJ+/HYOyP8P4OM59FDi0kM8GwOE0
WgYrJHH92qaVhoiPTLi7
   </wsse:BinarySecurityToken>
   <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>
</wsse:Security>

INCORRECT: 

<!-- This example is incorrect because the wsse:Embedded element has multiple element children -->

<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="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/
hs+f3NwvK23bh46mNmnCQVsUYHbYAREZpykrd/eRwNgx8T+ByeFhmSviW77n6yTcI7XU7xZT54S9
hTSyBLN2Sce1dEQpQXh5ssZK9aZTMrsFT1NBvNHC3Qq7w0Otr5V4axH3MXffsuI9WzxPCfHdalN4
rLRfNY318pc6bn00zAMw0omUWwBEJZxxBGGUc9QY3VjwNALgGDaEAT7gpURkCI85HjdnSA5SM4cY
7jAsYX/CIpEkRJcBULlTEFrBZIBYDPzRWlSdsJRJngF7yCoGWJ+/HYOyP8P4OM59FDi0kM8GwOE0
WgYrJHH92qaVhoiPTLi7
         </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/
hs+f3NwvK23bh46mNmnCQVsUYHbYAREZpykrd/eRwNgx8T+ByeFhmSviW77n6yTcI7XU7xZT54S9
hTSyBLN2Sce1dEQpQXh5ssZK9aZTMrsFT1NBvNHC3Qq7w0Otr5V4axH3MXffsuI9WzxPCfHdalN4
rLRfNY318pc6bn00zAMw0omUWwBEJZxxBGGUc9QY3VjwNALgGDaEAT7gpURkCI85HjdnSA5SM4cY
7jAsYX/CIpEkRJcBULlTEFrBZIBYDPzRWlSdsJRJngF7yCoGWJ+/HYOyP8P4OM59FDi0kM8GwOE0
WgYrJHH92qaVhoiPTLi7
         </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: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/
hs+f3NwvK23bh46mNmnCQVsUYHbYAREZpykrd/eRwNgx8T+ByeFhmSviW77n6yTcI7XU7xZT54S9
hTSyBLN2Sce1dEQpQXh5ssZK9aZTMrsFT1NBvNHC3Qq7w0Otr5V4axH3MXffsuI9WzxPCfHdalN4
rLRfNY318pc6bn00zAMw0omUWwBEJZxxBGGUc9QY3VjwNALgGDaEAT7gpURkCI85HjdnSA5SM4cY
7jAsYX/CIpEkRJcBULlTEFrBZIBYDPzRWlSdsJRJngF7yCoGWJ+/HYOyP8P4OM59FDi0kM8GwOE0
WgYrJHH92qaVhoiPTLi7
         </wsse:BinarySecurityToken>
      </wsse:Embedded>
   </wsse:SecurityTokenReference>
</wsse:Security>

Editors' note:We need to figure out exactly what 'appropriate' means in this context.

5.2.14 Reference from wsse:SecurityTokenReference to wsse:SecurityTokenReference

R3056 A wsse:SecurityTokenReference element in a SECURE_ENVELOPE MUST NOT contain a direct reference to another wsse:SecurityTokenReference element that does not have a wsse:Embedded child element.

R3064 When wsse:SecurityTokenReference element in a SECURE_ENVELOPE contains a direct reference to an security token contained within an wsse:Embedded element, the reference MUST be to the contained token not to the wsse:Embedded element.

For example,

INCORRECT: 

<!-- This example is incorrect because the second wsse:SecurityTokenReference element refers to the 
     wsse:SecurityTokenReference with an wsu:Id of TheFirstSTR  -->

<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/
hs+f3NwvK23bh46mNmnCQVsUYHbYAREZpykrd/eRwNgx8T+ByeFhmSviW77n6yTcI7XU7xZT54S9
hTSyBLN2Sce1dEQpQXh5ssZK9aZTMrsFT1NBvNHC3Qq7w0Otr5V4axH3MXffsuI9WzxPCfHdalN4
rLRfNY318pc6bn00zAMw0omUWwBEJZxxBGGUc9QY3VjwNALgGDaEAT7gpURkCI85HjdnSA5SM4cY
7jAsYX/CIpEkRJcBULlTEFrBZIBYDPzRWlSdsJRJngF7yCoGWJ+/HYOyP8P4OM59FDi0kM8GwOE0
WgYrJHH92qaVhoiPTLi7
   </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>
</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/
hs+f3NwvK23bh46mNmnCQVsUYHbYAREZpykrd/eRwNgx8T+ByeFhmSviW77n6yTcI7XU7xZT54S9
hTSyBLN2Sce1dEQpQXh5ssZK9aZTMrsFT1NBvNHC3Qq7w0Otr5V4axH3MXffsuI9WzxPCfHdalN4
rLRfNY318pc6bn00zAMw0omUWwBEJZxxBGGUc9QY3VjwNALgGDaEAT7gpURkCI85HjdnSA5SM4cY
7jAsYX/CIpEkRJcBULlTEFrBZIBYDPzRWlSdsJRJngF7yCoGWJ+/HYOyP8P4OM59FDi0kM8GwOE0
WgYrJHH92qaVhoiPTLi7
         </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>
</wsse:Security>

5.2.15 wsse:SecurityTokenReference/Reference ValueType Attribute

R3059 A wsse:SecurityTokenReference/wsse:Reference element in a SECURE_ENVELOPE MUST have a ValueType attribute.

R3058 The value of a ValueType attribute on any wsse:SecurityTokenReference/wsse:Reference element in a SECURE_ENVELOPE MUST match the value of the ValueType attribute, if any, on the referenced token.

5.2.16 wsse:SecurityTokenReference constraints

R3061 A wsse:SecurityTokenReference element in a SECURE_ENVELOPE MUST have exactly one child element

R3062 A wsse:SecurityTokenReference/wsse:Reference element in a SECURE_ENVELOPE MUST have a URI attribute

5.2.17 wsse:SecurityTokenReference Dereferencing Transform

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

5.3 Timestamps

The following specifications (or sections thereof) are referred to in this section of the Profile;

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

5.3.1 wsu:Timestamp

The wsu:Created element represents the creation time of the security semantics. 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.

R3203 Any wsu:Timestamp element in a wsse:Security header in a SECURE_ENVELOPE MUST have exactly one wsu:Created element child.

R3213 A wsu:Timestamp within a SECURE_ENVELOPE MUST NOT include wsse:Created or wsse:Expires values that specify leap seconds.

R3217 A wsu:Timestamp within a SECURE_ENVELOPE MUST contain time instants only in UTC format as specified by the XML Schema type (dateTime).

R3218 The wsu:Timestamp within a SECURE_ENVELOPE when present as a descendant of a wsse:Security element MUST be a child of that element.

R3219 The wsu:Timestamp element within a SECURE_ENVELOPE when present as a child of a wsse:Security element MUST NOT appear more than once within that wsse:Security element.

R3220 The wsu:Created and wsu:Expires elements within a SECURE_ENVELOPE MUST appear at most once within a wsu:Timestamp element.

R3221 If wsu:Created and wsu:Expires elements both appear within a SECURE_ENVELOPE they MUST appear in the order: wsu:Created then wsu:Expires.

For example,

INCORRECT: 

<!-- This example is incorrect because the wsu:Timestamp element is missing a wsu:Created 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' >
 <wsu:Timestamp wsu:Id="timestamp">
   <wsu:Expires>2001-10-13T09:00:00Z</wsu:Expires>
 </wsu:Timestamp>
</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' >
 <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>
</wsse:Security>

5.4 wsu:Id References

The following specifications (or sections thereof) are referred to in this section of the Profile;

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

5.4.1 wsu:Id Attribute Uniqueness

R3204 Two wsu:Id attributes within any SECURE_ENVELOPE MUST NOT have the same value.

5.5 wsse:Security Processing Order

The following specifications (or sections thereof) are referred to in this section of the Profile;

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

5.5.1 Order of Processing

R3212 Within a SECURE_ENVELOPE, the ds:Signature and/or the encryption sub-elements (xenc:EncryptedKey or xenc:ReferenceList) MUST be ordered within the wsse:Security header so a receiver will get the correct result by processing the elements in the order they appear within each wsse:Security header.

5.6 SOAP Actor

The following specifications (or sections thereof) are referred to in this section of the Profile;

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

5.6.1 SOAP Actor Value

R3206 Within a SECURE_ENVELOPE there MUST be at most one wsse:Security header block with the actor attribute omitted.

R3210 Within a SECURE_ENVELOPE there MUST be at most one wsse:Security header block with the same actor attribute value.

6. Username Token Profile

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

6.1 Token Usage

6.1.1 wsse:UsernameToken/wsse:Password/@Type

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

R4201 When a wsse:UsernameToken/wsse:Password element is present in a SECURE_ENVELOPE its Type attribute MUST be explicitly present.

For example,

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

R4212 When the wsse:PasswordDigest element is used within a SECURE_ENVELOPE, 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.

6.1.3 wsse:Nonce

R4213 Each SECURE_ENVELOPE including a wsse:Nonce element MUST use a nonce value which is different from all previous nonce values used by that SENDER.

6.1.4 ValueType attribute

R4214 When a UsernameToken is referenced within a SECURE_ENVELOPE using a wsse:SecurityTokenReference and the ValueType attribute is used, its value MUST be "http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-soap-message-security-1.0#UsernameToken".

6.1.5 Reference by KeyIdentifier

R4215 When a wsse:SecurityTokenReference element is used within a SECURE_ENVELOPE to refer to a wsse:UsernameToken, a KeyIdentifier reference MUST NOT be used.

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 sometime in the future. See UTP07 for discussion of this issue.

6.1.7 Sign UsernameToken

C4210 A wsse:UsernameToken in a SECURE_ENVELOPE which contains a wsse:Nonce element SHOULD be referenced by a ds:Reference in a ds:SignedInfo element in order to prevent replay.

C4211 A wsse:UsernameToken in a SECURE_ENVELOPE which contains a wsu:Created element SHOULD be referenced by a ds:Reference in a ds:SignedInfo element in order to prevent replay.

7. X.509 Certificate Token Profile

This section of the Profile 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 Profile;

Web Services Security: X.509 Token Profile defines 3 token types. This Profile places the following constraints on their use:

7.1.1 Certificate Path

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.

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.

7.1.2 KeyIdentifier

R5206 When the wsse:KeyIdentifier element is used within a SECURE_ENVELOPE to specify a reference to an X.509 certificate, the wsse:KeyIdentifier element MUST have ValueType attribute with the value http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-soap-message-security-1.0#X509SubjectKeyIdentifier and its contents MUST be the value of the certificate's X.509 SubjectKeyIdentifier extension.

7.1.3 Use of SecurityTokenReference

R5207 Within a SECURE_ENVELOPE, a wsse:SecurityTokenReference element MUST be used to specify all references to X.509 token types in signature or encryption elements.

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. This Profile places the constraints defined in this section on the use of XML Signature and the processing model with respect to signatures whose ds:Signature element appears as a child of a wsse:Security element. This section of the profile places no constraints on ds:Signature elements appearing elsewhere.

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

8.1 General Constraints on XML Signature

8.1.1 Types of Signatures

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 XML Signatures in a SECURE_ENVELOPE MUST NOT be Enveloping Signatures as defined by the XML Signature specification.

R3103 XML Signatures in a SECURE_ENVELOPE SHOULD be Detached Signatures as defined by the XML Signature specification.

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

For example,

INCORRECT: 

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

<soap:Envelope xmlns:wsse='http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd'
               xmlns:soap='http://schemas.xmlsoap.org/soap/envelope' >
  <soap:Header>
    <wsse:Security 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/
hs+f3NwvK23bh46mNmnCQVsUYHbYAREZpykrd/eRwNgx8T+ByeFhmSviW77n6yTcI7XU7xZT54S9
hTSyBLN2Sce1dEQpQXh5ssZK9aZTMrsFT1NBvNHC3Qq7w0Otr5V4axH3MXffsuI9WzxPCfHdalN4
rLRfNY318pc6bn00zAMw0omUWwBEJZxxBGGUc9QY3VjwNALgGDaEAT7gpURkCI85HjdnSA5SM4cY
7jAsYX/CIpEkRJcBULlTEFrBZIBYDPzRWlSdsJRJngF7yCoGWJ+/HYOyP8P4OM59FDi0kM8GwOE0
WgYrJHH92qaVhoiPTLi7
      </wsse:BinarySecurityToken>
      <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' />
          </wsse:SecurityTokenReference>
        </ds:KeyInfo>
        <ds:Object>
          <ds:SignatureProperties>
            <ds:SignatureProperty Id='SigPropBody' Target='#TheSig'>
              <SomeSecurityToken/>
            </ds:SignatureProperty>
          </ds:SignatureProperties>
        </ds:Object>
      </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/
hs+f3NwvK23bh46mNmnCQVsUYHbYAREZpykrd/eRwNgx8T+ByeFhmSviW77n6yTcI7XU7xZT54S9
hTSyBLN2Sce1dEQpQXh5ssZK9aZTMrsFT1NBvNHC3Qq7w0Otr5V4axH3MXffsuI9WzxPCfHdalN4
rLRfNY318pc6bn00zAMw0omUWwBEJZxxBGGUc9QY3VjwNALgGDaEAT7gpURkCI85HjdnSA5SM4cY
7jAsYX/CIpEkRJcBULlTEFrBZIBYDPzRWlSdsJRJngF7yCoGWJ+/HYOyP8P4OM59FDi0kM8GwOE0
WgYrJHH92qaVhoiPTLi7
     </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>i3qi5GjhHnfoBn/jOjQp2mq0Na4=</ds:DigestValue>
         </ds:Reference>
       </ds:SignedInfo>
       <ds:SignatureValue>PipXJ2Sfc+LTDnq4pM5JcIYt9gg=</ds:SignatureValue>
       <ds:KeyInfo>
         <wsse:SecurityTokenReference>
           <wsse:Reference URI='#SomeCert' />
         </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.2 Element References in XML Signature

The following specifications (or sections thereof) are referred to in this section of the Profile;

Element references are used to specify which portions of a SECURE_ENVELOPE are integrity protected. This Profile places the following constraints on the use of Element References:

8.2.1 Reference to element with ID attribute

Local references using shorthand XPointers are easy to resolve.

R3001 When referring to an element in a SECURE_ENVELOPE that carries an attribute of type ID from ds:Reference a shorthand XPointer MUST be used to refer to that element.

This avoids requirement for receiver to implement generalized XPath processing when not required.

For example,

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/
hs+f3NwvK23bh46mNmnCQVsUYHbYAREZpykrd/eRwNgx8T+ByeFhmSviW77n6yTcI7XU7xZT54S9
hTSyBLN2Sce1dEQpQXh5ssZK9aZTMrsFT1NBvNHC3Qq7w0Otr5V4axH3MXffsuI9WzxPCfHdalN4
rLRfNY318pc6bn00zAMw0omUWwBEJZxxBGGUc9QY3VjwNALgGDaEAT7gpURkCI85HjdnSA5SM4cY
7jAsYX/CIpEkRJcBULlTEFrBZIBYDPzRWlSdsJRJngF7yCoGWJ+/HYOyP8P4OM59FDi0kM8GwOE0
WgYrJHH92qaVhoiPTLi7
   </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>i3qi5GjhHnfoBn/jOjQp2mq0Na4=</ds:DigestValue>
       </ds:Reference>
     </ds:SignedInfo>
     <ds:SignatureValue>PipXJ2Sfc+LTDnq4pM5JcIYt9gg=</ds:SignatureValue>
     <ds:KeyInfo>
       <wsse:SecurityTokenReference>
         <wsse:Reference URI='#SomeCert' />
       </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.2.2 Reference to element without ID attribute

Elements that do not have an attribute of type ID cannot be refered to by shorthand XPointers so a different referencing mechanism is needed. The XPath Filter 2.0 transform is more efficient that the original XPath transform from XML Digital Signature Syntax and Processing

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

For example,

INCORRECT: 

<!-- This example is incorrect because it uses the http://www.w3.org/TR/1999/REC-xpath-19991116 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/
hs+f3NwvK23bh46mNmnCQVsUYHbYAREZpykrd/eRwNgx8T+ByeFhmSviW77n6yTcI7XU7xZT54S9
hTSyBLN2Sce1dEQpQXh5ssZK9aZTMrsFT1NBvNHC3Qq7w0Otr5V4axH3MXffsuI9WzxPCfHdalN4
rLRfNY318pc6bn00zAMw0omUWwBEJZxxBGGUc9QY3VjwNALgGDaEAT7gpURkCI85HjdnSA5SM4cY
7jAsYX/CIpEkRJcBULlTEFrBZIBYDPzRWlSdsJRJngF7yCoGWJ+/HYOyP8P4OM59FDi0kM8GwOE0
WgYrJHH92qaVhoiPTLi7
     </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=''>
           <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' />
             </ds:Transform>
             <ds:Transform Algorithm='http://www.w3.org/TR/1999/REC-xpath-19991116'>
               <ds:XPath>/soap:Envelope/soap:Body/*</ds:XPath>
             </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' />
         </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/
hs+f3NwvK23bh46mNmnCQVsUYHbYAREZpykrd/eRwNgx8T+ByeFhmSviW77n6yTcI7XU7xZT54S9
hTSyBLN2Sce1dEQpQXh5ssZK9aZTMrsFT1NBvNHC3Qq7w0Otr5V4axH3MXffsuI9WzxPCfHdalN4
rLRfNY318pc6bn00zAMw0omUWwBEJZxxBGGUc9QY3VjwNALgGDaEAT7gpURkCI85HjdnSA5SM4cY
7jAsYX/CIpEkRJcBULlTEFrBZIBYDPzRWlSdsJRJngF7yCoGWJ+/HYOyP8P4OM59FDi0kM8GwOE0
WgYrJHH92qaVhoiPTLi7
      </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=''>
            <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' />
              </ds:Transform>
              <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: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' />
          </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

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

R5404 Any ds:CanonicalizationMethod/@Algorithm attribute in a SECURE_ENVELOPE 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 that has an @Algorithm attribute whose value is "http://www.w3.org/2001/10/xml-exc-c14n#" MUST have a c14N:InclusiveNamespace child element with an @PrefixList attribute.

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

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

R5408 Any ds:Transform/c14n:InclusiveNamespaces/@PrefixList attribute 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.

For example,

INCORRECT: 

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

<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/
hs+f3NwvK23bh46mNmnCQVsUYHbYAREZpykrd/eRwNgx8T+ByeFhmSviW77n6yTcI7XU7xZT54S9
hTSyBLN2Sce1dEQpQXh5ssZK9aZTMrsFT1NBvNHC3Qq7w0Otr5V4axH3MXffsuI9WzxPCfHdalN4
rLRfNY318pc6bn00zAMw0omUWwBEJZxxBGGUc9QY3VjwNALgGDaEAT7gpURkCI85HjdnSA5SM4cY
7jAsYX/CIpEkRJcBULlTEFrBZIBYDPzRWlSdsJRJngF7yCoGWJ+/HYOyP8P4OM59FDi0kM8GwOE0
WgYrJHH92qaVhoiPTLi7
      </wsse:BinarySecurityToken>
      <ds:Signature xmlns:ds='http://www.w3.org/2000/09/xmldsig#'>
        <ds:SignedInfo>
          <ds:CanonicalizationMethod Algorithm='http://www.w3.org/TR/2001/REC-xml-c14n-20010315' />
          <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/2001/REC-xml-c14n-20010315 ' />
              <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: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' />
          </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>

INCORRECT: 

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

<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/
hs+f3NwvK23bh46mNmnCQVsUYHbYAREZpykrd/eRwNgx8T+ByeFhmSviW77n6yTcI7XU7xZT54S9
hTSyBLN2Sce1dEQpQXh5ssZK9aZTMrsFT1NBvNHC3Qq7w0Otr5V4axH3MXffsuI9WzxPCfHdalN4
rLRfNY318pc6bn00zAMw0omUWwBEJZxxBGGUc9QY3VjwNALgGDaEAT7gpURkCI85HjdnSA5SM4cY
7jAsYX/CIpEkRJcBULlTEFrBZIBYDPzRWlSdsJRJngF7yCoGWJ+/HYOyP8P4OM59FDi0kM8GwOE0
WgYrJHH92qaVhoiPTLi7
      </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#" ' />
          <ds:SignatureMethod Algorithm='http://www.w3.org/2000/09/xmldsig#rsa-sha1' />
          <ds:Reference URI=''>
            <ds:Transforms>
              <ds:Transform Algorithm='http://www.w3.org/2001/10/xml-exc-c14n#' />
              <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: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' />
          </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>

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 wsu prefix 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/
hs+f3NwvK23bh46mNmnCQVsUYHbYAREZpykrd/eRwNgx8T+ByeFhmSviW77n6yTcI7XU7xZT54S9
hTSyBLN2Sce1dEQpQXh5ssZK9aZTMrsFT1NBvNHC3Qq7w0Otr5V4axH3MXffsuI9WzxPCfHdalN4
rLRfNY318pc6bn00zAMw0omUWwBEJZxxBGGUc9QY3VjwNALgGDaEAT7gpURkCI85HjdnSA5SM4cY
7jAsYX/CIpEkRJcBULlTEFrBZIBYDPzRWlSdsJRJngF7yCoGWJ+/HYOyP8P4OM59FDi0kM8GwOE0
WgYrJHH92qaVhoiPTLi7
      </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=''>
            <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: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: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' />
          </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/
hs+f3NwvK23bh46mNmnCQVsUYHbYAREZpykrd/eRwNgx8T+ByeFhmSviW77n6yTcI7XU7xZT54S9
hTSyBLN2Sce1dEQpQXh5ssZK9aZTMrsFT1NBvNHC3Qq7w0Otr5V4axH3MXffsuI9WzxPCfHdalN4
rLRfNY318pc6bn00zAMw0omUWwBEJZxxBGGUc9QY3VjwNALgGDaEAT7gpURkCI85HjdnSA5SM4cY
7jAsYX/CIpEkRJcBULlTEFrBZIBYDPzRWlSdsJRJngF7yCoGWJ+/HYOyP8P4OM59FDi0kM8GwOE0
WgYrJHH92qaVhoiPTLi7
      </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=''>
            <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' />
              </ds:Transform>
              <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: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' />
          </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 Transform required

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

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

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

For example,

INCORRECT: 

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

<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/
hs+f3NwvK23bh46mNmnCQVsUYHbYAREZpykrd/eRwNgx8T+ByeFhmSviW77n6yTcI7XU7xZT54S9
hTSyBLN2Sce1dEQpQXh5ssZK9aZTMrsFT1NBvNHC3Qq7w0Otr5V4axH3MXffsuI9WzxPCfHdalN4
rLRfNY318pc6bn00zAMw0omUWwBEJZxxBGGUc9QY3VjwNALgGDaEAT7gpURkCI85HjdnSA5SM4cY
7jAsYX/CIpEkRJcBULlTEFrBZIBYDPzRWlSdsJRJngF7yCoGWJ+/HYOyP8P4OM59FDi0kM8GwOE0
WgYrJHH92qaVhoiPTLi7
      </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: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' />
          </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/
hs+f3NwvK23bh46mNmnCQVsUYHbYAREZpykrd/eRwNgx8T+ByeFhmSviW77n6yTcI7XU7xZT54S9
hTSyBLN2Sce1dEQpQXh5ssZK9aZTMrsFT1NBvNHC3Qq7w0Otr5V4axH3MXffsuI9WzxPCfHdalN4
rLRfNY318pc6bn00zAMw0omUWwBEJZxxBGGUc9QY3VjwNALgGDaEAT7gpURkCI85HjdnSA5SM4cY
7jAsYX/CIpEkRJcBULlTEFrBZIBYDPzRWlSdsJRJngF7yCoGWJ+/HYOyP8P4OM59FDi0kM8GwOE0
WgYrJHH92qaVhoiPTLi7
      </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' />
          </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.3 Permitted algorithms

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

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

R5421 Any ds:SignatureMethod/@Algorithm element in a SECURE_ENVELOPE that is part of a signature based on a symmetric key MUST have the value "http://www.w3.org/2000/09/xmldsig#hmac-sha1"

R5422 Any ds:SignatureMethod/@Algorithm element in a SECURE_ENVELOPE that is part of a signature based on an asymmetric key MUST have the value "http://www.w3.org/2000/09/xmldsig#rsa-sha1"

R5423 Any ds:Transform/@Algorithm attribute in a SECURE_ENVELOPE 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#STRTransform" or "http://www.w3.org/2000/09/xmldsig#enveloped-signature"

For example,

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/
hs+f3NwvK23bh46mNmnCQVsUYHbYAREZpykrd/eRwNgx8T+ByeFhmSviW77n6yTcI7XU7xZT54S9
hTSyBLN2Sce1dEQpQXh5ssZK9aZTMrsFT1NBvNHC3Qq7w0Otr5V4axH3MXffsuI9WzxPCfHdalN4
rLRfNY318pc6bn00zAMw0omUWwBEJZxxBGGUc9QY3VjwNALgGDaEAT7gpURkCI85HjdnSA5SM4cY
7jAsYX/CIpEkRJcBULlTEFrBZIBYDPzRWlSdsJRJngF7yCoGWJ+/HYOyP8P4OM59FDi0kM8GwOE0
WgYrJHH92qaVhoiPTLi7
      </wsse:BinarySecurityToken>
      <xenc:EncryptedKey Id='Secret' xmlns:xenc='http://www.w3.org/2001/04/xmlenc#' >
        <xenc:EncryptionMethod Algorithm='http://www.w3.org/2001/04/xmlenc#rsa-oaep-mgf1p' />
        <ds:KeyInfo xmlns:ds='http://www.w3.org/2000/09/xmldsig#'>
          <wsse:SecurityTokenReference>
            <wsse:Reference URI='#SomeCert' />
          </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:KeyInfo>
          <wsse:SecurityTokenReference>
            <wsse:Reference URI='#Secret' />
          </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/
hs+f3NwvK23bh46mNmnCQVsUYHbYAREZpykrd/eRwNgx8T+ByeFhmSviW77n6yTcI7XU7xZT54S9
hTSyBLN2Sce1dEQpQXh5ssZK9aZTMrsFT1NBvNHC3Qq7w0Otr5V4axH3MXffsuI9WzxPCfHdalN4
rLRfNY318pc6bn00zAMw0omUWwBEJZxxBGGUc9QY3VjwNALgGDaEAT7gpURkCI85HjdnSA5SM4cY
7jAsYX/CIpEkRJcBULlTEFrBZIBYDPzRWlSdsJRJngF7yCoGWJ+/HYOyP8P4OM59FDi0kM8GwOE0
WgYrJHH92qaVhoiPTLi7
      </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' />
          </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.4 XML Signature Syntax

XML-Signature Syntax and Processing defines many elements and attributes. This Profile 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 in a SECURE_ENVELOPE.

For example,

INCORRECT: 

<!-- This example is incorrect because the ds:SignatureMethod element has a ds:HMACOutputLength child element -->

<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/
hs+f3NwvK23bh46mNmnCQVsUYHbYAREZpykrd/eRwNgx8T+ByeFhmSviW77n6yTcI7XU7xZT54S9
hTSyBLN2Sce1dEQpQXh5ssZK9aZTMrsFT1NBvNHC3Qq7w0Otr5V4axH3MXffsuI9WzxPCfHdalN4
rLRfNY318pc6bn00zAMw0omUWwBEJZxxBGGUc9QY3VjwNALgGDaEAT7gpURkCI85HjdnSA5SM4cY
7jAsYX/CIpEkRJcBULlTEFrBZIBYDPzRWlSdsJRJngF7yCoGWJ+/HYOyP8P4OM59FDi0kM8GwOE0
WgYrJHH92qaVhoiPTLi7
     </wsse:BinarySecurityToken>
     <xenc:EncryptedKey Id='Secret'
                        xmlns:xenc='http://www.w3.org/2001/04/xmlenc#'>
       <xenc:EncryptionMethod Algorithm='http://www.w3.org/2001/04/xmlenc#rsa-oaep-mgf1p' />
       <ds:KeyInfo xmlns:ds='http://www.w3.org/2000/09/xmldsig#' >
         <wsse:SecurityTokenReference>
           <wsse:Reference URI='#SomeCert' />
         </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:HMACOutputLength>128</ds:HMACOutputLength>
         </ds:SignatureMethod>
         <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='#Secret' />
         </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/
hs+f3NwvK23bh46mNmnCQVsUYHbYAREZpykrd/eRwNgx8T+ByeFhmSviW77n6yTcI7XU7xZT54S9
hTSyBLN2Sce1dEQpQXh5ssZK9aZTMrsFT1NBvNHC3Qq7w0Otr5V4axH3MXffsuI9WzxPCfHdalN4
rLRfNY318pc6bn00zAMw0omUWwBEJZxxBGGUc9QY3VjwNALgGDaEAT7gpURkCI85HjdnSA5SM4cY
7jAsYX/CIpEkRJcBULlTEFrBZIBYDPzRWlSdsJRJngF7yCoGWJ+/HYOyP8P4OM59FDi0kM8GwOE0
WgYrJHH92qaVhoiPTLi7
      </wsse:BinarySecurityToken>
      <xenc:EncryptedKey Id='Secret' xmlns:xenc='http://www.w3.org/2001/04/xmlenc#'>
        <xenc:EncryptionMethod Algorithm='http://www.w3.org/2001/04/xmlenc#rsa-oaep-mgf1p' />
        <ds:KeyInfo xmlns:ds='http://www.w3.org/2000/09/xmldsig#'>
          <wsse:SecurityTokenReference>
            <wsse:Reference URI='#SomeCert' />
          </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:KeyInfo>
          <wsse:SecurityTokenReference>
            <wsse:Reference URI='#Secret' />
          </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.4.2 ds:KeyInfo

The ds:KeyInfo element allows for many different child elements. This profile mandates a single element and restricts the list to wsse:SecurityTokenReference, which is needed to reference security tokens, and ds:MgmtData, which is needed to include inline unencrypted key info. The latter would only be used when tranmission occurs over a secure transport.

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

R5409 The child element of a ds:KeyInfo element in a SECURE_ENVELOPE MUST be either wsse:SecurityTokenReference or ds:MgmtData.

For example,

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/
hs+f3NwvK23bh46mNmnCQVsUYHbYAREZpykrd/eRwNgx8T+ByeFhmSviW77n6yTcI7XU7xZT54S9
hTSyBLN2Sce1dEQpQXh5ssZK9aZTMrsFT1NBvNHC3Qq7w0Otr5V4axH3MXffsuI9WzxPCfHdalN4
rLRfNY318pc6bn00zAMw0omUWwBEJZxxBGGUc9QY3VjwNALgGDaEAT7gpURkCI85HjdnSA5SM4cY
7jAsYX/CIpEkRJcBULlTEFrBZIBYDPzRWlSdsJRJngF7yCoGWJ+/HYOyP8P4OM59FDi0kM8GwOE0
WgYrJHH92qaVhoiPTLi7
      </wsse:BinarySecurityToken>
      <xenc:EncryptedKey Id='Secret' xmlns:xenc='http://www.w3.org/2001/04/xmlenc#'>
        <xenc:EncryptionMethod Algorithm='http://www.w3.org/2001/04/xmlenc#rsa-oaep-mgf1p' />
        <ds:KeyInfo xmlns:ds='http://www.w3.org/2000/09/xmldsig#' >
          <wsse:SecurityTokenReference>
            <wsse:Reference URI='#SomeCert' />
          </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:KeyInfo>
          <wsse:SecurityTokenReference>
            <wsse:Reference URI='#Secret' />
          </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'>
      <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:KeyInfo>
          <ds:MgmtData>eMtKYL5PbZ59pu/zKtFkwQod0kA=</ds:MgmtData>
        </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.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 ds:Signature element in a SECURE_ENVELOPE MUST NOT contain a ds:Manifest element.

For example,

INCORRECT: 

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

<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/
hs+f3NwvK23bh46mNmnCQVsUYHbYAREZpykrd/eRwNgx8T+ByeFhmSviW77n6yTcI7XU7xZT54S9
hTSyBLN2Sce1dEQpQXh5ssZK9aZTMrsFT1NBvNHC3Qq7w0Otr5V4axH3MXffsuI9WzxPCfHdalN4
rLRfNY318pc6bn00zAMw0omUWwBEJZxxBGGUc9QY3VjwNALgGDaEAT7gpURkCI85HjdnSA5SM4cY
7jAsYX/CIpEkRJcBULlTEFrBZIBYDPzRWlSdsJRJngF7yCoGWJ+/HYOyP8P4OM59FDi0kM8GwOE0
WgYrJHH92qaVhoiPTLi7
      </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='#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' />
          </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>
    </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/
hs+f3NwvK23bh46mNmnCQVsUYHbYAREZpykrd/eRwNgx8T+ByeFhmSviW77n6yTcI7XU7xZT54S9
hTSyBLN2Sce1dEQpQXh5ssZK9aZTMrsFT1NBvNHC3Qq7w0Otr5V4axH3MXffsuI9WzxPCfHdalN4
rLRfNY318pc6bn00zAMw0omUWwBEJZxxBGGUc9QY3VjwNALgGDaEAT7gpURkCI85HjdnSA5SM4cY
7jAsYX/CIpEkRJcBULlTEFrBZIBYDPzRWlSdsJRJngF7yCoGWJ+/HYOyP8P4OM59FDi0kM8GwOE0
WgYrJHH92qaVhoiPTLi7
      </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' />
          </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.5 Security Considerations

8.5.1 Sign Security Token

C5440 A ds:Signature in a SECURE_ENVELOPE which contains the Security Token which provides the signature verification key SHOULD include a ds:Reference which points to that Security Token in order to prevent substitution with another Security Token that uses the same key.

C5441 A ds:Signature in a SECURE_ENVELOPE which does not contain the Security Token which provides the signature verification key SHOULD include a ds:Reference that uses the Security Token Dereferencing Transform that points to the wsse:SecurityTokenReference that refers to that Security Token in order to prevent substitution of another Security Token that uses the same key.

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. This Profile places the constraints defined in this section on the use of XML Encryption and the processing model with respect to xenc:EncryptedData, xenc:EncryptedKey and xenc:ReferenceList elements that are the result of or are used as part of performing a single encryption step ( as defined in SOAP Message Security ). This section of the profile places no constraints on xenc:EncryptedData, xenc:EncryptedKey and xenc:ReferenceList elements produced by or used for other purposes.

This section of the Profile 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 seperate 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 For each encryption step that produces an xenc:ReferenceList a SECURE_ENVELOPE MUST contain a seperate wsse:Security/xenc:ReferenceList element for each key used in that encryption step.

R3215 Any xenc:ReferenceList in a SECURE_ENVELOPE MUST contain an xenc:DataReference element for each xenc:EncryptedData element encrypted under a single key as part of the corresponding encryption step.

R3214 An xenc:ReferenceList element in a SECURE_ENVELOPE which is a child of xenc:EncryptedKey MUST contain a xenc:DataReference for each xenc:EncryptedData element that was encrypted in the encryption step with the key corresponding to the xenc:EncryptedKey.

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.

R3207 All xenc:EncryptedKey elements in a SECURE_ENVELOPE that are intended for use by SOAP Message Security MUST be children of a wsse:Security header.

R3208 xenc:EncryptedKey elements in the wsse:Security header in a SECURE_ENVELOPE MUST precede any xenc:EncryptedData elements in that header encrypted using the key in the xenc:EncryptedKey element.

For example,

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/
hs+f3NwvK23bh46mNmnCQVsUYHbYAREZpykrd/eRwNgx8T+ByeFhmSviW77n6yTcI7XU7xZT54S9
hTSyBLN2Sce1dEQpQXh5ssZK9aZTMrsFT1NBvNHC3Qq7w0Otr5V4axH3MXffsuI9WzxPCfHdalN4
rLRfNY318pc6bn00zAMw0omUWwBEJZxxBGGUc9QY3VjwNALgGDaEAT7gpURkCI85HjdnSA5SM4cY
7jAsYX/CIpEkRJcBULlTEFrBZIBYDPzRWlSdsJRJngF7yCoGWJ+/HYOyP8P4OM59FDi0kM8GwOE0
WgYrJHH92qaVhoiPTLi7
  </wsse:BinarySecurityToken>
  <xenc:EncryptedData Id='Enc1'>
    <xenc:EncryptionMethod Algorithm='http://www.w3.org/2001/04/xmlenc#tripledes-cbc' />
    <ds:KeyInfo>
      <wsse:SecurityTokenReference>
        <wsse:Reference URI='#Secret' />
      </wsse:SecurityTokenReference>
    </ds:KeyInfo>
    <xenc:CipherData>
      <xenc:CipherValue>
9jFtYcLSlDZQBMjKfT7ctg6Jy+6sC8YORhiPeTvOjug7ozY2SRHGuLt8G/vf2f/f4IdF0ewiDOpq
XhuqQhv7gnbfj9kHpmz8whIzL/DLLmwZsJi0iL38GJZMy+r2HHWfgZmF/0ol2DoaSQ/Z7936nzCu
kJKCR/m443dDutuBBaWck65WRi4i9NhemT+uIii5Uiu6SIziHTqfzBvT4h1emUNpPVwvo1kBi5u6
I626CsFOiWivx7wZuXZzt3oTTxK7/wD7ROXMiq7Rub3wKPmM5cFahFi0r9GGT4Pmu+vf7juJ/yOt
vsXcgf+53Q3/KJF85tK4ucu5BlAudPRh5s7C8suBZyjV3yb7fQJZ+tHEhyfxadQZJjVwz/jTf0nR
epsw9utCfcFopgervTvIYAx/au3NcHz5qcuVEZcwAmDcKgJnKQPlgQllicLNbmn5qG/sVBVbAwoe
Nk0grWwqOKSnzpM5YTcImejkaOa6LDphnGknQ65KgSb3SPK1xNSdO1AeJZ/VwEc45Losd5sjZAkT
vhADAvX2XE1sQRhEUtQURy2Wmwabi9sh71/zHgmL0+ToogXDmThbKMlSaX4u85HlFzBujcgDeDM0
4ROWAj1D4W40W7DPUa30O3M9SSJd8/vODgfZHUYb5SrSjrgkxSaLDogQ+pfgFsWCeVJVxS4Q1+4=
   </xenc:CipherValue>
 </xenc:CipherData>
</xenc:EncryptedData>
<xenc:EncryptedKey Id='Secret'>
  <xenc:EncryptionMethod Algorithm='http://www.w3.org/2001/04/xmlenc#rsa-oaep-mgf1p' />
  <ds:KeyInfo>
    <wsse:SecurityTokenReference>
      <wsse:Reference URI='#SomeCert' />
    </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/
hs+f3NwvK23bh46mNmnCQVsUYHbYAREZpykrd/eRwNgx8T+ByeFhmSviW77n6yTcI7XU7xZT54S9
hTSyBLN2Sce1dEQpQXh5ssZK9aZTMrsFT1NBvNHC3Qq7w0Otr5V4axH3MXffsuI9WzxPCfHdalN4
rLRfNY318pc6bn00zAMw0omUWwBEJZxxBGGUc9QY3VjwNALgGDaEAT7gpURkCI85HjdnSA5SM4cY
7jAsYX/CIpEkRJcBULlTEFrBZIBYDPzRWlSdsJRJngF7yCoGWJ+/HYOyP8P4OM59FDi0kM8GwOE0
WgYrJHH92qaVhoiPTLi7
  </wsse:BinarySecurityToken>
  <xenc:EncryptedKey Id='Secret'>
   <xenc:EncryptionMethod Algorithm='http://www.w3.org/2001/04/xmlenc#rsa-oaep-mgf1p' />
   <ds:KeyInfo>
     <wsse:SecurityTokenReference>
       <wsse:Reference URI='#SomeCert' />
     </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' />
   <ds:KeyInfo>
     <wsse:SecurityTokenReference>
       <wsse:Reference URI='#Secret' />
     </wsse:SecurityTokenReference>
   </ds:KeyInfo>
   <xenc:CipherData>
     <xenc:CipherValue>
9jFtYcLSlDZQBMjKfT7ctg6Jy+6sC8YORhiPeTvOjug7ozY2SRHGuLt8G/vf2f/f4IdF0ewiDOpq
XhuqQhv7gnbfj9kHpmz8whIzL/DLLmwZsJi0iL38GJZMy+r2HHWfgZmF/0ol2DoaSQ/Z7936nzCu
kJKCR/m443dDutuBBaWck65WRi4i9NhemT+uIii5Uiu6SIziHTqfzBvT4h1emUNpPVwvo1kBi5u6
I626CsFOiWivx7wZuXZzt3oTTxK7/wD7ROXMiq7Rub3wKPmM5cFahFi0r9GGT4Pmu+vf7juJ/yOt
vsXcgf+53Q3/KJF85tK4ucu5BlAudPRh5s7C8suBZyjV3yb7fQJZ+tHEhyfxadQZJjVwz/jTf0nR
epsw9utCfcFopgervTvIYAx/au3NcHz5qcuVEZcwAmDcKgJnKQPlgQllicLNbmn5qG/sVBVbAwoe
Nk0grWwqOKSnzpM5YTcImejkaOa6LDphnGknQ65KgSb3SPK1xNSdO1AeJZ/VwEc45Losd5sjZAkT
vhADAvX2XE1sQRhEUtQURy2Wmwabi9sh71/zHgmL0+ToogXDmThbKMlSaX4u85HlFzBujcgDeDM0
4ROWAj1D4W40W7DPUa30O3M9SSJd8/vODgfZHUYb5SrSjrgkxSaLDogQ+pfgFsWCeVJVxS4Q1+4=
     </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 Profile;

XML Encryption Syntax and Processing defines many elements and attributes. This Profile places the following constraints on their use:

9.2.1 Placement

R3216 Any xenc:EncryptedKey element MUST contain a xenc:ReferenceList child element.

For example,

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/
hs+f3NwvK23bh46mNmnCQVsUYHbYAREZpykrd/eRwNgx8T+ByeFhmSviW77n6yTcI7XU7xZT54S9
hTSyBLN2Sce1dEQpQXh5ssZK9aZTMrsFT1NBvNHC3Qq7w0Otr5V4axH3MXffsuI9WzxPCfHdalN4
rLRfNY318pc6bn00zAMw0omUWwBEJZxxBGGUc9QY3VjwNALgGDaEAT7gpURkCI85HjdnSA5SM4cY
7jAsYX/CIpEkRJcBULlTEFrBZIBYDPzRWlSdsJRJngF7yCoGWJ+/HYOyP8P4OM59FDi0kM8GwOE0
WgYrJHH92qaVhoiPTLi7
  </wsse:BinarySecurityToken>
  <xenc:EncryptedKey Id='Secret'>
    <xenc:EncryptionMethod Algorithm='http://www.w3.org/2001/04/xmlenc#rsa-oaep-mgf1p' />
    <ds:KeyInfo>
      <wsse:SecurityTokenReference>
        <wsse:Reference URI='#SomeCert' />
      </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' />
    <ds:KeyInfo>
      <wsse:SecurityTokenReference>
        <wsse:Reference URI='#Secret' />
      </wsse:SecurityTokenReference>
    </ds:KeyInfo>
    <xenc:CipherData>
      <xenc:CipherValue>
9jFtYcLSlDZQBMjKfT7ctg6Jy+6sC8YORhiPeTvOjug7ozY2SRHGuLt8G/vf2f/f4IdF0ewiDOpq
XhuqQhv7gnbfj9kHpmz8whIzL/DLLmwZsJi0iL38GJZMy+r2HHWfgZmF/0ol2DoaSQ/Z7936nzCu
kJKCR/m443dDutuBBaWck65WRi4i9NhemT+uIii5Uiu6SIziHTqfzBvT4h1emUNpPVwvo1kBi5u6
I626CsFOiWivx7wZuXZzt3oTTxK7/wD7ROXMiq7Rub3wKPmM5cFahFi0r9GGT4Pmu+vf7juJ/yOt
vsXcgf+53Q3/KJF85tK4ucu5BlAudPRh5s7C8suBZyjV3yb7fQJZ+tHEhyfxadQZJjVwz/jTf0nR
epsw9utCfcFopgervTvIYAx/au3NcHz5qcuVEZcwAmDcKgJnKQPlgQllicLNbmn5qG/sVBVbAwoe
Nk0grWwqOKSnzpM5YTcImejkaOa6LDphnGknQ65KgSb3SPK1xNSdO1AeJZ/VwEc45Losd5sjZAkT
vhADAvX2XE1sQRhEUtQURy2Wmwabi9sh71/zHgmL0+ToogXDmThbKMlSaX4u85HlFzBujcgDeDM0
4ROWAj1D4W40W7DPUa30O3M9SSJd8/vODgfZHUYb5SrSjrgkxSaLDogQ+pfgFsWCeVJVxS4Q1+4=
      </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/
hs+f3NwvK23bh46mNmnCQVsUYHbYAREZpykrd/eRwNgx8T+ByeFhmSviW77n6yTcI7XU7xZT54S9
hTSyBLN2Sce1dEQpQXh5ssZK9aZTMrsFT1NBvNHC3Qq7w0Otr5V4axH3MXffsuI9WzxPCfHdalN4
rLRfNY318pc6bn00zAMw0omUWwBEJZxxBGGUc9QY3VjwNALgGDaEAT7gpURkCI85HjdnSA5SM4cY
7jAsYX/CIpEkRJcBULlTEFrBZIBYDPzRWlSdsJRJngF7yCoGWJ+/HYOyP8P4OM59FDi0kM8GwOE0
WgYrJHH92qaVhoiPTLi7
  </wsse:BinarySecurityToken>
  <xenc:EncryptedKey Id='Secret'>
    <xenc:EncryptionMethod Algorithm='http://www.w3.org/2001/04/xmlenc#rsa-oaep-mgf1p' />
    <ds:KeyInfo>
      <wsse:SecurityTokenReference>
        <wsse:Reference URI='#SomeCert' />
      </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' />
    <ds:KeyInfo>
      <wsse:SecurityTokenReference>
        <wsse:Reference URI='#Secret' />
      </wsse:SecurityTokenReference>
    </ds:KeyInfo>
    <xenc:CipherData>
      <xenc:CipherValue>
9jFtYcLSlDZQBMjKfT7ctg6Jy+6sC8YORhiPeTvOjug7ozY2SRHGuLt8G/vf2f/f4IdF0ewiDOpq
XhuqQhv7gnbfj9kHpmz8whIzL/DLLmwZsJi0iL38GJZMy+r2HHWfgZmF/0ol2DoaSQ/Z7936nzCu
kJKCR/m443dDutuBBaWck65WRi4i9NhemT+uIii5Uiu6SIziHTqfzBvT4h1emUNpPVwvo1kBi5u6
I626CsFOiWivx7wZuXZzt3oTTxK7/wD7ROXMiq7Rub3wKPmM5cFahFi0r9GGT4Pmu+vf7juJ/yOt
vsXcgf+53Q3/KJF85tK4ucu5BlAudPRh5s7C8suBZyjV3yb7fQJZ+tHEhyfxadQZJjVwz/jTf0nR
epsw9utCfcFopgervTvIYAx/au3NcHz5qcuVEZcwAmDcKgJnKQPlgQllicLNbmn5qG/sVBVbAwoe
Nk0grWwqOKSnzpM5YTcImejkaOa6LDphnGknQ65KgSb3SPK1xNSdO1AeJZ/VwEc45Losd5sjZAkT
vhADAvX2XE1sQRhEUtQURy2Wmwabi9sh71/zHgmL0+ToogXDmThbKMlSaX4u85HlFzBujcgDeDM0
4ROWAj1D4W40W7DPUa30O3M9SSJd8/vODgfZHUYb5SrSjrgkxSaLDogQ+pfgFsWCeVJVxS4Q1+4=
      </xenc:CipherValue>
    </xenc:CipherData>
  </xenc:EncryptedData>
</wsse:Security>

9.2.2 xenc:EncryptedKey attributes

R3209 xenc:EncryptedKey elements in a SECURE_ENVELOPE MUST NOT specify a Type attribute.

R5622 xenc:EncryptedKey elements in a SECURE_ENVELOPE MUST NOT specify a MimeType attribute.

R5623 xenc:EncryptedKey elements in a SECURE_ENVELOPE MUST NOT specify a Encoding attribute.

9.2.3 xenc:EncryptedData attributes

R5624 xenc:EncryptedKey elements in a SECURE_ENVELOPE MUST have an Id attribute.

9.2.4 References from xenc:EncryptedData

R3211 An xenc:EncryptedData/ds:KeyInfo/wsse:SecurityTokenReference element in a SECURE_ENVELOPE MUST NOT reference another ds:KeyInfo element.

9.2.5 xenc:EncryptionMethod mandatory

R5601 When an xenc:EncryptedData element appears in a SECURE_ENVELOPE it MUST have an xenc:EncryptionMethod child element.

R5603 When an xenc:EncryptedKey element appears in a SECURE_ENVELOPE it MUST have an xenc:EncryptionMethod child element.

For example,

INCORRECT: 

<!-- This example is incorrect because the xenc:EncryptedKey element is missing an xenc:EncryptionMethod 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/
hs+f3NwvK23bh46mNmnCQVsUYHbYAREZpykrd/eRwNgx8T+ByeFhmSviW77n6yTcI7XU7xZT54S9
hTSyBLN2Sce1dEQpQXh5ssZK9aZTMrsFT1NBvNHC3Qq7w0Otr5V4axH3MXffsuI9WzxPCfHdalN4
rLRfNY318pc6bn00zAMw0omUWwBEJZxxBGGUc9QY3VjwNALgGDaEAT7gpURkCI85HjdnSA5SM4cY
7jAsYX/CIpEkRJcBULlTEFrBZIBYDPzRWlSdsJRJngF7yCoGWJ+/HYOyP8P4OM59FDi0kM8GwOE0
WgYrJHH92qaVhoiPTLi7
  </wsse:BinarySecurityToken>
  <xenc:EncryptedKey Id='Secret'>
    <xenc:EncryptionMethod Algorithm='http://www.w3.org/2001/04/xmlenc#rsa-oaep-mgf1p' />
    <ds:KeyInfo>
      <wsse:SecurityTokenReference>
        <wsse:Reference URI='#SomeCert' />
      </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' />
    <ds:KeyInfo>
      <wsse:SecurityTokenReference>
        <wsse:Reference URI='#Secret' />
      </wsse:SecurityTokenReference>
    </ds:KeyInfo>
    <xenc:CipherData>
      <xenc:CipherValue>
9jFtYcLSlDZQBMjKfT7ctg6Jy+6sC8YORhiPeTvOjug7ozY2SRHGuLt8G/vf2f/f4IdF0ewiDOpq
XhuqQhv7gnbfj9kHpmz8whIzL/DLLmwZsJi0iL38GJZMy+r2HHWfgZmF/0ol2DoaSQ/Z7936nzCu
kJKCR/m443dDutuBBaWck65WRi4i9NhemT+uIii5Uiu6SIziHTqfzBvT4h1emUNpPVwvo1kBi5u6
I626CsFOiWivx7wZuXZzt3oTTxK7/wD7ROXMiq7Rub3wKPmM5cFahFi0r9GGT4Pmu+vf7juJ/yOt
vsXcgf+53Q3/KJF85tK4ucu5BlAudPRh5s7C8suBZyjV3yb7fQJZ+tHEhyfxadQZJjVwz/jTf0nR
epsw9utCfcFopgervTvIYAx/au3NcHz5qcuVEZcwAmDcKgJnKQPlgQllicLNbmn5qG/sVBVbAwoe
Nk0grWwqOKSnzpM5YTcImejkaOa6LDphnGknQ65KgSb3SPK1xNSdO1AeJZ/VwEc45Losd5sjZAkT
vhADAvX2XE1sQRhEUtQURy2Wmwabi9sh71/zHgmL0+ToogXDmThbKMlSaX4u85HlFzBujcgDeDM0
4ROWAj1D4W40W7DPUa30O3M9SSJd8/vODgfZHUYb5SrSjrgkxSaLDogQ+pfgFsWCeVJVxS4Q1+4=
      </xenc:CipherValue>
    </xenc:CipherData>
  </xenc:EncryptedData>
</wsse:Security>

INCORRECT: 

<!-- This example is incorrect because the xenc:EncryptedData element is missing an xenc:EncryptionMethod 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/
hs+f3NwvK23bh46mNmnCQVsUYHbYAREZpykrd/eRwNgx8T+ByeFhmSviW77n6yTcI7XU7xZT54S9
hTSyBLN2Sce1dEQpQXh5ssZK9aZTMrsFT1NBvNHC3Qq7w0Otr5V4axH3MXffsuI9WzxPCfHdalN4
rLRfNY318pc6bn00zAMw0omUWwBEJZxxBGGUc9QY3VjwNALgGDaEAT7gpURkCI85HjdnSA5SM4cY
7jAsYX/CIpEkRJcBULlTEFrBZIBYDPzRWlSdsJRJngF7yCoGWJ+/HYOyP8P4OM59FDi0kM8GwOE0
WgYrJHH92qaVhoiPTLi7
  </wsse:BinarySecurityToken>
  <xenc:EncryptedKey Id='Secret'>
    <xenc:EncryptionMethod Algorithm='http://www.w3.org/2001/04/xmlenc#rsa-oaep-mgf1p' />
    <ds:KeyInfo>
      <wsse:SecurityTokenReference>
        <wsse:Reference URI='#SomeCert' />
      </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' />
    <ds:KeyInfo>
      <wsse:SecurityTokenReference>
        <wsse:Reference URI='#Secret' />
      </wsse:SecurityTokenReference>
    </ds:KeyInfo>
    <xenc:CipherData>
      <xenc:CipherValue>
9jFtYcLSlDZQBMjKfT7ctg6Jy+6sC8YORhiPeTvOjug7ozY2SRHGuLt8G/vf2f/f4IdF0ewiDOpq
XhuqQhv7gnbfj9kHpmz8whIzL/DLLmwZsJi0iL38GJZMy+r2HHWfgZmF/0ol2DoaSQ/Z7936nzCu
kJKCR/m443dDutuBBaWck65WRi4i9NhemT+uIii5Uiu6SIziHTqfzBvT4h1emUNpPVwvo1kBi5u6
I626CsFOiWivx7wZuXZzt3oTTxK7/wD7ROXMiq7Rub3wKPmM5cFahFi0r9GGT4Pmu+vf7juJ/yOt
vsXcgf+53Q3/KJF85tK4ucu5BlAudPRh5s7C8suBZyjV3yb7fQJZ+tHEhyfxadQZJjVwz/jTf0nR
epsw9utCfcFopgervTvIYAx/au3NcHz5qcuVEZcwAmDcKgJnKQPlgQllicLNbmn5qG/sVBVbAwoe
Nk0grWwqOKSnzpM5YTcImejkaOa6LDphnGknQ65KgSb3SPK1xNSdO1AeJZ/VwEc45Losd5sjZAkT
vhADAvX2XE1sQRhEUtQURy2Wmwabi9sh71/zHgmL0+ToogXDmThbKMlSaX4u85HlFzBujcgDeDM0
4ROWAj1D4W40W7DPUa30O3M9SSJd8/vODgfZHUYb5SrSjrgkxSaLDogQ+pfgFsWCeVJVxS4Q1+4=
      </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/
hs+f3NwvK23bh46mNmnCQVsUYHbYAREZpykrd/eRwNgx8T+ByeFhmSviW77n6yTcI7XU7xZT54S9
hTSyBLN2Sce1dEQpQXh5ssZK9aZTMrsFT1NBvNHC3Qq7w0Otr5V4axH3MXffsuI9WzxPCfHdalN4
rLRfNY318pc6bn00zAMw0omUWwBEJZxxBGGUc9QY3VjwNALgGDaEAT7gpURkCI85HjdnSA5SM4cY
7jAsYX/CIpEkRJcBULlTEFrBZIBYDPzRWlSdsJRJngF7yCoGWJ+/HYOyP8P4OM59FDi0kM8GwOE0
WgYrJHH92qaVhoiPTLi7
  </wsse:BinarySecurityToken>
  <xenc:EncryptedKey Id='Secret'>
    <xenc:EncryptionMethod Algorithm='http://www.w3.org/2001/04/xmlenc#rsa-oaep-mgf1p' />
    <ds:KeyInfo>
      <wsse:SecurityTokenReference>
        <wsse:Reference URI='#SomeCert' />
      </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' />
    <ds:KeyInfo>
      <wsse:SecurityTokenReference>
        <wsse:Reference URI='#Secret' />
      </wsse:SecurityTokenReference>
    </ds:KeyInfo>
    <xenc:CipherData>
      <xenc:CipherValue>
9jFtYcLSlDZQBMjKfT7ctg6Jy+6sC8YORhiPeTvOjug7ozY2SRHGuLt8G/vf2f/f4IdF0ewiDOpq
XhuqQhv7gnbfj9kHpmz8whIzL/DLLmwZsJi0iL38GJZMy+r2HHWfgZmF/0ol2DoaSQ/Z7936nzCu
kJKCR/m443dDutuBBaWck65WRi4i9NhemT+uIii5Uiu6SIziHTqfzBvT4h1emUNpPVwvo1kBi5u6
I626CsFOiWivx7wZuXZzt3oTTxK7/wD7ROXMiq7Rub3wKPmM5cFahFi0r9GGT4Pmu+vf7juJ/yOt
vsXcgf+53Q3/KJF85tK4ucu5BlAudPRh5s7C8suBZyjV3yb7fQJZ+tHEhyfxadQZJjVwz/jTf0nR
epsw9utCfcFopgervTvIYAx/au3NcHz5qcuVEZcwAmDcKgJnKQPlgQllicLNbmn5qG/sVBVbAwoe
Nk0grWwqOKSnzpM5YTcImejkaOa6LDphnGknQ65KgSb3SPK1xNSdO1AeJZ/VwEc45Losd5sjZAkT
vhADAvX2XE1sQRhEUtQURy2Wmwabi9sh71/zHgmL0+ToogXDmThbKMlSaX4u85HlFzBujcgDeDM0
4ROWAj1D4W40W7DPUa30O3M9SSJd8/vODgfZHUYb5SrSjrgkxSaLDogQ+pfgFsWCeVJVxS4Q1+4=
      </xenc:CipherValue>
    </xenc:CipherData>
  </xenc:EncryptedData>
</wsse:Security>

9.2.6 xenc:EncryptedKey/@Recipient

R5602 When an xenc:EncryptedKey appears in a SECURE_ENVELOPE, a Recipient attribute MUST NOT be present.

For example,

INCORRECT: 

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

<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/
hs+f3NwvK23bh46mNmnCQVsUYHbYAREZpykrd/eRwNgx8T+ByeFhmSviW77n6yTcI7XU7xZT54S9
hTSyBLN2Sce1dEQpQXh5ssZK9aZTMrsFT1NBvNHC3Qq7w0Otr5V4axH3MXffsuI9WzxPCfHdalN4
rLRfNY318pc6bn00zAMw0omUWwBEJZxxBGGUc9QY3VjwNALgGDaEAT7gpURkCI85HjdnSA5SM4cY
7jAsYX/CIpEkRJcBULlTEFrBZIBYDPzRWlSdsJRJngF7yCoGWJ+/HYOyP8P4OM59FDi0kM8GwOE0
WgYrJHH92qaVhoiPTLi7
  </wsse:BinarySecurityToken>
  <xenc:EncryptedKey Id='Secret' Recipient='Bert'>
    <xenc:EncryptionMethod Algorithm='http://www.w3.org/2001/04/xmlenc#rsa-oaep-mgf1p' />
    <ds:KeyInfo>
      <wsse:SecurityTokenReference>
        <wsse:Reference URI='#SomeCert' />
      </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' />
    <ds:KeyInfo>
      <wsse:SecurityTokenReference>
        <wsse:Reference URI='#Secret' />
      </wsse:SecurityTokenReference>
    </ds:KeyInfo>
    <xenc:CipherData>
      <xenc:CipherValue>
9jFtYcLSlDZQBMjKfT7ctg6Jy+6sC8YORhiPeTvOjug7ozY2SRHGuLt8G/vf2f/f4IdF0ewiDOpq
XhuqQhv7gnbfj9kHpmz8whIzL/DLLmwZsJi0iL38GJZMy+r2HHWfgZmF/0ol2DoaSQ/Z7936nzCu
kJKCR/m443dDutuBBaWck65WRi4i9NhemT+uIii5Uiu6SIziHTqfzBvT4h1emUNpPVwvo1kBi5u6
I626CsFOiWivx7wZuXZzt3oTTxK7/wD7ROXMiq7Rub3wKPmM5cFahFi0r9GGT4Pmu+vf7juJ/yOt
vsXcgf+53Q3/KJF85tK4ucu5BlAudPRh5s7C8suBZyjV3yb7fQJZ+tHEhyfxadQZJjVwz/jTf0nR
epsw9utCfcFopgervTvIYAx/au3NcHz5qcuVEZcwAmDcKgJnKQPlgQllicLNbmn5qG/sVBVbAwoe
Nk0grWwqOKSnzpM5YTcImejkaOa6LDphnGknQ65KgSb3SPK1xNSdO1AeJZ/VwEc45Losd5sjZAkT
vhADAvX2XE1sQRhEUtQURy2Wmwabi9sh71/zHgmL0+ToogXDmThbKMlSaX4u85HlFzBujcgDeDM0
4ROWAj1D4W40W7DPUa30O3M9SSJd8/vODgfZHUYb5SrSjrgkxSaLDogQ+pfgFsWCeVJVxS4Q1+4=
      </xenc:CipherValue>
    </xenc:CipherData>
  </xenc:EncryptedData>
</wsse:Security>

9.2.7 ds:KeyInfo/xenc:AgreementMethod prohibited

R5605 Any ds:KeyInfo elements in a SECURE_ENVELOPE MUST NOT have any xenc:AgreementMethod child elements.

9.2.8 xenc:EncryptedData

R5606 Within a SECURE_ENVELOPE an encrypted element or element content MUST be replaced by a corresponding xenc:EncryptedData.

9.2.9 SOAP Envelope

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 XML Encryption Algorithms

9.3.1 Permitted Algorithms

R5620 Any xenc:EncryptedData/xenc:EncryptionMethod/@Algorithm attribute in a SECURE_ENVELOPE 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"

R5621 Any xenc:EncryptedKey/xenc:EncryptionMethod/@Algorithm attribute in a SECURE_ENVELOPE MUST have a value of "http://www.w3.org/2001/04/xmlenc#rsa-oaep-mgf1p", "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"

9.4 Security Considerations

9.4.1 Encrypt DigestValue

C5630 A ds:DigestValue in a SECURE_ENVELOPE 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.

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

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

This profile recommends against the use of the following ciphersuites due to their lack of confidentiatlity services:

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

This 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 Extension Profile 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.

The Basic Security Profile is an extension of the Basic Profile, 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 BP 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.

Figure 1: Protocol Stack with SOAP Message Security

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.

11.1 Basic Profile Clarifications

This section clarifies the BP 1.0 and BP 1.1 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 and BP1.1 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 wire signatures that are different from one another."

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

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

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

11.1.3 BP Requirement R2712

bp10:R2712 states "A document-literal binding MUST be represented on the wire 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 represented 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 have SOAP Message Security has been reversed.

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

12. Attachment Security

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 this Profile, 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 including MIME Headers.

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

If it is required for an instance to integrity and confidentiality protect the entire HTTP Message, on a hop-by-hop basis, including HTTP Headers, SOAP Envelope, and all MIME Parts including MIME Headers, SSL/TLS may be used in conjunction with WSS.

Application level security mechanisms, including XML Signature, XML Encryption, PKCS7, 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 this Profile.

Attachment security conformance claim URIs (as defined in 12.1) constitute an extensibility point of the Basic Security Profile. Profiles for other mechanisms for dealing with attachments and attachment security MUST define a URI for claiming conformance.

This Profile 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 Profile;

12.1.1 Conformance

R6000 Conformance to this section of the profile MUST be indicated by a SENDER or RECEIVER by placing a ConformanceClaim element on the wsdl:port or wsdl:binding (per BP 1.0 Section 3.3) in the WSDL description of the service with the following URI: http://ws-i.org/profiles/basic-security/swa/1.0.

R6001 The SECURE_MESSAGE MUST conform to Attachments Profile 1.0.

12.1.2 Scope

R6002 A MIME Part that is signed and/or encrypted using WSS MUST be at the same MIME level as the root MIME Part containing the SECURE_ENVELOPE.

12.2 Signed Attachments

12.2.1 Reference

R6100 A MIME Part signed using WSS MUST be referenced from within the SECURE_ENVELOPE using a wsse:Security/ds:Reference element with a URI attribute of the "cid:partToBeSigned".

12.2.2 Transform

R6101 A ds:Reference within a SECURE_ENVELOPE to a signed MIME Part signed using WSS MUST use a MIME Part Signature Transform designated by the URI [TBD]. This MIME Part Signature Transform and URI will be specified before the final version of this Profile is released. The anticipated venue to define this Transform is the OASIS WSS TC.

12.2.3 Encoding

R6103 A MIME Part signed using WSS MUST have a Content-Transfer-Encoding of binary in effect at the time of WSS processing at both the SENDER and RECEIVER. This does not preclude use of another form of Content-Transfer-Encoding after a message is signed as long as it is removed before the message is verified.

12.3 Encrypted Attachments

12.3.1 Reference

R6200 When a MIME Part is encrypted using WSS, the SECURE_ENVELOPE MUST contain an xenc:DataReference which points to the wsse:Security/../xenc:EncryptedData associated with the encrypted MIME Part.

R6201 A MIME Part encrypted using WSS MUST be referenced from within the SECURE_ENVELOPE using a wsse:Security/.../xenc:EncryptedData element with a Type attribute with the value "http://www.w3.org/2001/04/xmlenc#Content".

R6202 Within a SECURE_ENVELOPE the wsse:Security/.../xenc:EncryptedData element that references a MIME Part encrypted using WSS MUST contain a xenc:CipherData/xenc:CipherReference element with a URI attribute of the form "cid:partToBeEncrypted".

12.3.2 Content

R6203 The content of an MIME Part in a SECURE_MESSAGE encrypted using WSS MUST be replaced by the result of encrypting the content of the MIME Part.

R6204 The content, including MIME Headers and Body, of a decrypted MIME Part in a SECURE_MESSAGE MUST be replaced by the result of decrypting the content of the MIME Part.

R6205 The value of the Content-ID MIME Header of a MIME Part encrypted in a SECURE_MESSAGE using WSS MUST match the value of the Content-ID MIME Header of the MIME Part before it was encrypted.

12.3.3 Transform

R6206 When encrypting a MIME Part using WSS a SENDER MUST use a MIME Part Encryption Transform designated by the URI [TBD]. This MIME Part Encryption Transform and URI will be specified before the final version of this Profile is released. The anticipated venue to define this Transform is the OASIS WSS TC.

R6207 When a MIME Part is encrypted using WSS, the SECURE_ENVELOPE MUST contain an xenc:DataReference that includes a ds:Transform element which references a MIME Part Decryption Transform designated by the URI [TBD]. This MIME Part Decryption Transform and URI will be specified before the final version of this Profile is released. The anticipated venue to define this Transform is the OASIS WSS TC.

13. Security Considerations

This section lists a number of security considerations that should be taken into account when using one or more of the technologies discussed in this profile.

SOAPAction Header
The use of the SOAPAction header in situations where the message content is being integrity or confidentiality protected can result in security risks when the transport layer does not provide the same protection to the SOAPAction header. The most obvious risk is that the SOAPAction header can potentially expose sensitive information about a SOAP message such as the URI of the service, or the context of the transaction that is taking place. Another, more subtle risk occurs in a situation where message routing is done based on the value of the SOAPAction header. By modifying the value, an attacker could cause the message to be directed to a different receiver. This could potentially defeat a replay detection mechanism that was based on the assumption that the message would always be routed to the same place. There is also the additional risk where some processing is performed by an intermediary based on the SOAPAction value. Changing the value of the SOAPAction may cause incorrect processing by the intermediary. This is especially important when the intermediary is performing security processing.
Clock Synchronization
The specifications covered by this profile use time-based mechanisms to prevent replay attacks. These mechanisms will be ineffective unless the system clocks of the various network nodes are synchronized. Since the technology to perform distributed clock synchronization are well known and widely available and are not among the technologies being profiled here, this document does not specify how clock synchronization should be done. However, the recommendation of the use of time-based security mechanisms implies that synchronization is being done.
Key Identifiers and Token Substitution
If a message is signed using a Security Token that binds a public verification key with other claims, and specific processing is performed based on those claims, then in order to protect against post-signature substitution of the Security Token with one that binds the same key to different claims, Security Token itself should be part of the signature computation. This can be acheived by putting a child ds:Reference element whose URI attribute contains a shorthand XPointer reference to the wsse:SecurityTokenReference that specifies the Security Token into the ds:SignedInfo element of a signature.
Binding Security Tokens to Signatures
If a ds:SignedInfo contains one or more ds:Reference children whose URI attribute contains a shorthand XPointer reference to a wsse:SecurityTokenReference that uses a potentially ambiguous mechanism to refer to the Security Token (e.g. KeyIdentifier), then in order to protect against post-signature substitution of the Security Token with one that binds the same key to different claims, it is recommended that at least one ds:Reference use the wsse:SecurityTokenReference deferencing transform. Other references to the wsse:SecurityTokenReference that do not use the wsse:SecurityTokenReference dereferencing transform may also appear.
Uniqueness of ID attributes
XML 1.0 requires that all attributes of type ID in a given XML document have unique values, but only validating XML processors have such type information. As various aspects of SOAP Message Security use ID based references it is recommended that applications ensure that ID attributes are unique by some mechanism.
Encryption Key Substitution
When a key is provided in band within a Token or otherwise for the purpose of specifying a key to be used by another node for encrypting information to be sent in a future message, it is recommended that the sender of the key cryptographicaly bind the key to the message in which it is transmitted. This can be done either by using the key to perform a Signature or HMAC over critical elements of the message body or by including the key under a signature covering critical elements of the message body which uses some other key. If a key is sent in a message which the receiver is expected to use to encrypt data in some future message, there is a risk that an attacker could substitute some other key and thereby be able to read unauthorized data. This is true even if the key is contained in a signed certificate, but is not bound to the current message in some way. If the future encryption key is used to sign the initial request, by verifying the signature, the receiver can determine that the key is the one that was intended.
Signing Security Tokens
In general, tokens contain claims made by an authority, usually about some system entity. Obviously a party relying on these claims must trust that authority to make them. The relying party must generally verify these claims. The method of doing this depends on the token type and is specified by the corresponding token profile.
Signing Username Tokens
When the Token contains only a Username and Password and is simply presented for Authentication, it does not need to be signed because the act of checking it against a stored value has the effect of verifying it. When a nonce and/or timestamp are used with the Username and Password to prevent replay, the Token must be signed to prevent undetected alteration of these fields. If a Password is being used to derive a key for a subsequent encryption of a response, it should be signed to ensure that an attacker doesn not substitute an alternative, but valid Username and Password. This is equivalent to the key substitution attack available when an X.509 Token is used for a similiar purpose.
Signing Binary Tokens
The content of a binary token will be a binary object which is integrity protected by a mechanism specific to the object type. For example, an X.509 certificate will be signed by the issuing authority. The outer wrapper of the binary token merely contains type indication information which does not have to be integrity protected in order to be able to rely in the claims.
Signing XML Tokens
XML tokens should be digitally signed in a manner described by their profile (or documents referenced by it), or delivered directly from their issuer over an integrity protected channel.
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.
Use of password digests 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 prefered 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:
1. If the receiver can access the cleartext password, a digest may be used.
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.
Encryption with signature
When a message contains a data value which does not has 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.

Appendix I: Referenced Specifications

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

Appendix II: Extensibility Points

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

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

In HTTP over TLS:

In Web Services Security: SOAP Message Security:

In XML-Signature Syntax and Processing:

In XML Encryption Syntax and Processing:

Appendix III: Acknowledgements

This Profile 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), Abbie Barbir (Nortel Networks), 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.), Dipak Chopra (SAP AG), Jamie Clark (OASIS), Edward Cobb (BEA Systems Inc.), David Cohen (Merrill Lynch), Ugo Corda (SeeBeyond Technology), Paul Cotton (Microsoft Corporation), Mark Davis (Sarvega Inc.), Alex Deacon (Verisign), Blake Dournaee (Sarvega Inc.), Rob Drew (Charlse Schwab), Gregory Elkins (Reed Elsevier), Mark Ericson (Mindreef), Jon Oyvind Eriksen (Kantega AS), Chris Ferris (IBM), 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), 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), Chris Miller (Accenture), Dale Moberg (Cyclone Commerce), Ron Monzillo (Sun Microsystems), 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 Cecupito (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. ), Davamun 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)