Basic Security Profile Version 1.1

WS-I Approval Draft


This version:
Latest version:
Michael McIntosh, IBM
Martin Gudgin, Microsoft
K. Scott Morrison, Layer 7
Abbie Barbir, Nortel Networks
Administrative contact:


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

Status of this Document

This document is a WS-I Approval Draft; it has been approved for publication by the Board of Directors, and is submitted for consideration by the Membership, and for public comment. It is a work in progress, and should not be considered as final; other documents may supersede this document.


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.



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

Table of Contents

1. Introduction
1.1. Guiding Principles
1.2. Notational Conventions
1.3. Profile Identification and Versioning
2. Profile Conformance
2.1. Conformance Requirements
2.2. Conformance Targets
2.3. Conformance Scope
2.4. Claiming Conformance
3. Document Conventions
3.1. Security Considerations
4. Transport Layer Mechanisms
4.1. TLS and SSL Versions
4.1.1. SSL 2.0 Prohibited
4.2. TLS and SSL Ciphersuites
4.2.1. Mandatory Ciphersuites
4.2.2. Recommended Ciphersuites
4.2.3. Discouraged Ciphersuites
4.2.4. Prohibited Ciphersuites
5. SOAP Nodes and Messages
5.1. Security Policy
5.1.1. Out of Band Agreement
5.2. SOAP Envelope
5.2.1. Secure Envelope Validity
5.2.2. wsu:Id Attribute Value Uniqueness
5.3. Intermediary Processing
5.3.1. Removal of Headers
5.4. Basic Profile Clarification
5.4.1. BP Requirement R1029
5.4.2. BP Requirement R2301
5.4.3. BP Requirement R2710
5.4.4. BP Requirement R2712
5.4.5. BP Requirement R2724
5.4.6. BP Requirement R2725
5.4.7. BP Requirement R2729
5.4.8. BP Requirement R2738
6. SecurityHeaders
6.1. Processing Order
6.1.1. In Order of Appearance
6.2. SOAP Actor Attribute
6.2.1. Avoid Target Ambiguity
7. Timestamps
7.1. Placement
7.1.1. Not More Than One per Security Header
7.2. Content
7.2.1. Exactly One Created per Timestamp
7.2.2. Not More Than One Expires per Timestamp
7.2.3. Created Precedes Expires in Timestamp
7.2.4. Timestamp Contains Nothing Other Than Create and Expires
7.3. Constraints on Created and Expires
7.3.1. Value Precision to Milliseconds
7.3.2. Leap Second Values Prohibited
7.3.3. ValueType Attribute Prohibited
7.3.4. UTC Format Mandatory
8. Security Token References
8.1. Content
8.1.1. Exactly One SecurityTokenReference Child Element
8.2. TokenType Attribute
8.2.1. Value of TokenType Attribute
8.3. Direct References
8.3.1. Direct Reference to Security Token Reference Prohibited
8.3.2. Reference/@ValueType Attribute Mandatory
8.3.3. Reference/@URI Attribute Mandatory
8.4. Key Name References
8.4.1. Key Name References Prohibited
8.5. Key Identifier References
8.5.1. KeyIdentifier/@ValueType Attribute Mandatory
8.5.2. KeyIdentifier/@EncodingType Attribute Mandatory
8.6. Embedded References
8.6.1. Embedded Content
8.6.2. Embedded Token Format
8.6.3. Security Token Reference in Embedded Prohibited
8.7. Internal References
8.7.1. Direct or Embedded References Where Possible
8.7.2. Direct Preferred to Embedded References
8.7.3. Shorthand XPointers Mandatory for Direct References
8.7.4. Security Tokens Precede Their References
8.7.5. References Between Security Headers Prohibited
8.8. External References
8.8.1. Direct References Where Possible
8.9. SecurityTokenReference With EncryptedData
8.9.1. Reference to KeyInfo Prohibited
9. XML-Signature
9.1. Types of Signature
9.1.1. Enveloping Signatures Prohibited
9.1.2. Enveloped Signatures Discouraged
9.1.3. Detached Signatures Preferred
9.2. Signed Element References
9.2.1. Shorthand XPointer Where Referent has wsu:Id Attribute
9.2.2. Shorthand XPointer Where Referent is defined by XML Signature
9.2.3. Shorthand XPointer Where Referent is defined by XML Encryption
9.2.4. Shorthand XPointer to wsu:Id Attribute Where Possible
9.2.5. XPath References Where Necessary
9.3. Signature Transforms
9.3.1. Transforms Element Mandatory
9.3.2. Transform Element Mandatory
9.3.3. Transform Algorithms
9.3.4. Last Transform Algorithm
9.3.5. Inclusive Namespaces with Exclusive-C14N Transform
9.3.6. Inclusive Namespaces with STR Transform
9.3.7. TransformationParameters and CanonicalizationMethod with STR Transform
9.4. Canonicalization Methods
9.4.1. Exclusive C14N Mandatory
9.4.2. Inclusive Namespaces with Exclusive-C14N
9.5. Inclusive Namespaces
9.5.1. Order of PrefixList
9.5.2. Whitespace in PrefixList
9.5.3. PrefixList Contents
9.6. Digest Methods
9.6.1. SHA-1 Preferred
9.7. Signature Methods
9.7.1. Algorithms
9.7.2. HMACOutputLength Prohibited
9.8. KeyInfo
9.8.1. Exactly One KeyInfo Child Element
9.8.2. SecurityTokenReference Mandatory
9.9. Manifest
9.9.1. Manifest Prohibited
9.10. Signature Encryption
9.10.1. Encrypt Only Entire Signature
9.11. Signature Confirmation
9.11.1. Signature Confirmation Format
10. XML Encryption
10.1. EncryptedHeader
10.1.1. EncryptedHeader Format
10.2. Encryption ReferenceList
10.2.1. Single Key
10.2.2. Encryption DataReference for EncryptedData
10.3. EncryptedKey ReferenceList
10.3.1. EncryptedKey DataReference for EncryptedData
10.4. EncryptedKey
10.4.1. EncryptedKey Precedes EncryptedData
10.4.2. EncryptedKey/@Type Attribute Prohibited
10.4.3. EncryptedKey/@MimeType Attribute Prohibited
10.4.4. EncryptedKey/@Encoding Attribute Prohibited
10.4.5. EncryptedKey/@Recipient Attribute Prohibited
10.4.6. EncryptionMethod Mandatory
10.5. EncryptedData
10.5.1. EncryptedData and KeyInfo
10.5.2. EncryptedData/@Id or EncryptedHeader/@wsu:Id Attribute Mandatory
10.5.3. EncryptedData EncryptionMethod Mandatory
10.6. Encryption KeyInfo
10.6.1. Exactly One Encryption KeyInfo Child Element
10.6.2. KeyInfo SecurityTokenReference Mandatory
10.7. Encryption DataReference
10.7.1. DataReference/@URI with Shorthand XPointer to EncryptedData or EncryptedHeader
10.8. EncryptedKey DataReference
10.8.1. EncryptedKey DataReference/@URI with Shorthand XPointer to EncryptedData
10.9. Encryption KeyReference
10.9.1. KeyReference/@URI with Shorthand XPointer to EncryptedKey
10.10. EncryptedKey KeyReference
10.10.1. EncryptedKey KeyReference/@URI with Shorthand XPointer to EncryptedKey
10.11. EncryptedData EncryptionMethod
10.11.1. Data Encryption Algorithms
10.12. EncryptedKey EncryptionMethod
10.12.1. Key Transport Algorithms
10.12.2. Key Wrap Algorithms
10.12.3. Key Encryption Algorithms
10.13. Encrypted Headers
10.13.1. Encrypted Headers
11. Binary Security Tokens
11.1. Binary Security Tokens
11.1.1. BinarySecurityToken/@EncodingType Attribute Mandatory
11.1.2. BinarySecurityToken/@ValueType Attribute Mandatory
12. Username Token
12.1. Password
12.1.1. Not More Than One Password
12.1.2. Password/@Type Attribute Mandatory
12.1.3. Digest Value
12.1.4. Key Derivation
12.2. Created
12.2.1. Not More Than One Created
12.3. Nonce
12.3.1. Not More Than One Nonce
12.3.2. Nonce/@EncodingType Attribute Mandatory
12.4. SecurityTokenReference
12.4.1. UsernameToken Reference/@ValueType Attribute Value
12.4.2. UsernameToken KeyIdentifier Prohibited
13. X.509 Certificate Token
13.1. X.509 Token Types
13.1.1. X.509 Token Format
13.1.2. Certificate Path Token Types
13.1.3. PKCS7 Token Format
13.2. SecurityTokenReference
13.2.1. SecurityTokenReference to X.509 Token
13.2.2. SecurityTokenReference to PKCS7 Token
13.2.3. PkiPath Token Format
13.2.4. SecurityTokenReference to PkiPath Token
13.2.5. KeyIdentifier or X509IssuerSerial for External References
13.2.6. KeyIdentifier/@ValueType Attribute Value
13.2.7. KeyIdentifier Value
13.2.8. X509IssuerSerial Value
14. REL Token
14.1. SecurityTokenReferences
14.1.1. SecurityTokenReference to REL Token
14.1.2. Reference by licenseId Prohibited When wsu:Id Present
14.1.3. Issuer Signature on REL Token Precedes First Reference
15. Kerberos Token
15.1. Content
15.1.1. Kerberos Token Format
15.1.2. Internal Token in First Message
15.1.3. External Token in Subsequent Messages
15.2. SecurityTokenReference
15.2.1. SecurityTokenReference to Kerberos Token
15.2.2. KeyIdentifier ValueType for Kerberos
15.2.3. KeyIdentifier for External Token
16. SAML Token
16.1. KeyInfo
16.1.1. References to SAML Tokens Prohibited
16.2. SecurityTokenReference
16.2.1. SecurityTokenReference to SAML V1.1 Token
16.2.2. SecurityTokenReference to SAML V2.0 Token
16.2.3. KeyIdentifier/@ValueType Attribute
16.2.4. KeyIdentifier/@EncodingType Attribute
16.2.5. References to Internal SAML Assertions
16.2.6. References to External SAML Assertions
17. EncryptedKey Token
17.1. SecurityTokenReference
17.1.1. SecurityTokenReference to EncryptedKey Token
18. Attachment Security
18.1. SOAP with Attachments
18.1.1. Conformance
18.1.2. Relationship between Parts
18.1.3. Encryption and Root Part
18.2. Signed Attachments
18.2.1. Reference to Signed Attachments
18.2.2. Attachment Transforms
18.2.3. Canonicalization
18.2.4. Digest Values
18.2.5. Content-Type
18.3. Encrypted Attachments
18.3.1. References to Encrypted Attachments
18.3.2. Type attribute
18.3.3. Reference URIs
18.3.4. Content
19. Security Considerations
19.1. SOAPAction Header
19.1.1. SOAPAction header
19.2. Clock Synchronization
19.3. Security Token Substitution
19.3.1. Security Token Substitution
19.3.2. Security Token Reference in Subsequent Messages
19.4. Protecting against removal and modification of XML Elements
19.5. Only What is Signed is Protected
19.6. Use of SHA1
19.7. Uniqueness of ID attributes
19.8. Signing Security Tokens
19.9. Signing Username Tokens
19.10. Signing Binary Tokens
19.11. Signing XML Tokens
19.12. Replay of Username Token
19.12.1. Replay of Username Token
19.13. Use of Digest vs. Cleartext Password
19.14. Encryption with Signatures
19.14.1. Encrypt DigestValue
19.15. Possible Operational Errors
Appendix A: Referenced Specifications
Appendix B: Extensibility Points
Appendix C: Normative References
Appendix D: Acknowledgements

1. Introduction

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

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

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

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

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

1.1 Guiding Principles

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

No guarantee of interoperability
Although it is impossible to completely guarantee the interoperability of a particular service, the Basic Security Profile 1.1 attempts to increase interoperability by addressing the most common problems that implementation experience has revealed to date.
Focus profiling effort
The focus of the Basic Security Profile 1.1 is the specifications that are explicitly defined as in-scope for the Basic Security Profile 1.1. 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 Basic Security Profile 1.1, assuring the common understanding of those semantics is not addressed by it.
When possible, the Basic Security Profile 1.1 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., MAY, 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 Basic Security Profile 1.1 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 to achieve the same goal, the Basic Security Profile 1.1 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 Basic Security Profile 1.1 aligns its requirements with in-progress revisions to the specifications it references. This aids implementers by enabling a graceful transition, and assures that WS-I does not 'fork' from these efforts. When the Basic Security Profile 1.1 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 Basic Security Profile 1.1, 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 Basic Security Profile 1.1 only addresses those that affect interoperability.
Conformance targets
Where possible, the Basic Security Profile 1.1 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 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.
Best Practices
It is not the intent of the Basic Security Profile 1.1 to define security best practices. However, when multiple options exist, we may use known security weaknesses as a means of reducing choice and thus enhancing interoperability. The Basic Security Profile 1.1 will offer non-normative security considerations where the authors deem appropriate; however, these are by no means exhaustive and should not be perceived as a sanctioning of a security best practice.
Selected Errata Inclusion
The Basic Security Profile 1.1 restates selected requirements from the WS-Security Errata rather than including the entire Errata by reference, preferring interoperability over strict conformance.

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

RnnnnStatement text here.

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

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

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

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

As noted above, some requirements may present compatibility issues (whether forwards or backwards) with previously published versions of the profile. For convenience, such requirements are annotated in the following manner: Compat

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

EnnnnExtensibility Point Name - Description

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

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

1.3 Profile Identification and Versioning

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

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

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

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

2 Profile Conformance

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

2.1 Conformance Requirements

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

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

For example;

R9999 Any WIDGET SHOULD be round in shape.

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

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

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

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

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

The following conformance targets are used in the Basic Security Profile 1.1:

2.3 Conformance Scope

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

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

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

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

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

2.4 Claiming Conformance

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