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