Basic Security Profile - Version 1.0 (WGD)

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

Status of this Document

This document is a Working Group Draft; it has been accepted by the Working Group as reflecting the current state of discussions. It is a work in progress, and should not be considered authoritative or final; other documents may supersede this document.

Notice

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

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

Feedback

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

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

1. Introduction

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

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

Section 2, "Document Conventions," describes notational conventions utilized by this Profile.

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.

2. Document Conventions

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

2.1 Security Considerations

The Profile will draw attention to security considerations; however, these are informational only and should be treated as non-normative. Adherence to these considerations does not guarantee security.

where "nnnn" is replaced by a number that is unique among the considerations in the Profile, thereby forming a unique consideration identifier.

2.2 Notational Conventions

The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC2119.

Normative statements of requirements in the Profile (i.e., those impacting conformance, as outlined in "Conformance Requirements") are presented in the following manner:

where "nnnn" is replaced by a number that is unique among the requirements in the Profile, thereby forming a unique requirement identifier.

Requirement identifiers can be considered to be namespace qualified, in such a way as to be compatible with QNames from Namespaces in XML. If there is no explicit namespace prefix on a requirement's identifier (e.g., "R9999" as opposed to "bp10:R9999"), it should be interpreted as being in the namespace identified by the conformance URI of the document section it occurs in. If it is qualified, the prefix should be interpreted according to the namespace mappings in effect, as documented below.

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

Some requirements are derived from ongoing standardization work on the referenced specification(s). For convenience, such forward-derived statements are annotated in the following manner: xxxx, where "xxxx" is an identifier for the specification (e.g., "WSDL20" for WSDL Version 2.0). Note that because such work was not complete when this document was publiished, the specification that the requirement is derived from may change; this information is included only as a convenience to implementers.

Extensibility points in underlying specifications (see "Conformance Scope") are presented in a similar manner:

where "nnnn" is replaced by a number that is unique among the extensibility points in the Profile. As with requirement statements, extensibility statements can be considered namespace-qualified.

This specification uses a number of namespace prefixes throughout; their associated URIs are listed below. Note that the choice of any namespace prefix is arbitrary and not semantically significant.

2.3 Profile Identification and Versioning

This document is identified by a name (in this case, Basic Security Profile) and a version number (here, 1.0). Together, they identify a particular profile instance.

Version numbers are composed of a major and minor portion, in the form "major.minor". They can be used to determine the precedence of a profile instance; a higher version number (considering both the major and minor components) indicates that an instance is more recent, and therefore supersedes earlier instances.

Instances of profiles with the same name (e.g., "Example Profile 1.1" and "Example Profile 5.0") address interoperability problems in the same general scope (although some developments may require the exact scope of a profile to change between instances).

One can also use this information to determine whether two instances of a profile are backwards-compatible; that is, whether one can assume that conformance to an earlier profile instance implies conformance to a later one. Profile instances with the same name and major version number (e.g., "Example Profile 1.0" and "Example Profile 1.1") MAY be considered compatible. Note that this does not imply anything about compatibility in the other direction; that is, one cannot assume that conformance with a later profile instance implies conformance to an earlier one.

3 Profile Conformance

Conformance to the Profile is defined by adherence to the set of requirements defined for a specific target, within the scope of the Profile. This section explains these terms and describes how conformance is defined and used.

3.1 Conformance Requirements

Requirements state the criteria for conformance to the Profile. They typically refer to an existing specification and embody refinements, amplifications, interpretations and clarifications to it in order to improve interoperability. All requirements in the Profile are considered normative, and those in the specifications it references that are in-scope (see "Conformance Scope") should likewise be considered normative. When requirements in the Profile and its referenced specifications contradict each other, the Profile's requirements take precedence for purposes of Profile conformance.

Requirement levels, using RFC2119 language (e.g., MUST, MAY, SHOULD) indicate the nature of the requirement and its impact on conformance. Each requirement is individually identified (e.g., R9999) for convenience.

This requirement is identified by "R9999", applies to the target WIDGET (see below), and places a conditional requirement upon widgets; i.e., although this requirement must be met to maintain conformance in most cases, there are some situations where there may be valid reasons for it not being met (which are explained in the requirement itself, or in its accompanying text).

Each requirement statement contains exactly one requirement level keyword (e.g., "MUST") and one conformance target keyword (e.g., "MESSAGE"). The conformance target keyword appears in bold text (e.g. "MESSAGE"). Other conformance targets appearing in non-bold text are being used strictly for their definition and NOT as a conformance target. Additional text may be included to illuminate a requirement or group of requirements (e.g., rationale and examples); however, prose surrounding requirement statements must not be considered in determining conformance.

Definitions of terms in the Profile are considered authoritative for the purposes of determining conformance.

None of the requirements in the Profile, regardless of their conformance level, should be interpreted as limiting the ability of an otherwise conforming implementation to apply security countermeasures in response to a real or perceived threat (e.g., a denial of service attack).

3.2 Conformance Targets

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

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

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

3.3 Conformance Scope

The scope of the Profile delineates the technologies that it addresses; in other words, the Profile only attempts to improve interoperability within its own scope. Generally, the Profile's scope is bounded by the specifications referenced by it.

The Profile's scope is further refined by extensibility points. Referenced specifications often provide extension mechanisms and unspecified or open-ended configuration parameters; when identified in the Profile as an extensibility point, such a mechanism or parameter is outside the scope of the Profile, and its use or non-use is not relevant to conformance.

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

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

The Profile's scope is defined by the referenced specifications in Appendix A, as refined by the extensibility points in Appendix B.

3.4 Claiming Conformance

Claims of conformance to the Profile can be made using the following mechanisms, as described in Conformance Claim Attachment Mechanisms, when the applicable Profile requirements associated with the listed targets have been met:

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

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 only protected when SSL or TLS is used, and even then only between adjacent SOAP nodes. 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:

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 A SECURITY_TOKEN named wsse:BinarySecurityToken MUST specify an EncodingType attribute.

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

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

INCORRECT:

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

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

CORRECT:

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

5.1.2 Binary Security Token ValueType Attribute

There is no appropriate default for ValueType.

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

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

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

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

INCORRECT:

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

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

INCORRECT:

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

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

CORRECT:

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

5.2 SecurityTokenReferences

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

5.2.1 Internal References

Reference by Key Identifier may be ambiguous.

R3022 When a SECURITY_TOKEN_REFERENCE references an INTERNAL_SECURITY_TOKEN which has a wsu:Id attribute, the reference MUST use either a Direct Reference or an Embedded Reference.

Direct and Embedded are preferred over Key Identifier References.

INCORRECT:

<!-- This example is incorrect because it refers to a wsse:BinarySecurityToken element which specifies a wsu:id
     attribute using a wsse:KeyIdentifier element rather than a wsse:Reference or wsse:Embedded element -->

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

5.2.2 Shorthand XPointer References

Constraining the number of different referencing mechanisms reduces complexity and thus improves interoperability. The wsse:BinarySecurityToken, the element which contains the security token, has a wsu:Id attribute allowing references to this token to use Shorthand XPointers.

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

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#X509"
                           EncodingType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-soap-message-security-1.0#Base64Binary">
lui+Jy4WYKGJW5xM3aHnLxOpGVIpzSg4V486hHFe7sHET/uxxVBovT7JV1A2RnWSWkXm9jAEdsm/...
 </wsse:BinarySecurityToken>
 <xenc:EncryptedKey>
   <xenc:EncryptionMethod Algorithm='http://www.w3.org/2001/04/xmlenc#rsa-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#X509"/>
    </wsse:SecurityTokenReference>
   </ds:KeyInfo>
   <xenc:CipherData>
     <xenc:CipherValue>
       XZEEVABD3L9G+VNTCDiDTE7WB1a4kILtz5f9FT747eE=       
     </xenc:CipherValue>
   </xenc:CipherData>
 </xenc:EncryptedKey>
</wsse:Security>

CORRECT:

<wsse:Security xmlns:wsse='http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd' 
               xmlns:wsu='http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd' 
               xmlns:xenc='http://www.w3.org/2001/04/xmlenc#' 
               xmlns:ds='http://www.w3.org/2000/09/xmldsig#' >
 <rel:license xmlns:rel='urn:mpeg:mpeg21:2003:01-REL-R-NS'
              wsu:Id='SomeLic' 
              licenseId='uuid:3D680C71-177B-40cc-84C1-123B02503524' >
 . . .
 </rel:license>
 <ds:Signature>
   . . .
   <ds:KeyInfo>
    <wsse:SecurityTokenReference>
     <wsse:Reference
       URI='#SomeLic'
       ValueType="http://docs.oasis-open.org/wss/2004/##/oasis-####-wss-REL-token-profile-1.0#license" />
    </wsse:SecurityTokenReference>
   </ds:KeyInfo>
 </ds:Signature>
</wsse:Security>

5.2.3 References to Preceding Security Tokens

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

R5205 An INTERNAL_SECURITY_TOKEN MUST precede the first SECURITY_TOKEN_REFERENCE that references it.

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

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'
         ValueType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-x509-token-profile-1.0#X509"/>
     </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#X509"
                           EncodingType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-soap-message-security-1.0#Base64Binary">
lui+Jy4WYKGJW5xM3aHnLxOpGVIpzSg4V486hHFe7sHET/uxxVBovT7JV1A2RnWSWkXm9jAEdsm/...
 </wsse:BinarySecurityToken>
</wsse:Security>

CORRECT:

<wsse:Security xmlns:wsse='http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd' 
               xmlns:wsu='http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd' 
               xmlns:xenc='http://www.w3.org/2001/04/xmlenc#' 
               xmlns:ds='http://www.w3.org/2000/09/xmldsig#' >
 <wsse:BinarySecurityToken wsu:Id='SomeCert'
                           ValueType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-x509-token-profile-1.0#X509"
                           EncodingType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-soap-message-security-1.0#Base64Binary">
lui+Jy4WYKGJW5xM3aHnLxOpGVIpzSg4V486hHFe7sHET/uxxVBovT7JV1A2RnWSWkXm9jAEdsm/...
 </wsse:BinarySecurityToken>
 <xenc:EncryptedKey>
   <xenc:EncryptionMethod Algorithm='http://www.w3.org/2001/04/xmlenc#rsa-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#X509"/>
     </wsse:SecurityTokenReference>
   </ds:KeyInfo>
   <xenc:CipherData>
     <xenc:CipherValue>
       XZEEVABD3L9G+VNTCDiDTE7WB1a4kILtz5f9FT747eE=       
     </xenc:CipherValue>
   </xenc:CipherData>
 </xenc:EncryptedKey>
</wsse:Security>

5.2.4 Direct Preferred to Embedded for Internal References

Since multiple security elements may reference a single 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 Each SECURITY_TOKEN_REFERENCE that refers to an INTERNAL_SECURITY_TOKEN that is referenced several times SHOULD be a direct reference rather than an embedded reference.

Direct references are encouraged. Embedded references are discouraged.

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#X509"
                                   EncodingType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-soap-message-security-1.0#Base64Binary">
lui+Jy4WYKGJW5xM3aHnLxOpGVIpzSg4V486hHFe7sHET/uxxVBovT7JV1A2RnWSWkXm9jAEdsm/...
         </wsse:BinarySecurityToken>
      </wsse:Embedded>
   </wsse:SecurityTokenReference>
</wsse:Security>

CORRECT:

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

5.2.5 Direct Required When Possible for External References

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

CORRECT:

<wsse:Security xmlns:wsse='http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd' 
               xmlns:wsu='http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd' 
               xmlns:xenc='http://www.w3.org/2001/04/xmlenc#' 
               xmlns:ds='http://www.w3.org/2000/09/xmldsig#' >

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

5.2.6 Format of Embedded References

R3025 When a wsse:Embedded element in a SECURITY_TOKEN_REFERENCE is used to specify an inline INTERNAL_SECURITY_TOKEN, its format MUST be the same as if the token were a child of a SECURITY_HEADER.

INCORRECT:

<!-- This example is incorrect because the wsse:Embedded element carries the data for the X.509 certificate
     directly rather than as a wsse:BinarySecurityToken element  -->

<wsse:SecurityTokenReference>
   <wsse:Embedded wsu:Id="SomeCert">
lui+Jy4WYKGJW5xM3aHnLxOpGVIpzSg4V486hHFe7sHET/uxxVBovT7JV1A2RnWSWkXm9jAEdsm/...
   </wsse:Embedded>
</wsse:SecurityTokenReference>

CORRECT:

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

5.2.7 Key Identifier for External References

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

CORRECT:

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

CORRECT:

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

5.2.8 Key Name References Prohibited

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

INCORRECT:

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

<wsse:SecurityTokenReference>
   <ds:KeyName>CN=Security WG, OU=BSP, O=WS-I, C=US</ds:KeyName>
</wsse:SecurityTokenReference>

5.2.9 KeyIdentifier/@ValueType Attribute

R3054 A wsse:KeyIdentifier element in a SECURITY_TOKEN_REFERENCE MUST specify a ValueType attribute.

R3063 A ValueType attribute on a wsse:KeyIdentifier element in a SECURITY_TOKEN_REFERENCE MUST have a value specified within the security token profile associated with the referenced SECURITY_TOKEN.

INCORRECT:

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

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

CORRECT:

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

5.2.10 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 a token profile.

INCORRECT:

<!-- This example is incorrect because the wsse:Embedded element contains a wsse:SecurityTokenReference element -->

<wsse:SecurityTokenReference>
   <wsse:Embedded wsu:Id="TheEmbeddedElementAroundSomeSTR">
      <wsse:SecurityTokenReference>
         <wsse:Reference URI='#SomeCert'
                         ValueType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-x509-token-profile-1.0#X509" />
      </wsse:SecurityTokenReference>
   </wsse:Embedded>
</wsse:SecurityTokenReference>

INCORRECT:

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

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

CORRECT:

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

5.2.11 Reference from wsse:SecurityTokenReference to wsse:SecurityTokenReference

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

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

INCORRECT:

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

CORRECT:

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

5.2.12 wsse:SecurityTokenReference/Reference ValueType Attribute

R3059 A wsse:Reference element in a SECURITY_TOKEN_REFERENCE MUST specify a ValueType attribute.

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

5.2.13 wsse:SecurityTokenReference constraints

R3061 A SECURITY_TOKEN_REFERENCE MUST have exactly one child element.

R3062 A wsse:Reference element in a SECURITY_TOKEN_REFERENCE MUST specify a URI attribute.

5.2.14 wsse:SecurityTokenReference Dereferencing Transform

R3065 When a SIGNATURE 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/wsu:Created

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 A TIMESTAMP MUST have exactly one wsu:Created element child.

INCORRECT:

<!-- This example is incorrect because the wsu:Timestamp element is missing a wsu:Created child element -->

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

CORRECT:

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

5.3.2 Occurence constraints on wsu:Created and wsu:Expires

R3223 A TIMESTAMP MUST NOT contain more than one wsu:Created element.

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

R3221 If a TIMESTAMP contains both a wsu:Created element and a wsu:Expires element they MUST appear in the order: wsu:Created then wsu:Expires.

5.3.3 Value constraints on wsu:Created and wsu:Expires

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

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

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

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

5.3.4 wsu:Timestamp inside wsse:Security header

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

R3219 A SECURITY_HEADER MUST NOT contain more than one TIMESTAMP.

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 SECURITY_HEADER, all SIGNATURE, ENCRYPTED_KEY, and ENCRYPTION_REFERENCE_LIST elements MUST be ordered so a receiver will get the correct result by processing the elements in the order they appear.

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 SECURITY_HEADER with the actor attribute omitted.

R3210 Within a SECURE_ENVELOPE there MUST be at most one SECURITY_HEADER with the same actor attribute value.

6. Username Token Profile

This section of the Profile incorporates the following specifications by reference:

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 A wsse:UsernameToken/wsse:Password element in a SECURITY_HEADER MUST specify a Type attribute.

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

6.1.3 ValueType attribute

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

6.1.4 Reference by KeyIdentifier

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

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

6.1.6 Sign UsernameToken

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

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

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: X509v3; x509PKIPathv1; and PKCS7. 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 SECURITY_TOKEN_REFERENCE to specify a reference to an X.509 Certificate Token, 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.

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 with Web Services Security: SOAP Message Security. This Profile places no constraints on other use of XML Signature.

This section of the Profile incorporates the following specifications by reference:

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 A SIGNATURE MUST NOT be an Enveloping Signature as defined by the XML Signature specification.

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

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

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

INCORRECT:

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

<ds:Signature Id='TheSig' xmlns:ds='http://www.w3.org/2000/09/xmldsig#'>
   <ds:SignedInfo>
      <ds:CanonicalizationMethod Algorithm='http://www.w3.org/2001/10/xml-exc-c14n#" '>
         <c14n:InclusiveNamespaces xmlns:c14n='http://www.w3.org/2001/10/xml-exc-c14n#' PrefixList='wsse soap' />
      </ds:CanonicalizationMethod>
      <ds:SignatureMethod Algorithm='http://www.w3.org/2000/09/xmldsig#rsa-sha1' />
      <ds:Reference URI='#SigPropBody'>
         <ds:Transforms>
            <ds:Transform Algorithm='http://www.w3.org/2001/10/xml-exc-c14n#'>
               <c14n:InclusiveNamespaces xmlns:c14n='http://www.w3.org/2001/10/xml-exc-c14n#' PrefixList='' />
            </ds:Transform>
         </ds:Transforms>
         <ds:DigestMethod Algorithm='http://www.w3.org/2000/09/xmldsig#sha1' />
         <ds:DigestValue>i3qi5GjhHnfoBn/jOjQp2mq0Na4=</ds:DigestValue>
      </ds:Reference>
   </ds:SignedInfo>
   <ds:SignatureValue>oxNwoqGbzqg1YBliz+PProgcjw8=</ds:SignatureValue>
   <ds:KeyInfo>
      <wsse:SecurityTokenReference>
         <wsse:Reference
            URI='#SomeCert'
            ValueType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-x509-token-profile-1.0#X509"/>
      </wsse:SecurityTokenReference>
   </ds:KeyInfo>
   <ds:Object>
      <ds:SignatureProperties>
         <ds:SignatureProperty Id='SigPropBody' Target='#TheSig'>
            <SomeSecurityToken/>
         </ds:SignatureProperty>
      </ds:SignatureProperties>
   </ds:Object>
</ds:Signature>

CORRECT:

<ds:Signature xmlns:ds='http://www.w3.org/2000/09/xmldsig#'>
   <ds:SignedInfo>
      <ds:CanonicalizationMethod Algorithm='http://www.w3.org/2001/10/xml-exc-c14n#" '>
         <c14n:InclusiveNamespaces xmlns:c14n='http://www.w3.org/2001/10/xml-exc-c14n#'
                                   PrefixList='wsse soap' />
      </ds:CanonicalizationMethod>
      <ds:SignatureMethod Algorithm='http://www.w3.org/2000/09/xmldsig#rsa-sha1' />
      <ds:Reference URI='#TheBody'>
         <ds:Transforms>
            <ds:Transform Algorithm='http://www.w3.org/2001/10/xml-exc-c14n#'>
               <c14n:InclusiveNamespaces xmlns:c14n='http://www.w3.org/2001/10/xml-exc-c14n#'
                                         PrefixList='soap wsu m' />
            </ds:Transform>
         </ds:Transforms>
         <ds:DigestMethod Algorithm='http://www.w3.org/2000/09/xmldsig#sha1' />
         <ds:DigestValue>i3qi5GjhHnfoBn/jOjQp2mq0Na4=</ds:DigestValue>
      </ds:Reference>
   </ds:SignedInfo>
   <ds:SignatureValue>PipXJ2Sfc+LTDnq4pM5JcIYt9gg=</ds:SignatureValue>
   <ds:KeyInfo>
      <wsse:SecurityTokenReference>
         <wsse:Reference URI='#SomeCert'
                         ValueType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-x509-token-profile-1.0#X509" />
      </wsse:SecurityTokenReference>
   </ds:KeyInfo>
</ds:Signature>

8.2 Element References in XML Signature

The following specifications (or sections thereof) are referred to in this section of the 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 Elements by Shorthand XPointer

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

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

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

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

8.2.2 Reference to Elements by XPath Expression

Elements that do not have an attribute of type ID cannot be refered to by Shorthand XPointer References so a different referencing mechanism is needed. The XPath Filter 2.0 transform is more efficient than 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 a ds:Reference in a SIGNATURE the XPath Filter 2.0 Transform (http://www.w3.org/2002/06/xmldsig-filter2) MUST be used to refer to that element.

INCORRECT:

<!-- This example is incorrect because it uses the http://www.w3.org/TR/1999/REC-xpath-19991116 transform 
     to reference the Body which contains an ID attribute -->

<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#X509">
lui+Jy4WYKGJW5xM3aHnLxOpGVIpzSg4V486hHFe7sHET/uxxVBovT7JV1A2RnWSWkXm9jAEdsm/...
     </wsse:BinarySecurityToken>
     <ds:Signature xmlns:ds='http://www.w3.org/2000/09/xmldsig#'>
       <ds:SignedInfo>
         <ds:CanonicalizationMethod Algorithm='http://www.w3.org/2001/10/xml-exc-c14n#" '>
           <c14n:InclusiveNamespaces xmlns:c14n='http://www.w3.org/2001/10/xml-exc-c14n#'
                                     PrefixList='wsse soap wsu' />
         </ds:CanonicalizationMethod>
         <ds:SignatureMethod Algorithm='http://www.w3.org/2000/09/xmldsig#rsa-sha1' />
         <ds:Reference URI=''>
           <ds:Transforms>
             <ds:Transform Algorithm='http://www.w3.org/TR/1999/REC-xpath-19991116'>
               <ds:XPath>/soap:Envelope/soap:Body/*</ds:XPath>
             </ds:Transform>
             <ds:Transform Algorithm='http://www.w3.org/2001/10/xml-exc-c14n#'>
               <c14n:InclusiveNamespaces xmlns:c14n='http://www.w3.org/2001/10/xml-exc-c14n#'
                                         PrefixList='soap wsu m' />
             </ds:Transform>
           </ds:Transforms>
           <ds:DigestMethod Algorithm='http://www.w3.org/2000/09/xmldsig#sha1' />
           <ds:DigestValue>VEPKwzfPGOxh2OUpoK0bcl58jtU=</ds:DigestValue>
         </ds:Reference>
       </ds:SignedInfo>
       <ds:SignatureValue>+diIuEyDpV7qxVoUOkb5rj61+Zs=</ds:SignatureValue>
       <ds:KeyInfo>
         <wsse:SecurityTokenReference>
            <wsse:Reference
              URI='#SomeCert'
              ValueType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-x509-token-profile-1.0#X509" />
         </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#X509">
lui+Jy4WYKGJW5xM3aHnLxOpGVIpzSg4V486hHFe7sHET/uxxVBovT7JV1A2RnWSWkXm9jAEdsm/...
      </wsse:BinarySecurityToken>
      <ds:Signature xmlns:ds='http://www.w3.org/2000/09/xmldsig#'>
        <ds:SignedInfo>
          <ds:CanonicalizationMethod Algorithm='http://www.w3.org/2001/10/xml-exc-c14n#" '>
            <c14n:InclusiveNamespaces xmlns:c14n='http://www.w3.org/2001/10/xml-exc-c14n#'
                                      PrefixList='wsse soap wsu' />
          </ds:CanonicalizationMethod>
          <ds:SignatureMethod Algorithm='http://www.w3.org/2000/09/xmldsig#rsa-sha1' />
          <ds:Reference URI=''>
            <ds:Transforms>
              <ds:Transform Algorithm='http://www.w3.org/2002/06/xmldsig-filter2'
                            xmlns:dsxp='http://www.w3.org/2002/06/xmldsig-filter2'>
                <dsxp:XPath Filter='intersect'>/soap:Envelope/soap:Body/*</dsxp:XPath>
              </ds:Transform>
              <ds:Transform Algorithm='http://www.w3.org/2001/10/xml-exc-c14n#'>
                <c14n:InclusiveNamespaces xmlns:c14n='http://www.w3.org/2001/10/xml-exc-c14n#'
                                          PrefixList='soap wsu m' />
              </ds:Transform>
            </ds:Transforms>
            <ds:DigestMethod Algorithm='http://www.w3.org/2000/09/xmldsig#sha1' />
            <ds:DigestValue>VEPKwzfPGOxh2OUpoK0bcl58jtU=</ds:DigestValue>
          </ds:Reference>
        </ds:SignedInfo>
        <ds:SignatureValue>+diIuEyDpV7qxVoUOkb5rj61+Zs=</ds:SignatureValue>
        <ds:KeyInfo>
          <wsse:SecurityTokenReference>
            <wsse:Reference
              URI='#SomeCert'
              ValueType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-x509-token-profile-1.0#X509" />
          </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 SIGNATURE MUST have a value of "http://www.w3.org/2001/10/xml-exc-c14n#" indicating that is uses Exclusive C14N without comments for canonicalization.

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

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

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

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

INCORRECT:

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

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

INCORRECT:

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

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

INCORRECT:

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

<soap:Envelope xmlns:soap='http://schemas.xmlsoap.org/soap/envelope' >
  <soap:Header>
    <wsse:Security xmlns:wsse='http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd'
                   xmlns:wsu='http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd'>
      <wsse:BinarySecurityToken wsu:Id='SomeCert'
                                ValueType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-x509-token-profile-1.0#X509">
lui+Jy4WYKGJW5xM3aHnLxOpGVIpzSg4V486hHFe7sHET/uxxVBovT7JV1A2RnWSWkXm9jAEdsm/...
      </wsse:BinarySecurityToken>
      <ds:Signature xmlns:ds='http://www.w3.org/2000/09/xmldsig#'>
        <ds:SignedInfo>
          <ds:CanonicalizationMethod Algorithm='http://www.w3.org/2001/10/xml-exc-c14n#" '>
            <c14n:InclusiveNamespaces xmlns:c14n='http://www.w3.org/2001/10/xml-exc-c14n#'
                                      PrefixList='wsse' />
          </ds:CanonicalizationMethod>
          <ds:SignatureMethod Algorithm='http://www.w3.org/2000/09/xmldsig#rsa-sha1' />
          <ds:Reference URI='#TheBody'>
            <ds:T

Basic Security Profile Version 1.0

Working Group Draft

Date: 2005/01/20

Abstract

Status of this Document

Notice

Feedback

Table of Contents

1. Introduction

1.1 Guiding Principles

2. Document Conventions

2.1 Security Considerations

2.2 Notational Conventions

2.3 Profile Identification and Versioning

3 Profile Conformance

3.1 Conformance Requirements

3.2 Conformance Targets

3.3 Conformance Scope

3.4 Claiming Conformance

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

5.2.2 Shorthand XPointer References

5.2.3 References to Preceding Security Tokens

5.2.4 Direct Preferred to Embedded for Internal References

5.2.5 Direct Required When Possible for External References

5.2.6 Format of Embedded References

5.2.7 Key Identifier for External References

5.2.8 Key Name References Prohibited

5.2.9 KeyIdentifier/@ValueType Attribute

5.2.10 Children of wsse:Embedded

5.2.11 Reference from wsse:SecurityTokenReference to wsse:SecurityTokenReference

5.2.12 wsse:SecurityTokenReference/Reference ValueType Attribute

5.2.13 wsse:SecurityTokenReference constraints

5.2.14 wsse:SecurityTokenReference Dereferencing Transform

5.3 Timestamps

5.3.1 wsu:Timestamp/wsu:Created

5.3.2 Occurence constraints on wsu:Created and wsu:Expires

5.3.3 Value constraints on wsu:Created and wsu:Expires

5.3.4 wsu:Timestamp inside wsse:Security header

5.4 wsu:Id References

5.4.1 wsu:Id Attribute Uniqueness

5.5 wsse:Security Processing Order

5.5.1 Order of Processing

5.6 SOAP Actor

5.6.1 SOAP Actor Value

6. Username Token Profile

6.1 Token Usage

6.1.1 wsse:UsernameToken/wsse:Password/@Type

6.1.2 PasswordDigest

6.1.3 ValueType attribute

6.1.4 Reference by KeyIdentifier

6.1.5 Key Derivation

6.1.6 Sign UsernameToken

7. X.509 Certificate Token Profile

7.1 Token Types

7.1.1 Certificate Path

7.1.2 KeyIdentifier

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 Elements by Shorthand XPointer

8.2.2 Reference to Elements by XPath Expression

8.3 XML Signature Algorithms

8.3.1 Use Exclusive C14N