ࡱ > ` Vx bjbj P |> Y `# `# `# `# `# `# `# t# 8 t# Dn r | ^ ڧ ڧ ڧ j j j j j j j $ q h t d 'j 9 `# W 4 W W 'j `# `# ڧ ڧ Z `j < W % `# ڧ `# ڧ j W j L `# `# P ڧ
< W t iN 4 R < k Dn N u u h P u `# P D l \ b } l l l 'j 'j i X l l l Dn W W W W t# D # ľ | ` $ t# # | ` t# t# t# `# `# `# `# `# `#
Web Services Security:SOAP Message Security 1.1 (WS-Security 2004)
Working Draft - Monday, 13 September 2004
Document identifier:
{WSS: SOAP Message Security }-{1.0} (HYPERLINK "http://www.oasis-open.org/wss/WSS-Username.doc"Word) (HYPERLINK "http://www.oasis-open.org/wss/WSS-Username.pdf"PDF)
Document Location:
HYPERLINK "http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-soap-message-security-1.1" http://docs.oasis-open.org/wss/2004/xx/oasis-2004xx-wss-soap-message-security-1.1
Errata Location:
HYPERLINK "http://www.oasis-open.org/committees/wss" http://www.oasis-open.org/committees/wss
Editors:
Anthony NadalinIBMChris KalerMicrosoft Ronald MonzilloSun Phillip Hallam-BakerVeriSignContributors:
Gene Thurston AmberPoint Frank Siebenlist Argonne National Lab Merlin Hughes Baltimore Technologies Irving Reid Baltimore Technologies Peter Dapkus BEA Hal Lockhart BEA Symon Chang CommerceOne SrinivasDavanumComputer AssociatesThomas DeMartini ContentGuard Guillermo Lao ContentGuard TJ Pannu ContentGuard Shawn Sharp Cyclone Commerce Ganesh Vaideeswaran Documentum Sam Wei Documentum John Hughes Entegrity Tim Moses Entrust Toshihiro Nishimura Fujitsu Tom Rutt Fujitsu Yutaka Kudo Hitachi Jason Rouault HP PaulaAustelIBMBobBlakley IBM Joel Farrell IBM SatoshiHada IBM Maryann Hondo IBM Michael McIntoshIBMHiroshi Maruyama IBM DavidMelgar IBM Anthony Nadalin IBM Nataraj Nagaratnam IBM WayneVicknairIBMKelvin Lawrence IBM (co-Chair) Don Flinn Individual Bob Morgan Individual Bob Atkinson Microsoft KeithBallingerMicrosoftAllen Brown Microsoft Paul Cotton Microsoft Giovanni Della-Libera Microsoft Vijay Gajjala Microsoft Johannes Klein Microsoft ScottKonersmannMicrosoftChris Kurt Microsoft Brian LaMacchia Microsoft Paul Leach Microsoft John Manferdelli Microsoft John Shewchuk Microsoft Dan Simon Microsoft Hervey Wilson MicrosoftChris Kaler Microsoft (co-Chair) Prateek Mishra Netegrity Frederick Hirsch Nokia Senthil Sengodan Nokia Lloyd Burch Novell Ed Reed Novell Charles Knouse Oblix Steve Anderson OpenNetwork (Sec) Vipin Samar Oracle Jerry Schwarz Oracle Eric Gravengaard Reactivity Stuart King Reed Elsevier Andrew Nash RSA Security Rob Philpott RSA Security Peter Rostin RSA Security Martijn de Boer SAP BlakeDournaeeSarvegaPete Wenzel SeeBeyond Jonathan Tourzan Sony Yassir Elley Sun Microsystems Jeff Hodges Sun Microsystems Ronald Monzillo Sun Microsystems Jan Alexander Systinet Michael Nguyen The IDA of Singapore Don Adams TIBCO John Weiland US Navy Phillip Hallam-Baker VeriSign MarkHaysVerisignHemmaPrafullchandra VeriSign
Abstract:
This specification describes enhancements to SOAP messaging to provide message integrity and confidentiality. The specified mechanisms can be used to accommodate a wide variety of security models and encryption technologies.
This specification also provides a general-purpose mechanism for associating security tokens with message content. No specific type of security token is required, the specification is designed to be extensible (i.e.. support multiple security token formats). For example, a client might provide one format for proof of identity and provide another format for proof that they have a particular business certification.
Additionally, this specification describes how to encode binary security tokens, a framework for XML-based tokens, and how to include opaque encrypted keys. It also includes extensibility mechanisms that can be used to further describe the characteristics of the tokens that are included with a message.
Status:
This is a technical committee document submitted for consideration by the OASIS Web Services Security (WSS) technical committee. Please send comments to the editors. If you are on the HYPERLINK "mailto:wss@lists.oasis-open.org" wss@lists.oasis-open.org list for committee members, send comments there. If you are not on that list, subscribe to the HYPERLINK "mailto:wss-comment@lists.oasis-open.org" wss-comment@lists.oasis-open.org list and send comments there. To subscribe, send an email message to HYPERLINK "mailto:wss-comment-request@lists.oasis-open.org" wss-comment-request@lists.oasis-open.org with the word "subscribe" as the body of the message. For patent disclosure information that may be essential to the implementation of this specification, and any offers of licensing terms, refer to the Intellectual Property Rights section of the OASIS Web Services Security Technical Committee (WSS TC) web page at HYPERLINK "http://www.oasis-open.org/committees/wss/ipr.php" http://www.oasis-open.org/committees/wss/ipr.php. General OASIS IPR information can be found at HYPERLINK "http://www.oasis-open.org/who/intellectualproperty.shtml" http://www.oasis-open.org/who/intellectualproperty.shtml.
Table of Contents
TOC \o "1-3" \h \z HYPERLINK \l "_Toc79851747" 1 Introduction PAGEREF _Toc79851747 \h 236
HYPERLINK \l "_Toc79851748" 1.1 Goals and Requirements PAGEREF _Toc79851748 \h 236
HYPERLINK \l "_Toc79851749" 1.1.1 Requirements PAGEREF _Toc79851749 \h 236
HYPERLINK \l "_Toc79851750" 1.1.2 Non-Goals PAGEREF _Toc79851750 \h 236
HYPERLINK \l "_Toc79851751" 2 Notations and Terminology PAGEREF _Toc79851751 \h 238
HYPERLINK \l "_Toc79851752" 2.1 Notational Conventions PAGEREF _Toc79851752 \h 238
HYPERLINK \l "_Toc79851753" 2.2 Namespaces PAGEREF _Toc79851753 \h 238
HYPERLINK \l "_Toc79851754" 2.3 Acronyms and Abbreviations PAGEREF _Toc79851754 \h 239
HYPERLINK \l "_Toc79851755" 2.4 Terminology PAGEREF _Toc79851755 \h 239
HYPERLINK \l "_Toc79851756" 3 Message Protection Mechanisms PAGEREF _Toc79851756 \h 2311
HYPERLINK \l "_Toc79851757" 3.1 Message Security Model PAGEREF _Toc79851757 \h 2311
HYPERLINK \l "_Toc79851758" 3.2 Message Protection PAGEREF _Toc79851758 \h 2311
HYPERLINK \l "_Toc79851759" 3.3 Invalid or Missing Claims PAGEREF _Toc79851759 \h 2311
HYPERLINK \l "_Toc79851760" 3.4 Example PAGEREF _Toc79851760 \h 2312
HYPERLINK \l "_Toc79851761" 4 ID References PAGEREF _Toc79851761 \h 2314
HYPERLINK \l "_Toc79851762" 4.1 Id Attribute PAGEREF _Toc79851762 \h 2314
HYPERLINK \l "_Toc79851763" 4.2 Id Schema PAGEREF _Toc79851763 \h 2314
HYPERLINK \l "_Toc79851764" 5 Security Header PAGEREF _Toc79851764 \h 2316
HYPERLINK \l "_Toc79851765" 6 Security Tokens PAGEREF _Toc79851765 \h 2318
HYPERLINK \l "_Toc79851766" 6.1 Attaching Security Tokens PAGEREF _Toc79851766 \h 2318
HYPERLINK \l "_Toc79851767" 6.1.1 Processing Rules PAGEREF _Toc79851767 \h 2318
HYPERLINK \l "_Toc79851768" 6.1.2 Subject Confirmation PAGEREF _Toc79851768 \h 2318
HYPERLINK \l "_Toc79851769" 6.2 User Name Token PAGEREF _Toc79851769 \h 2318
HYPERLINK \l "_Toc79851770" 6.2.1 Usernames PAGEREF _Toc79851770 \h 2318
HYPERLINK \l "_Toc79851771" 6.3 Binary Security Tokens PAGEREF _Toc79851771 \h 2319
HYPERLINK \l "_Toc79851772" 6.3.1 Attaching Security Tokens PAGEREF _Toc79851772 \h 2319
HYPERLINK \l "_Toc79851773" 6.3.2 Encoding Binary Security Tokens PAGEREF _Toc79851773 \h 2319
HYPERLINK \l "_Toc79851774" 6.4 XML Tokens PAGEREF _Toc79851774 \h 2320
HYPERLINK \l "_Toc79851775" 6.4.1 Identifying and Referencing Security Tokens PAGEREF _Toc79851775 \h 2320
HYPERLINK \l "_Toc79851776" 7 Token References PAGEREF _Toc79851776 \h 2321
HYPERLINK \l "_Toc79851777" 7.1 SecurityTokenReference Element PAGEREF _Toc79851777 \h 2321
HYPERLINK \l "_Toc79851778" 7.2 Direct References PAGEREF _Toc79851778 \h 2322
HYPERLINK \l "_Toc79851779" 7.3 Key Identifiers PAGEREF _Toc79851779 \h 2323
HYPERLINK \l "_Toc79851780" 7.4 Embedded References PAGEREF _Toc79851780 \h 2323
HYPERLINK \l "_Toc79851781" 7.5 ds:KeyInfo PAGEREF _Toc79851781 \h 2324
HYPERLINK \l "_Toc79851782" 7.6 Key Names PAGEREF _Toc79851782 \h 2324
HYPERLINK \l "_Toc79851783" 8 Signatures PAGEREF _Toc79851783 \h 2326
HYPERLINK \l "_Toc79851784" 8.1 Algorithms PAGEREF _Toc79851784 \h 2326
HYPERLINK \l "_Toc79851785" 8.2 Signing Messages PAGEREF _Toc79851785 \h 2328
HYPERLINK \l "_Toc79851786" 8.3 Signing Tokens PAGEREF _Toc79851786 \h 2329
HYPERLINK \l "_Toc79851787" 8.4 Signature Validation PAGEREF _Toc79851787 \h 2331
HYPERLINK \l "_Toc79851788" 8.5 Example PAGEREF _Toc79851788 \h 2331
HYPERLINK \l "_Toc79851789" 9 Encryption PAGEREF _Toc79851789 \h 2333
HYPERLINK \l "_Toc79851790" 9.1 xenc:ReferenceList PAGEREF _Toc79851790 \h 2333
HYPERLINK \l "_Toc79851791" 9.2 xenc:EncryptedKey PAGEREF _Toc79851791 \h 2334
HYPERLINK \l "_Toc79851792" 9.3 Processing Rules PAGEREF _Toc79851792 \h 2334
HYPERLINK \l "_Toc79851793" 9.3.1 Encryption PAGEREF _Toc79851793 \h 2335
HYPERLINK \l "_Toc79851794" 9.3.2 Decryption PAGEREF _Toc79851794 \h 2335
HYPERLINK \l "_Toc79851795" 9.4 Decryption Transformation PAGEREF _Toc79851795 \h 2336
HYPERLINK \l "_Toc79851796" 10 Security Timestamps PAGEREF _Toc79851796 \h 2337
HYPERLINK \l "_Toc79851797" 11 Extended Example PAGEREF _Toc79851797 \h 2339
HYPERLINK \l "_Toc79851798" 12 Error Handling PAGEREF _Toc79851798 \h 2342
HYPERLINK \l "_Toc79851799" 13 Security Considerations PAGEREF _Toc79851799 \h 2343
HYPERLINK \l "_Toc79851800" 13.1 General Considerations PAGEREF _Toc79851800 \h 2343
HYPERLINK \l "_Toc79851801" 13.2 Additional Considerations PAGEREF _Toc79851801 \h 2343
HYPERLINK \l "_Toc79851802" 13.2.1 Replay PAGEREF _Toc79851802 \h 2343
HYPERLINK \l "_Toc79851803" 13.2.2 Combining Security Mechanisms PAGEREF _Toc79851803 \h 2344
HYPERLINK \l "_Toc79851804" 13.2.3 Challenges PAGEREF _Toc79851804 \h 2344
HYPERLINK \l "_Toc79851805" 13.2.4 Protecting Security Tokens and Keys PAGEREF _Toc79851805 \h 2344
HYPERLINK \l "_Toc79851806" 13.2.5 Protecting Timestamps and Ids PAGEREF _Toc79851806 \h 2345
HYPERLINK \l "_Toc79851807" 14 Interoperability Notes PAGEREF _Toc79851807 \h 2346
HYPERLINK \l "_Toc79851808" 15 Privacy Considerations PAGEREF _Toc79851808 \h 2347
HYPERLINK \l "_Toc79851809" 16 References PAGEREF _Toc79851809 \h 2348
HYPERLINK \l "_Toc79851810" Appendix A: Utility Elements and Attributes PAGEREF _Toc79851810 \h 2350
HYPERLINK \l "_Toc79851811" A.1. Identification Attribute PAGEREF _Toc79851811 \h 2350
HYPERLINK \l "_Toc79851812" A.2. Timestamp Elements PAGEREF _Toc79851812 \h 2350
HYPERLINK \l "_Toc79851813" A.3. General Schema Types PAGEREF _Toc79851813 \h 2351
HYPERLINK \l "_Toc79851814" Appendix B: SecurityTokenReference Model PAGEREF _Toc79851814 \h 2352
HYPERLINK \l "_Toc79851815" Appendix C: Revision History PAGEREF _Toc79851815 \h 2356
HYPERLINK \l "_Toc79851816" Appendix D: Notices PAGEREF _Toc79851816 \h 2357
Introduction
This OASIS specification is the result of significant new work by the WSS Technical Committee and supersedes the input submissions, Web Service Security (WS-Security) Version 1.0 April 5, 2002 and Web Services Security Addendum Version 1.0 August 18, 2002.
This specification proposes a standard set of HYPERLINK \l "soap" SOAP [SOAP11, SOAP12] extensions that can be used when building secure Web services to implement message content integrity and confidentiality. This specification refers to this set of extensions and modules as the Web Services Security: SOAP Message Security or WSS: SOAP Message Security.
This specification is flexible and is designed to be used as the basis for securing Web services within a wide variety of security models including PKI, Kerberos, and SSL. Specifically, this specification provides support for multiple security token formats, multiple trust domains, multiple signature formats, and multiple encryption technologies. The token formats and semantics for using these are defined in the associated profile documents.
This specification provides three main mechanisms: ability to send security tokens as part of a message, message integrity, and message confidentiality. These mechanisms by themselves do not provide a complete security solution for Web services. Instead, this specification is a building block that can be used in conjunction with other Web service extensions and higher-level application-specific protocols to accommodate a wide variety of security models and security technologies.
These mechanisms can be used independently (e.g., to pass a security token) or in a tightly coupled manner (e.g., signing and encrypting a message or part of a message and providing a security token or token path associated with the keys used for signing and encryption).
Goals and Requirements
The goal of this specification is to enable applications to conduct secure HYPERLINK \l "soap" SOAP message exchanges.
This specification is intended to provide a flexible set of mechanisms that can be used to construct a range of security protocols; in other words this specification intentionally does not describe explicit fixed security protocols.
As with every security protocol, significant efforts must be applied to ensure that security protocols constructed using this specification are not vulnerable to any one of a wide range of attacks. The examples in this specification are meant to illustrate the syntax of these mechanisms and are not intended as examples of combining these mechanisms in secure ways.
The focus of this specification is to describe a single-message security language that provides for message security that may assume an established session, security context and/or policy agreement.
The requirements to support secure message exchange are listed below.
Requirements
The Web services security language must support a wide variety of security models. The following list identifies the key driving requirements for this specification:
Multiple security token formats
Multiple trust domains
Multiple signature formats
Multiple encryption technologies
End-to-end message content security and not just transport-level security
Non-Goals
The following topics are outside the scope of this document:
Establishing a security context or authentication mechanisms.
Key derivation.
Advertisement and exchange of security policy.
How trust is established or determined.
Non-repudiation.
Notations and Terminology
This section specifies the notations, namespaces, and terminology used in this specification.
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 RFC 2119.
When describing abstract data models, this specification uses the notational convention used by the XML Infoset. Specifically, abstract property names always appear in square brackets (e.g., [some property]).
When describing concrete XML schemas, this specification uses a convention where each member of an elements [children] or [attributes] property is described using an XPath-like notation (e.g., /x:MyHeader/x:SomeProperty/@value1). The use of {any} indicates the presence of an element wildcard (). The use of @{any} indicates the presence of an attribute wildcard ().
Readers are presumed to be familiar with the terms in the HYPERLINK "http://www.ietf.org/rfc/rfc2828.txt"Internet Security Glossary [GLOS].
Namespaces
Namespace URIs (of the general form "some-URI") represents some application-dependent or context-dependent URI as defined in RFC 2396 HYPERLINK \l "ref13" [URI].
This specification is backwardly compatible with version 1.0. This means that URIs and schema elements defined in 1.0 remain unchanged and new schema elements and constants are defined using 1.1 namespaces and URIs.
The HYPERLINK \l "xml-ns" XML namespace URIs that MUST be used by implementations of this specification are as follows (note that elements used in this specification are from various namespaces):
HYPERLINK "http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd" http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd
HYPERLINK "http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd" http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd
HYPERLINK "http://docs.oasis-open.org/wss/2004/01/oasis-2004xx-wss-wssecurity-secext-1.1.xsd" http://docs.oasis-open.org/wss/2004/01/oasis-2004xx-wss-wssecurity-secext-1.1.xsd
This specification is designed to work with the general SOAP [ HYPERLINK \l "soap11" SOAP11, HYPERLINK \l "soap12" SOAP12] message structure and message processing model, and should be applicable to any version of SOAP. The current SOAP 1.1 namespace URI is used herein to provide detailed examples, but there is no intention to limit the applicability of this specification to a single version of SOAP.
The namespaces used in this document are shown in the following table (note that for brevity, the examples use the prefixes listed below but do not include the URIs those listed below are assumed).
PrefixNamespaceds HYPERLINK "http://www.w3.org/2000/09/xmldsig#" http://www.w3.org/2000/09/xmldsig# S11 HYPERLINK "http://schemas.xmlsoap.org/soap/envelope/" http://schemas.xmlsoap.org/soap/envelope/ S12 HYPERLINK "http://www.w3.org/2003/05/soap-envelope" http://www.w3.org/2003/05/soap-envelopewsse HYPERLINK "http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd" http://docs.oasis-open.org/wss/2004/xx/oasis-2004xx-wss-wssecurity-secext-1.0.xsd wsse11 HYPERLINK "http://docs.oasis-open.org/wss/2004/xx/oasis-2004xx-wss-wssecurity-secext-1.1.xsd" http://docs.oasis-open.org/wss/2004/xx/oasis-2004xx-wss-wssecurity-secext-1.1.xsd wsu HYPERLINK "http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd" http://docs.oasis-open.org/wss/2004/xx/oasis-2004xx-wss-wssecurity-utility-1.0.xsd xenc HYPERLINK "http://www.w3.org/2001/04/xmlenc#" http://www.w3.org/2001/04/xmlenc# The URLs provided for the wsse and wsu namespaces can be used to obtain the schema files.
URI fragments defined in WSS: SOAP Message Security 1.0 are relative to a base URI of
HYPERLINK "http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-soap-message-security-1.0" http://docs.oasis-open.org/wss/2004/xx/oasis-2004xx-wss-soap-message-security-1.0
Acronyms and Abbreviations
The following (non-normative) table defines acronyms and abbreviations for this document.
TermDefinitionHMACKeyed-Hashing for Message AuthenticationSHA-1Secure Hash Algorithm 1SOAPSimple Object Access ProtocolURIUniform Resource IdentifierXMLExtensible Markup LanguageTerminology
Defined below are the basic definitions for the security terminology used in this specification.
Claim A claim is a declaration made by an entity (e.g. name, identity, key, group, privilege, capability, etc).
Claim Confirmation A claim confirmation is the process of verifying that a claim applies to an entity
Confidentiality Confidentiality is the property that data is not made available to unauthorized individuals, entities, or processes.
Digest A digest is a cryptographic checksum of an octet stream.
Digital Signature In this document, digital signature and signature are used interchangeably and have the same meaning.
End-To-End Message Level Security - End-to-end message level security is established when a message that traverses multiple applications (one or more SOAP intermediaries) within and between business entities, e.g. companies, divisions and business units, is secure over its full route through and between those business entities. This includes not only messages that are initiated within the entity but also those messages that originate outside the entity, whether they are Web Services or the more traditional messages.
Integrity Integrity is the property that data has not been modified.
Message Confidentiality - Message Confidentiality is a property of the message and encryption is the mechanism by which this property of the message is provided.
Message Integrity - Message Integrity is a property of the message and digital signature is a mechanism by which this property of the message is provided.
Signature - A signature is a value computed with a cryptographic algorithm and bound
to data in such a way that intended recipients of the data can use the signature to verify that the data has not been altered and/or has originated from the signer of the message, providing message integrity and authentication. The signature can be computed and verified with symmetric key algorithms, where the same key is used for signing and verifying, or with asymmetric key algorithms, where different keys are used for signing and verifying (a private and public key pair are used).
Security Token A security token represents a collection (one or more) of claims.
INCLUDEPICTURE "../Local%20Settings/vijayg/Local%20Settings/Temporary%20Internet%20Files/Local%20Settings/Temporary%20Internet%20Files/Local%20Settings/Documents%20and%20Settings/Nadalin/Application%20Data/Microsoft/Local%20Settings/Temporary%20Internet%20Files/Local%20Settings/Temporary%20Internet%20Files/Local%20Settings/Temporary%20Internet%20Files/OLK72/wsse-SecTokens.gif" \* MERGEFORMAT
Signed Security Token A signed security token is a security token that is asserted and cryptographically signed by a specific authority (e.g. an X.509 certificate or a Kerberos ticket).
Trust - Trust is the characteristic that one entity is willing to rely upon a second entity to execute a set of actions and/or to make set of assertions about a set of subjects and/or scopes.
Message Protection Mechanisms
When securing HYPERLINK \l "soap" SOAP messages, various types of threats should be considered. This includes, but is not limited to:
the message could be modified or read by antagonists or
an antagonist could send messages to a service that, while well-formed, lack appropriate security claims to warrant processing.
an antagonist could alter a message to the service which being well formed causes the service to process and respond to the client for an incorrect request.
To understand these threats this specification defines a message security model.
Message Security Model
This document specifies an abstract message security model in terms of HYPERLINK \l "securitytokendef"security tokens combined with digital HYPERLINK \l "signaturedef" signatures to protect and authenticate SOAP messages.
Security tokens assert HYPERLINK \l "claimdef"claims and can be used to assert the binding between authentication secrets or keys and security identities. An authority can vouch for or endorse the claims in a security token by using its key to sign or encrypt (it is recommended to use a keyed encryption) the security token thereby enabling the authentication of the claims in the token. An HYPERLINK \l "x509"X.509 [X509] certificate, claiming the binding between ones identity and public key, is an example of a HYPERLINK \l "signedsecuritytokendef" signed security token endorsed by the certificate authority. In the absence of endorsement by a third party, the recipient of a security token may choose to accept the claims made in the token based on its HYPERLINK \l "trustdef" trust of the producer of the containing message.
Signatures are used to verify message origin and integrity. Signatures are also used by message producers to demonstrate knowledge of the key, typically from a third party, used to confirm the claims in a security token and thus to bind their identity (and any other claims occurring in the security token) to the messages they create.
It should be noted that this security model, by itself, is subject to multiple security attacks. Refer to the HYPERLINK \l "_7._Security_Considerations"Security Considerations section for additional details.
Where the specification requires that an element be "processed" it means that the element type MUST be recognized to the extent that an appropriate error is returned if the element is not supported.
Message Protection
Protecting the message content from being disclosed (confidentiality) or modified without detection (integrity) are primary security concerns. This specification provides a means to protect a message by encrypting and/or digitally signing a body, a header, or any combination of them (or parts of them).
Message HYPERLINK \l "integritydef" integrity is provided by HYPERLINK "http://www.w3.org/TR/2001/PR-xmldsig-core-20010820" XML Signature [XMLSIG] in conjunction with HYPERLINK \l "securitytokendef" security tokens to ensure that modifications to messages are detected. The HYPERLINK \l "integritydef" integrity mechanisms are designed to support multiple HYPERLINK \l "signaturedef" signatures, potentially by multiple HYPERLINK \l "SOAP"SOAP actors/roles, and to be extensible to support additional HYPERLINK \l "signaturedef" signature formats.
Message HYPERLINK \l "confidentialitydef" confidentiality leverages HYPERLINK "http://www.w3.org/TR/2001/WD-xmlenc-core-20010626" XML Encryption [XMLENC] in conjunction with HYPERLINK \l "securitytokendef" security tokens to keep portions of a HYPERLINK \l "soap" SOAP message HYPERLINK \l "confidentialitydef" confidential. The encryption mechanisms are designed to support additional encryption processes and operations by multiple HYPERLINK \l "SOAP" SOAP actors/roles.
This document defines syntax and semantics of signatures within a element. This document does not specify any signature appearing outside of a element.
Invalid or Missing Claims
A message recipient SHOULD reject messages containing invalid signatures, messages missing necessary claims or messages whose claims have unacceptable values. Such messages are unauthorized (or malformed). This specification provides a flexible way for the message producer to make a HYPERLINK \l "claimdef" claim about the security properties by associating zero or more HYPERLINK \l "securitytokendef" security tokens with the message. An example of a security HYPERLINK \l "claimdef" claim is the identity of the producer; the producer can HYPERLINK \l "claimdef" claim that he is Bob, known as an employee of some company, and therefore he has the right to send the message.
Example
The following example illustrates the use of a custom security token and associated signature. The token contains base64 encoded binary data conveying a symmetric key which, we assume, can be properly authenticated by the recipient. The message producer uses the symmetric key with an HMAC signing algorithm to sign the message. The message receiver uses its knowledge of the shared secret to repeat the HMAC key calculation which it uses to validate the signature and in the process confirm that the message was authored by the claimed user identity.
(001)
(002)
(003)
(004)
(005)
(006) FHUIORv...
(007)
(008)
(009)
(010)
(011)
(012)
(013)
(014) LyLsF0Pi4wPU...
(015)
(016)
(017) DJbchm5gK...
(018)
(019)
(020)
(021)
(022)
(023)
(024)
(025)
(026)
(027) QQQ
(028)
(029)
The first two lines start the HYPERLINK \l "soap" SOAP envelope. Line (003) begins the headers that are associated with this HYPERLINK \l "soap" SOAP message.
Line (004) starts the HYPERLINK \l "_4._Security_Element" header defined in this specification. This header contains security information for an intended recipient. This element continues until line (024).
Lines (005) to (007) specify a custom token that is associated with the message. In this case, it uses an externally defined custom token format.
Lines (008) to (023) specify a digital signature. This signature ensures the HYPERLINK \l "_3._Quality_of_Protection" integrity of the signed elements. The signature uses the HYPERLINK \l "xml-signature" XML Signature specification identified by the ds namespace declaration in Line (002).
Lines (009) to (016) describe what is being signed and the type of canonicalization being used. Line (010) specifies how to canonicalize (normalize) the data that is being signed. Lines (012) to (015) select the elements that are signed and how to digest them. Specifically, line (012) indicates that the element is signed. In this example only the message body is signed; typically all critical elements of the message are included in the signature (see the HYPERLINK \l "_5._Extended_Example" Extended Example below).
Line (017) specifies the signature value of the canonicalized form of the data that is being signed as defined in the HYPERLINK \l "xml-signature" XML Signature specification.
Lines (018) to (022) provides information, partial or complete, as to where to find the HYPERLINK \l "securitytokendef" security token associated with this signature. Specifically, lines (019) to (021) indicate that the HYPERLINK \l "securitytokendef" security token can be found at (pulled from) the specified URL.
Lines (026) to (028) contain the body (payload) of the HYPERLINK \l "soap" SOAP message.
ID References
There are many motivations for referencing other message elements such as signature references or correlating signatures to security tokens. For this reason, this specification defines the wsu:Id attribute so that recipients need not understand the full schema of the message for processing of the security elements. That is, they need only "know" that the wsu:Id attribute represents a schema type of ID which is used to reference elements. However, because some key schemas used by this specification don't allow attribute extensibility (namely XML Signature and XML Encryption), this specification also allows use of their local ID attributes in addition to the wsu:Id attribute. As a consequence, when trying to locate an element referenced in a signature, the following attributes are considered:
Local ID attributes on XML Signature elements
Local ID attributes on XML Encryption elements
Global wsu:Id attributes (described below) on elements
In addition, when signing a part of an envelope such as the body, it is RECOMMENDED that an ID reference is used instead of a more general transformation, especially HYPERLINK \l "xpath" XPath [XPATH]. This is to simplify processing.
Id Attribute
There are many situations where elements within HYPERLINK \l "soap" SOAP messages need to be referenced. For example, when signing a SOAP message, selected elements are included in the scope of the signature. HYPERLINK \l "xmlschema2"XML Schema Part 2 [XMLSCHEMA] provides several built-in data types that may be used for identifying and referencing elements, but their use requires that consumers of the SOAP message either have or must be able to obtain the schemas where the identity or reference mechanisms are defined. In some circumstances, for example, intermediaries, this can be problematic and not desirable.
Consequently a mechanism is required for identifying and referencing elements, based on the SOAP foundation, which does not rely upon complete schema knowledge of the context in which an element is used. This functionality can be integrated into SOAP processors so that elements can be identified and referred to without dynamic schema discovery and processing.
This section specifies a namespace-qualified global attribute for identifying an element which can be applied to any element that either allows arbitrary attributes or specifically allows a particular attribute.
Id Schema
To simplify the processing for intermediaries and recipients, a common attribute is defined for identifying an element. This attribute utilizes the XML Schema ID type and specifies a common attribute for indicating this information for elements.
The syntax for this attribute is as follows:
...
The following describes the attribute illustrated above:
.../@wsu:Id
This attribute, defined as type xsd:ID, provides a well-known attribute for specifying the local ID of an element.
Two wsu:Id attributes within an XML document MUST NOT have the same value. Implementations MAY rely on XML Schema validation to provide rudimentary enforcement for intra-document uniqueness. However, applications SHOULD NOT rely on schema validation alone to enforce uniqueness.
This specification does not specify how this attribute will be used and it is expected that other specifications MAY add additional semantics (or restrictions) for their usage of this attribute.
The following example illustrates use of this attribute to identify an element:
Conformant processors that do support XML Schema MUST treat this attribute as if it was defined using a global attribute declaration.
Conformant processors that do not support dynamic XML Schema or DTDs discovery and processing are strongly encouraged to integrate this attribute definition into their parsers. That is, to treat this attribute information item as if its PSVI has a [type definition] which {target namespace} is "http://www.w3.org/2001/XMLSchema" and which {type} is "ID." Doing so allows the processor to inherently know how to process the attribute without having to locate and process the associated schema. Specifically, implementations MAY support the value of the wsu:Id as the valid identifier for use as an HYPERLINK \l "xpointer" XPointer [XPointer] shorthand pointer for interoperability with XML Signature references.
Security Header
The header block provides a mechanism for attaching security-related information targeted at a specific recipient in the form of a HYPERLINK \l "soap" SOAPactor/role. This may be either the ultimate recipient of the message or an intermediary. Consequently, elements of this type may be present multiple times in a HYPERLINK \l "soap" SOAP message. An active intermediary on the message path MAY add one or more new sub-elements to an existing header block if they are targeted for its HYPERLINK \l "soap" SOAP node or it MAY add one or more new headers for additional targets.
As stated, a message MAY have multiple header blocks if they are targeted for separate recipients. However, only one header block MAY omit the S11: actor or S12:role attributes. Two header blocks MUST NOT have the same value for S11:actor or S12:role. Message security information targeted for different recipients MUST appear in different header blocks. This is due to potential processing order issues (e.g. due to possible header re-ordering). The header block without a specified S11:actor or S12:role MAY be processed by anyone, but MUST NOT be removed prior to the final destination or endpoint.
As elements are added to a header block, they SHOULD be prepended to the existing elements. As such, the header block represents the signing and encryption steps the message producer took to create the message. This prepending rule ensures that the receiving application can process sub-elements in the order they appear in the header block, because there will be no forward dependency among the sub-elements. Note that this specification does not impose any specific order of processing the sub-elements. The receiving application can use whatever order is required.
When a sub-element refers to a key carried in another sub-element (for example, a signature sub-element that refers to a binary security token sub-element that contains the HYPERLINK \l "x509" X.509 certificate used for the signature), the key-bearing element SHOULD be ordered to precede the key-using
Element:
...
...
...
...
The following describes the attributes and elements listed in the example above:
/wsse:Security
This is the header block for passing security-related message information to a recipient.
/wsse:Security/@S11:actor
This attribute allows a specific HYPERLINK \l "soap" SOAP 1.1 [SPOAP11] actor to be identified. This attribute is optional; however, no two instances of the header block may omit a actor or specify the same actor.
/wsse:Security/@S12:role
This attribute allows a specific HYPERLINK \l "soap" SOAP 1.2 [SOAP12] role to be identified. This attribute is optional; however, no two instances of the header block may omit a role or specify the same role.
/wsse:Security/{any}
This is an extensibility mechanism to allow different (extensible) types of security information, based on a schema, to be passed. Unrecognized elements SHOULD cause a fault.
/wsse:Security/@{any}
This is an extensibility mechanism to allow additional attributes, based on schemas, to be added to the header. Unrecognized attributes SHOULD cause a fault.
All compliant implementations MUST be able to process a element.
All compliant implementations MUST declare which profiles they support and MUST be able to process a element including any sub-elements which may be defined by that profile. It is RECOMMENDED that undefined elements within the header not be processed.
The next few sections outline elements that are expected to be used within a header.
When a header includes a mustUnderstand="true" attribute:
The receiver MUST generate a SOAP fault if does not implement the WSS: SOAP Message Security specification corresponding to the namespace. Implementation means ability to interpret the schema as well as follow the required processing rules specified in WSS: SOAP Message Security.
The receiver MUST generate a fault if unable to interpret or process security tokens contained in the header block according to the corresponding WSS: SOAP Message Security token profiles.
Receivers MAY ignore elements or extensions within the element, based on local security policy.
Security Tokens
This chapter specifies some different types of security tokens and how they are attached to messages.
Attaching Security Tokens
This specification defines the header as a mechanism for conveying security information with and about a HYPERLINK \l "soap" SOAP message. This header is, by design, extensible to support many types of security information.
For security tokens based on XML, the extensibility of the header allows for these security tokens to be directly inserted into the header.
Processing Rules
This specification describes the processing rules for using and processing HYPERLINK \l "xml-signature" XML Signature and HYPERLINK \l "xmlencrypt" XML Encryption. These rules MUST be followed when using any type of security token. Note that if signature or encryption is used in conjunction with security tokens, they MUST be used in a way that conforms to the processing rules defined by this specification.
Subject Confirmation
This specification does not dictate if and how claim confirmation must be done; however, it does define how signatures may be used and associated with security tokens (by referencing the security tokens from the signature) as a form of claim confirmation.
User Name Token
Usernames
The element is introduced as a way of providing a username. This element is optionally included in the header.
The following illustrates the syntax of this element:
...
The following describes the attributes and elements listed in the example above:
/wsse:UsernameToken
This element is used to represent a claimed identity.
/wsse:UsernameToken/@wsu:Id
A string label for this security token. The wsu:Id allow for an open attribute model.
/wsse:UsernameToken/wsse:Username
This required element specifies the claimed identity.
/wsse:UsernameToken/wsse:Username/@{any}
This is an extensibility mechanism to allow additional attributes, based on schemas, to be added to the element.
/wsse:UsernameToken/{any}
This is an extensibility mechanism to allow different (extensible) types of security information, based on a schema, to be passed. Unrecognized elements SHOULD cause a fault.
/wsse:UsernameToken/@{any}
This is an extensibility mechanism to allow additional attributes, based on schemas, to be added to the element. Unrecognized attributes SHOULD cause a fault.
All compliant implementations MUST be able to process a element.
The following illustrates the use of this:
...
Zoe
...
...
Binary Security Tokens
Attaching Security Tokens
For binary-formatted security tokens, this specification provides a element that can be included in the header block.
Encoding Binary Security Tokens
Binary security tokens (e.g., HYPERLINK \l "x509" X.509 certificates and HYPERLINK \l "kerberos" Kerberos [KERBEROS] tickets) or other non-XML formats require a special encoding format for inclusion. This section describes a basic framework for using binary security tokens. Subsequent specifications MUST describe the rules for creating and processing specific binary security token formats.
The element defines two attributes that are used to interpret it. The ValueType attribute indicates what the security token is, for example, a HYPERLINK \l "kerberos" Kerberos ticket.
The EncodingType tells how the security token is encoded, for example Base64Binary.
The following is an overview of the syntax:
The following describes the attributes and elements listed in the example above:
/wsse:BinarySecurityToken
This element is used to include a binary-encoded security token.
/wsse:BinarySecurityToken/@wsu:Id
An optional string label for this HYPERLINK \l "securitytokendef" security token.
/wsse:BinarySecurityToken/@ValueType
The ValueType attribute is used to indicate the "value space" of the encoded binary data (e.g. an HYPERLINK \l "x509" X.509 certificate). The ValueType attribute allows a URI that defines the value type and space of the encoded binary data. Subsequent specifications MUST define the ValueType value for the tokens that they define. The usage of ValueType is RECOMMENDED.
/wsse:BinarySecurityToken/@EncodingType
The EncodingType attribute is used to indicate, using a URI, the encoding format of the binary data (e.g., base64 encoded). A new attribute is introduced, as there are issues with the current schema validation tools that make derivations of mixed simple and complex types difficult within HYPERLINK \l "xml-schema1" XML Schema. The EncodingType attribute is interpreted to indicate the encoding format of the element. The following encoding formats are pre-defined (note that the URI fragments are relative to the URI for this specification):
URIDescription#Base64Binary (default) HYPERLINK \l "xml-schema1" XML Schema base 64 encoding
/wsse:BinarySecurityToken/@{any}
This is an extensibility mechanism to allow additional attributes, based on schemas, to be added.
All compliant implementations MUST be able to process a element.
XML Tokens
This section presents framework for using XML-based security tokens. Profile specifications describe rules and processes for specific XML-based security token formats.
Identifying and Referencing Security Tokens
This specification also defines multiple mechanisms for identifying and referencing security tokens using the wsu:Id attribute and the element (as well as some additional mechanisms). Please refer to the specific profile documents for the appropriate reference mechanism. However, specific extensions MAY be made to the element.
EncryptedData Token
In certain cases it is desirable that the token included in the header be encrypted for the recipient processing role. In such a case the element MAY be used to contain a security token and included in the header. That is this specification defines the usage of to encrypt security tokens contained in header.
It should be noted that token references are not made to the element, but instead to the token represented by the clear-text, once the element has been processed (decrypted). Such references utilize the token profile for the contained token. i.e., SHOULD NOT include an XML Id for referencing the contained security token.
All tokens SHOULD either have an embedded encryption key or should be referenced by a separate encryption key.
When a token is processed, it is replaced in the message infoset with its decrypted form.
Token References
This chapter discusses and defines mechanisms for referencing security tokens.
SecurityTokenReference Element
A HYPERLINK \l "securitytokendef" security token conveys a set of HYPERLINK \l "claimdef" claims. Sometimes these claims reside somewhere else and need to be "pulled" by the receiving application. The element provides an extensible mechanism for referencing HYPERLINK \l "securitytokendef" security tokens.
The element provides an open content model for referencing security tokens because not all tokens support a common reference pattern. Similarly, some token formats have closed schemas and define their own reference mechanisms. The open content model allows appropriate reference mechanisms to be used when referencing corresponding token types.
If a is used outside of the security header processing block the meaning of the response and/or processing rules of the resulting references MUST be specified by the containing element and are out of scope of this specification.
The following illustrates the syntax of this element:
...
The following describes the elements defined above:
/wsse:SecurityTokenReference
This element provides a reference to a security token.
/wsse:SecurityTokenReference/@wsu:Id
A string label for this HYPERLINK \l "securitytokendef" security token reference which names the reference. This attribute does not indicate the ID of what is being referenced, that SHOULD be done using a fragment URI in a element within the element.
/wsse:SecurityTokenReference/@wsse:Usage
This optional attribute is used to type the usage of the . Usages are specified using URIs and multiple usages MAY be specified using XML list semantics. No usages are defined by this specification.
/wsse:SecurityTokenReference/{any}
This is an extensibility mechanism to allow different (extensible) types of security references, based on a schema, to be passed. Unrecognized elements SHOULD cause a fault.
/wsse:SecurityTokenReference/@{any}
This is an extensibility mechanism to allow additional attributes, based on schemas, to be added to the header. Unrecognized attributes SHOULD cause a fault.
All compliant implementations MUST be able to process a element.
This element can also be used as a direct child element of to indicate a hint to retrieve the key information from a security token placed somewhere else. In particular, it is RECOMMENDED, when using HYPERLINK \l "xml-signature" XML Signature and HYPERLINK \l "xmlencrypt" XML Encryption, that a element be placed inside a to reference the HYPERLINK \l "securitytokendef" security token used for the signature or encryption.
There are several challenges that implementations face when trying to interoperate. Processing the IDs and references requires the recipient to understand the schema. This may be an expensive task and in the general case impossible as there is no way to know the "schema location" for a specific namespace URI. As well, the primary goal of a reference is to uniquely identify the desired token. ID references are, by definition, unique by XML. However, other mechanisms such as "principal name" are not required to be unique and therefore such references may be not unique.
The following list provides a list of the specific reference mechanisms defined in WSS: SOAP Message Security in preferred order (i.e., most specific to least specific):
Direct References This allows references to included tokens using URI fragments and external tokens using full URIs.
Key Identifiers This allows tokens to be referenced using an opaque value that represents the token (defined by token type/profile).
Key Names This allows tokens to be referenced using a string that matches an identity assertion within the security token. This is a subset match and may result in multiple security tokens that match the specified name.
Embedded References - This allows tokens to be embedded (as opposed to a pointer to a token that resides elsewhere).
Direct References
The element provides an extensible mechanism for directly referencing HYPERLINK \l "securitytokendef" security tokens using URIs.
The following illustrates the syntax of this element:
The following describes the elements defined above:
/wsse:SecurityTokenReference/wsse:Reference
This element is used to identify an abstract URI location for locating a security token.
/wsse:SecurityTokenReference/wsse:Reference/@URI
This optional attribute specifies an abstract URI for where to find a security token. If a fragment is specified, then it indicates the local ID of the token being referenced.
/wsse:SecurityTokenReference/wsse:Reference/@ValueType
This optional attribute specifies a URI that is used to identify the type of token being referenced. This specification does not define any processing rules around the usage of this attribute, however, specifications for individual token types MAY define specific processing rules and semantics around the value of the URI and how it SHALL be interpreted. If this attribute is not present, the URI MUST be processed as a normal URI. The usage of ValueType is RECOMMENDED for references with local URIs.
/wsse:SecurityTokenReference/wsse:Reference/{any}
This is an extensibility mechanism to allow different (extensible) types of security references, based on a schema, to be passed. Unrecognized elements SHOULD cause a fault.
/wsse:SecurityTokenReference/wsse:Reference/@{any}
This is an extensibility mechanism to allow additional attributes, based on schemas, to be added to the header. Unrecognized attributes SHOULD cause a fault.
The following illustrates the use of this element:
Key Identifiers
Alternatively, if a direct reference is not used, then it is RECOMMENDED to use a key identifier to specify/reference a security token instead of a . A KeyIdentifier is a value that can be used to uniquely identify a security token (e.g. a hash of the important elements of the security token). The exact value type and generation algorithm varies by security token type (and sometimes by the data within the token), Consequently, the values and algorithms are described in the token-specific profiles rather than this specification.
The element SHALL be placed in the element to reference a token using an identifier. This element SHOULD be used for all key identifiers.
The processing model assumes that the key identifier for a security token is constant. Consequently, processing a key identifier is simply looking for a security token whose key identifier matches a given specified constant. The element is only allowed inside a element
The following is an overview of the syntax:
...
The following describes the attributes and elements listed in the example above:
/wsse:SecurityTokenReference/wsse:KeyIdentifier
This element is used to include a binary-encoded key identifier.
/wsse:SecurityTokenReference/wsse:KeyIdentifier/@wsu:Id
An optional string label for this identifier.
/wsse:SecurityTokenReference/wsse:KeyIdentifier/@ValueType
The optional ValueType attribute is used to indicate the type of KeyIdentifier being used. This specification defines one ValueType that can be applied to all token types. Each specific token profile specifies the KeyIdentifier types that may be used to refer to tokens of that type. It also specifies the critical semantics of the identifier, such as whether the KeyIdentifier is unique to the key or the token. If no value is specified then the key identifier will be interpreted in an application-specific manner.
URIDescription HYPERLINK "http://docs.oasis-open.org/wss/2004/xx/oasis-2004xx-wss-soap-message-security-1.1" \l "ThumbprintSHA1" http://docs.oasis-open.org/wss/2004/xx/oasis-2004xx-wss-soap-message-security-1.1#ThumbprintSHA1 If the security token type that the Security Token Reference refers to already contains a representation for the thumbprint, the value obtained from the token MAY be used. If the token does not contain a representation of a thumbprint, then the value of the KeyIdentifier MUST be the SHA1 of the raw octets which would be encoded within the security token element were it to be included.
/wsse:SecurityTokenReference/wsse:KeyIdentifier/@EncodingType
The optional EncodingType attribute is used to indicate, using a URI, the encoding format of the KeyIdentifier (#Base64Binary). This specification defines the EncodingType URI values appearing in the following table. A token specific profile MAY define additional token specific EncodingType URI values. A KeyIdentifier MUST include an EncodingType attribute when its ValueType is not sufficient to identify its encoding type.The base values defined in this specification are used (Note that URI fragments are relative to this document's URI)::
URIDescription#Base64BinaryHYPERLINK \l "xmlschema1"XML Schema base 64 encoding (default)
/wsse:SecurityTokenReference/wsse:KeyIdentifier/@{any}
This is an extensibility mechanism to allow additional attributes, based on schemas, to be added.
Embedded References
In some cases a reference may be to an embedded token (as opposed to a pointer to a token that resides elsewhere). To do this, the element is specified within a element. The element is only allowed inside a element.
The following is an overview of the syntax:
...
The following describes the attributes and elements listed in the example above:
/wsse:SecurityTokenReference/wsse:Embedded
This element is used to embed a token directly within a reference (that is, to create a local or literal reference).
/wsse:SecurityTokenReference/wsse:Embedded/@wsu:Id
An optional string label for this element. This allows this embedded token to be referenced by a signature or encryption.
/wsse:SecurityTokenReference/wsse:Embedded/{any}
This is an extensibility mechanism to allow any security token, based on schemas, to be embedded. Unrecognized elements SHOULD cause a fault.
/wsse:SecurityTokenReference/wsse:Embedded/@{any}
This is an extensibility mechanism to allow additional attributes, based on schemas, to be added. Unrecognized attributes SHOULD cause a fault.
The following example illustrates embedding a SAML assertion:
...
...
...
...
ds:KeyInfo
The element (from HYPERLINK \l "xml-signature" XML Signature) can be used for carrying the key information and is allowed for different key types and for future extensibility. However, in this specification, the use of is the RECOMMENDED mechanism to carry key material if the key type contains binary data. Please refer to the specific profile documents for the appropriate way to carry key material.
The following example illustrates use of this element to fetch a named key:
CN=Hiroshi Maruyama, C=JP
Key Names
It is strongly RECOMMENDED to use elements. However, if key names are used, then it is strongly RECOMMENDED that elements conform to the attribute names in section 2.3 of RFC 2253 (this is recommended by XML Signature for ) for interoperability.
Additionally, e-mail addresses, SHOULD conform to RFC 822:
EmailAddress=ckaler@microsoft.com
Encrypted Key reference
In certain cases, an element MAY be used to carry key material encrypted for the recipients key. This key material is henceforth referred to as EncryptedKey. The EncyrptedKey MAY be used to perform other cryptographic operations within the same message, such as signatures. The EncryptedKey MAY also be used for performing cryptographic operations in subsequent messages exchanged by the two parties. Two mechanisms are defined for referencing the EncryptedKey.
When referencing the EncryptedKey within the same message that contains the element, the element of the referencing construct MUST contain a . The element MUST contain a element. The URI attribute value of the element MUST be set to the value of the ID attribute of the referenced element that contains the EncryptedKey.
When referencing the EncrypteKey in a message that does not contain the element, the element of the referencing construct MUST contain a . The element MUST contain a element. The EncodingType attribute SHOULD be set to #Base64Binary. Other encoding types MAY be specified if agreed on by all parties. The ValueType attribute MUST be set to
HYPERLINK "http://docs.oasis-open.org/wss/2004/xx/oasis-2004xx-wss-soap-message-security-1.1#EncryptedKey" http://docs.oasis-open.org/wss/2004/xx/oasis-2004xx-wss-soap-message-security-1.1#EncryptedKey.The identifier for a token is defined as the SHA1 of the raw (pre-base64 encoding) octets specified in the element of the referenced token. This value is encoded as indicated in the KeyIdentifier reference.
Signatures
Message producers may want to enable message recipients to determine whether a message was altered in transit and to verify that the claims in a particular HYPERLINK \l "securitytokendef" security token apply to the producer of the message.
Demonstrating knowledge of a confirmation key associated with a token key-claim confirms the accompanying token claims. Knowledge of a confirmation key may be demonstrated using that key to create an XML Signature, for example. The relying party acceptance of the claims may depend on its confidence in the token. Multiple tokens may contain a key-claim for a signature and may be referenced from the signature using a . A key-claim may be an X.509 Certificate token, or a Kerberos service ticket token to give two examples.
Because of the mutability of some HYPERLINK \l "soap" SOAP headers, producers SHOULD NOT use the Enveloped Signature Transform defined in HYPERLINK \l "xml-signature" XML Signature. Instead, messages SHOULD explicitly include the elements to be signed. Similarly, producers SHOULD NOT use the Enveloping Signature defined in HYPERLINK \l "xml-signature" XML Signature [XMLSIG].
This specification allows for multiple signatures and signature formats to be attached to a message, each referencing different, even overlapping, parts of the message. This is important for many distributed applications where messages flow through multiple processing stages. For example, a producer may submit an order that contains an orderID header. The producer signs the orderID header and the body of the request (the contents of the order). When this is received by the order processing sub-system, it may insert a shippingID into the header. The order sub-system would then sign, at a minimum, the orderID and the shippingID, and possibly the body as well. Then when this order is processed and shipped by the shipping department, a shippedInfo header might be appended. The shipping department would sign, at a minimum, the shippedInfo and the shippingID and possibly the body and forward the message to the billing department for processing. The billing department can verify the signatures and determine a valid chain of trust for the order, as well as who authorized each step in the process.
All compliant implementations MUST be able to support the HYPERLINK \l "xml-signature" XML Signature standard.
Algorithms
This specification builds on HYPERLINK \l "xml-signature" XML Signature and therefore has the same algorithm requirements as those specified in the HYPERLINK \l "xml-signature" XML Signature specification.
The following table outlines additional algorithms that are strongly RECOMMENDED by this specification:
Algorithm TypeAlgorithmAlgorithm URICanonicalizationExclusive XML Canonicalization HYPERLINK "http://www.w3.org/2001/10/xml-exc-c14n" http://www.w3.org/2001/10/xml-exc-c14n#
As well, the following table outlines additional algorithms that MAY be used:
Algorithm TypeAlgorithmAlgorithm URITransformSOAP Message Normalizationhttp://www.w3.org/TR/soap12-n11n/
The HYPERLINK "http://www.w3.org/2001/10/xml-exc-c14n" Exclusive XML Canonicalization algorithm addresses the pitfalls of general canonicalization that can occur from leaky namespaces with pre-existing signatures.
Finally, if a producer wishes to sign a message before encryption, then following the ordering rules laid out in section 5, "Security Header", they SHOULD first prepend the signature element to the header, and then prepend the encryption element, resulting in a header that has the encryption element first, followed by the signature element:
header[encryption element]
[signature element]
.
.
Likewise, if a producer wishes to sign a message after encryption, they SHOULD first prepend the encryption element to the header, and then prepend the signature element. This will result in a header that has the signature element first, followed by the encryption element:
header[signature element]
[encryption element]
.
.
The XML Digital Signature WG has defined two canonicalization algorithms: XML Canonicalization and Exclusive XML Canonicalization. To prevent confusion, the first is also called Inclusive Canonicalization. Neither one solves all possible problems that can arise. The following informal discussion is intended to provide guidance on the choice of which one to use
in particular circumstances. For a more detailed and technically precise discussion of these issues see: [XML-C14N] and [EXC-C14N].
There are two problems to be avoided. On the one hand, XML allows documents to be changed in various ways and still be considered equivalent. For example, duplicate namespace declarations can be removed or created. As a result, XML tools make these kinds of changes freely when processing XML. Therefore, it is vital that these equivalent forms match the same signature.
On the other hand, if the signature simply covers something like xx:foo, its meaning may change if xx is redefined. In this case the signature does not prevent tampering. It might be thought that the problem could be solved by expanding all the values in line. Unfortunately, there are mechanisms like XPATH which consider xx=" HYPERLINK "http://example.com/%22" http://example.com/"; to be different from yy=" HYPERLINK "http://example.com/%22" http://example.com/"; even though both xx and yy are bound to the same namespace.
The fundamental difference between the Inclusive and Exclusive Canonicalization is the namespace declarations which are placed in the output. Inclusive Canonicalization copies all the declarations that are currently in force, even if they are defined outside of the scope of the
signature. It also copies any xml: attributes that are in force, such as xml:lang or xml:base. This guarantees that all the declarations you might make use of will be unambiguously specified. The problem with this is that if the signed XML is moved into another XML document which has other declarations, the Inclusive Canonicalization will copy then and the signature will be invalid. This can even happen if you simply add an attribute in a different namespace to the surrounding context.
Exclusive Canonicalization tries to figure out what namespaces you are actually using and just copies those. Specifically, it copies the ones that are "visibly used", which means the ones that are a part of the XML syntax. However, it does not look into attribute values or element content, so the namespace declarations required to process these are not copied. For example
if you had an attribute like xx:foo="yy:bar" it would copy the declaration for xx, but not yy. (This can even happen without your knowledge because XML processing tools will add xsi:type if you use a schema subtype.) It also does not copy the xml: attributes that are declared outside the scope of the signature.
Exclusive Canonicalization allows you to create a list of the namespaces that must be declared, so that it will pick up the declarations for the ones that are not visibly used. The only problem is that the software doing the signing must know what they are. In a typical SOAP software environment, the security code will typically be unaware of all the namespaces being used by
the application in the message body that it is signing.
Exclusive Canonicalization is useful when you have a signed XML document that you wish to insert into other XML documents. A good example is a signed SAML assertion which might be inserted as a XML Token in the security header of various SOAP messages. The Issuer who signs the assertion will be aware of the namespaces being used and able to construct the list. The use of Exclusive Canonicalization will insure the signature verifies correctly every time.
Inclusive Canonicalization is useful in the typical case of signing part or all of the SOAP body in accordance with this specification. This will insure all the declarations fall under the signature, even though the code is unaware of what namespaces are being used. At the same time, it is less likely that the signed data (and signature element) will be inserted in some other XML document. Even if this is desired, it still may not be feasible for other reasons, for example there may be Id's with the same value defined in both XML documents.
In other situations it will be necessary to study the requirements of the application and the detailed operation of the canonicalization methods to determine which is appropriate.
This section is non-normative.
Signing Messages
The header block MAY be used to carry a signature compliant with the HYPERLINK \l "xml-signature" XML Signature specification within a HYPERLINK \l "soap" SOAP Envelope for the purpose of signing one or more elements in the HYPERLINK \l "soap" SOAP Envelope. Multiple signature entries MAY be added into a single HYPERLINK \l "soap" SOAP Envelope within one header block. Producers SHOULD sign all important elements of the message, and careful thought must be given to creating a signing policy that requires signing of parts of the message that might legitimately be altered in transit.
HYPERLINK \l "soap" SOAP applications MUST satisfy the following conditions:
A compliant implementation MUST be capable of processing the required elements defined in the HYPERLINK \l "xml-signature" XML Signature specification.
To add a signature to a header block, a element conforming to the XML Signature specification MUST be prepended to the existing content of the header block, in order to indicate to the receiver the correct order of operations. All the elements contained in the signature SHOULD refer to a resource within the enclosing HYPERLINK \l "soap" SOAP envelope as described in the HYPERLINK \l "xml-signature" XML Signature specification. However, since the HYPERLINK \l "soap" SOAP message exchange model allows intermediate applications to modify the Envelope (add or delete a header block; for example), HYPERLINK \l "xpath" XPath filtering does not always result in the same objects after message delivery. Care should be taken in using HYPERLINK \l "xpath" XPath filtering so that there is no subsequent validation failure due to such modifications.
The problem of modification by intermediaries (especially active ones) is applicable to more than just HYPERLINK \l "xpath" XPath processing. Digital signatures, because of canonicalization and HYPERLINK \l "digestdef" digests, present particularly fragile examples of such relationships. If overall message processing is to remain robust, intermediaries must exercise care that the transformation algorithms used do not affect the validity of a digitally signed component.
Due to security concerns with namespaces, this specification strongly RECOMMENDS the use of the " HYPERLINK \l "xml-signature" Exclusive XML Canonicalization" algorithm or another canonicalization algorithm that provides equivalent or greater protection.
For processing efficiency it is RECOMMENDED to have the signature added and then the security token pre-pended so that a processor can read and cache the token before it is used.
Signing Tokens
It is often desirable to sign security tokens that are included in a message or even external to the message. The XML Signature specification provides several common ways for referencing information to be signed such as URIs, IDs, and XPath, but some token formats may not allow tokens to be referenced using URIs or IDs and XPaths may be undesirable in some situations.
This specification allows different tokens to have their own unique reference mechanisms which are specified in their profile as extensions to the element. This element provides a uniform referencing mechanism that is guaranteed to work with all token formats. Consequently, this specification defines a new reference option for XML Signature: the STR Dereference Transform.
This transform is specified by the URI #STR-Transform (Note that URI fragments are relative to this document's URI) and when applied to a element it means that the output is the token referenced by the element not the element itself.
As an overview the processing model is to echo the input to the transform except when a element is encountered. When one is found, the element is not echoed, but instead, it is used to locate the token(s) matching the criteria and rules defined by the element and echo it (them) to the output. Consequently, the output of the transformation is the resultant sequence representing the input with any elements replaced by the referenced security token(s) matched.
The following illustrates an example of this transformation which references a token contained within the message envelope:
...
...
...
...
...
...
The following describes the attributes and elements listed in the example above:
/wsse:TransformationParameters
This element is used to wrap parameters for a transformation allows elements even from the XML Signature namespace.
/wsse:TransformationParameters/ds:Canonicalization
This specifies the canolicalization algorithm to apply to the selected data.
/wsse:TransformationParameters/{any}
This is an extensibility mechanism to allow different (extensible) parameters to be specified in the future. Unrecognized parameters SHOULD cause a fault.
/wsse:TransformationParameters/@{any}
This is an extensibility mechanism to allow additional attributes, based on schemas, to be added to the element in the future. Unrecognized attributes SHOULD cause a fault.
The following is a detailed specification of the transformation.
The algorithm is identified by the URI: #STR-Transform
Transform Input:
The input is a node set. If the input is an octet stream, then it is automatically parsed; cf. XML Digital Signature [XMLSIG].
Transform Output:
The output is an octet steam.
Syntax:
The transform takes a single mandatory parameter, a element, which is used to serialize the input node set. Note, however, that the output may not be strictly in canonical form, per the canonicalization algorithm; however, the output is canonical, in the sense that it is unambiguous. However, because of syntax requirements in the XML Signature definition, this parameter MUST be wrapped in a element.
Processing Rules:
Let N be the input node set.
Let R be the set of all elements in N.
For each Ri in R, let Di be the result of dereferencing Ri.
If Di cannot be determined, then the transform MUST signal a failure.
If Di is an XML security token (e.g., a SAML assertion or a element), then let Ri' be Di.Otherwise, Di is a raw binary security token; i.e., an octet stream. In this case, let Ri' be a node set consisting of a element, utilizing the same namespace prefix as the element Ri, with no EncodingType attribute, a ValueType attribute identifying the content of the security token, and text content consisting of the binary-encoded security token, with no white space.
Finally, employ the canonicalization method specified as a parameter to the transform to serialize N to produce the octet stream output of this transform; but, in place of any dereferenced element Ri and its descendants, process the dereferenced node set Ri' instead. During this step, canonicalization of the replacement node set MUST be augmented as follows:
Note: A namespace declaration xmlns="" MUST be emitted with every apex element that has no namespace node declaring a value for the default namespace; cf. XML Decryption Transform.
Signing a SecurityTokenReference (STR) provides authentication and integrity protection of only the STR and not the referenced security token (ST). If signing the ST is the intended behavior, the STR Dereference Transform (STRDT) may be used which replaces the STR with the ST for digest computation, effectively protecting the ST and not the STR. If protecting both the ST and the STR is desired, you may sign the STR twice, once using the STRDT and once not using the STRDT.
The following table lists the full URI for each URI fragment referred to in the specification.
URI FragmentFull URI#Base64Binaryhttp://docs.oasis-open.org/wss/2004/xx/oasis-2004xx-wss-soap-message-security-1.0#Base64Binary#STR-Transformhttp://docs.oasis-open.org/wss/2004/xx/oasis-2004xx-wss-soap-message-security-1.0#STR-Transform#X509v3http://docs.oasis-open.org/wss/2004/xx/oasis-2004xx-wss-x509-token-profile-1.0#X509v3Signature Validation
The validation of a element inside an header block SHALL fail if:
the syntax of the content of the element does not conform to this specification, or
the validation of the HYPERLINK \l "signaturedef" signature contained in the element fails according to the core validation of the HYPERLINK \l "xml-signature" XML Signature specification [XMLSIG], or
the application applying its own validation policy rejects the message for some reason (e.g., the HYPERLINK \l "signaturedef" signature is created by an untrusted key verifying the previous two steps only performs cryptographic validation of the HYPERLINK \l "signaturedef" signature).
If the validation of the signature element fails, applications MAY report the failure to the producer using the fault codes defined in HYPERLINK \l "_6._Error_Handling" Section 12 Error Handling.
The signature validation shall additionally adhere to the rules defines in signature confirmation section below, if the initiator desires signature confirmation:
Signature Confirmation
In the general model, the initiator uses XML Signature constructs to represent message parts of the request that were signed. The manifest of signed SOAP elements is contained in the element which in turn is placed inside the header. The element of the request contains a . This element contains a base64 encoded value representing the actual digital signature. In certain situations it is desirable that initiator confirms that the message received was generated in response to a message it initiated in its unaltered form. This helps prevent certain forms of attack. This specification introduces a element to address this necessity.
Compliant responder implementations that support signature confirmation, MUST include a element inside the header of the associated response message for every element that is a direct child of the header block in the originating message. The responder MUST include the contents of the element of the request signature as the value of the @Value attribute of the element. The element MUST be included in the message signature of the associated response message.
If the associated originating signature is received in encrypted form then the corresponding element SHOULD be encrypted to protect the original signature and keys.
The schema outline for this element is as follows:
/SignatureConfirmation
This element indicates that the responder has processed the signature in the request. When this element is not present in a response the initiator SHOULD interpret that the responder is not compliant with this functionality.
/SignatureConfirmation/@wsu:Id
Identifier to be used when referencing this element in the SignedInfo reference list of the signature of the associated response message. This attribute MUST be present so that un-ambiguous references can be made to this element..
/SignatureConfirmation/@Value
This optional attribute contains the contents of a copied from the associated request. If the request was not signed, then this attribute MUST NOT be present. If this attribute is specified with an empty value, the initiator SHOULD interpret this as incorrect behavior and process accordingly. When this attribute is not present, the initiator SHOULD interpret this to mean that the response is based on a request that was not signed.
Response Generation Rules
If the responder does not comply with this specification, it MUST NOT include any elements in response messages it generates. If the responder complies with this specification, it MUST include at least one element in the header in any response(s) associated with requests. That is, the normal messaging patterns are not altered.
For every response message generated, the responder MUST include a element for every element it processed from the original request message. The Value attribute MUST be set to the exact value of the element of the corresponding element. If no elements are present in the original request message, the responder MUST include exactly one element. The Value attribute of the element MUST NOT be present. The responder MUST include all elements in the message signature of the response message(s). If the element corresponding to a element was encrypted in the original request message, the element SHOULD be encrypted for the recipient of the response message(s).
Response Processing Rules
The signature validation shall additionally adhere to the following processing guidelines, if the initiator desires signature confirmation:
If a response message does not contain a element inside the header, the initiator SHOULD reject the response message.
If a response message does contain a element inside the header but @Value attribute is not present on element, and the associated request message did include a element, the initiator SHOULD reject the response message.
If a response message does contain a element inside the header and the @Value attribute is present on the element, but the associated request did not include a element, the initiator SHOULD reject the response message.
If a response message does contain a element inside the header, and the associated request message did include a element and the @Value attribute is present but does not match the stored signature value of the associated request message, the initiator SHOULD reject the response message.
If a response message does not contain a element inside the header corresponding to each element or if the @Value attribute present does not match the stored signature values of the associated request message, the initiator SHOULD reject the response message.
Example
The following sample message illustrates the use of integrity and security tokens. For this example, only the message body is signed.
MIIEZzCCA9CgAwIBAgIQEmtJZc0rqrKh5i...
EULddytSo1...
BL8jdfToEb1l/vXcMZNNjPOV...
QQQ
Encryption
This specification allows encryption of any combination of body blocks, header blocks, and any of these sub-structures by either a common symmetric key shared by the producer and the recipient or a symmetric key carried in the message in an encrypted form.
In order to allow this flexibility, this specification leverages the HYPERLINK \l "xmlencrypt" XML Encryption standard. This specification Specifically what this specification describes is how the three two elements and elements (listed below and defined in HYPERLINK \l "xmlencrypt" XML Encryption) can be used within the header block. . When a producer or an active intermediary encrypts portion(s) of a HYPERLINK \l "soap" SOAP message using HYPERLINK \l "xmlencrypt" XML Encryption they it MUST prepend a sub-element to the header block. Furthermore, the encrypting party MUST either prepend the sub-element to an existing header block for the intended recipients or create a new header block and insert the sub-element. The combined process of encrypting portion(s) of a message and adding one of these sub-elements is called an encryption step hereafter. The sub-element MUST contain the information necessary for the recipient to identify the portions of the message that it is able to decrypt.
This specification additionally defines an element for containing encrypted SOAP header blocks. This specification RECOMMENDS an additional mechanism that uses this element for encrypting SOAP header blocks that complies with SOAP processing guidelines while preserving the confidentiality of attributes on the SOAP header blocks.
All compliant implementations MUST be able to support the HYPERLINK \l "xmlencrypt" XML Encryption standard [XMLENC].
xenc:ReferenceList
The element from HYPERLINK \l "xmlencrypt" XML Encryption [XMLENC] MAY be used to create a manifest of encrypted portion(s), which are expressed as elements within the envelope. An element or element content to be encrypted by this encryption step MUST be replaced by a corresponding according to HYPERLINK \l "xmlencrypt" XML Encryption. All the elements created by this encryption step SHOULD be listed in elements inside one or more element.
Although in HYPERLINK \l "xmlencrypt" XML Encryption [XMLENC], was originally designed to be used within an element (which implies that all the referenced elements are encrypted by the same key), this specification allows that elements referenced by the same MAY be encrypted by different keys. Each encryption key can be specified in within individual .
A typical situation where the sub-element is useful is that the producer and the recipient use a shared secret key. The following illustrates the use of this sub-element:
CN=Hiroshi Maruyama, C=JP
...
xenc:EncryptedKey
When the encryption step involves encrypting elements or element contents within a HYPERLINK \l "soap" SOAP envelope with a symmetric key, which is in turn to be encrypted by the recipients key and embedded in the message, MAY be used for carrying such an encrypted key. This sub-element SHOULD have a manifest, that is, an element, in order for the recipient to know the portions to be decrypted with this key. An element or element content to be encrypted by this encryption step MUST be replaced by a corresponding according to HYPERLINK \l "xmlencrypt" XML Encryption. All the elements created by this encryption step SHOULD be listed in the element inside this sub-element.
This construct is useful when encryption is done by a randomly generated symmetric key that is in turn encrypted by the recipients public key. The following illustrates the use of this element:
...
DC=ACMECorp, DC=com
12345678
...
...
...
While XML Encryption specifies that elements MAY be specified in elements, this specification strongly RECOMMENDS that elements be placed in the header.
Encrypted Header
In order to be compliant with SOAP mustUnderstand processing guidelines and to prevent disclosure of information contained in attributes on a SOAP header block, this specification introduces an element. This element contains exactly one element. This specification RECOMMENDS the use of element for encrypting SOAP header blocks.
Processing Rules
Encrypted parts or using one of the sub-elements defined above MUST be in compliance with the HYPERLINK \l "xmlencrypt" XML Encryption specification. An encrypted HYPERLINK \l "soap" SOAP envelope MUST still be a valid HYPERLINK \l "soap" SOAP envelope. The message creator MUST NOT encrypt the , ,or , elements but MAY encrypt child elements of either the , and or elements. Multiple steps of encryption MAY be added into a single header block if they are targeted for the same recipient.
When an element or element content inside a HYPERLINK \l "soap" SOAP envelope (e.g. the contents of the or elements) are to be encrypted, it MUST be replaced by an , according to HYPERLINK \l "xmlencrypt" XML Encryption and it SHOULD be referenced from the element created by this encryption step. If the target of reference is an EncryptedHeader as defined in section 9.3 above, see processing rules defined in section 9.5.3 Encryption using EncryptedHeader and section 9.5.4 Decryption of EncryptedHeader below.
Encryption
The general steps (non-normative) for creating an encrypted HYPERLINK \l "soap" SOAP message in compliance with this specification are listed below (note that use of is RECOMMENDED).. Additionally, if target of encryption is a SOAP header, processing rules defined in section 9.5.3 SHOUD be used).
Create a new HYPERLINK \l "soap" SOAP envelope.
Create a header
When an is used, create a sub-element of the element. This sub-element SHOULD contain an sub-element, containing a to each element that was encrypted using that key.
Locate data items to be encrypted, i.e., XML elements, element contents within the target HYPERLINK \l "soap" SOAP envelope.
Encrypt the data items as follows: For each XML element or element content within the target HYPERLINK \l "soap" SOAP envelope, encrypt it according to the processing rules of the HYPERLINK \l "xmlencrypt" XML Encryption specification [XMLENC]. Each selected original element or element content MUST be removed and replaced by the resulting element.
The optional element in the element MAY reference another element. Note that if the encryption is based on an attached security token, then a element SHOULD be added to the element to facilitate locating it.
Create an element referencing the generated elements. Add the created element to the .
Copy all non-encrypted data.
Decryption
On receiving a HYPERLINK \l "soap" SOAP envelope containing encryption header elements, for each encryption header element the following general steps should be processed (this section is non-normative. Additionally, if the target of reference is an EncryptedHeader, processing rules as defined in section 9.5.4 below SHOULD be used):
Identify any decryption keys that are in the recipients possession, then identifying any message elements that it is able to decrypt.
Locate the items to be decrypted (possibly using the ).
Decrypt them as follows:
For each element in the target HYPERLINK \l "soap" SOAP envelope, decrypt it according to the processing rules of the HYPERLINK \l "xmlencrypt" XML Encryption specification and the processing rules listed above.
If the decryption fails for some reason, applications MAY report the failure to the producer using the fault code defined in HYPERLINK \l "_6._Error_Handling" Section 12 Error Handling of this specification.
It is possible for overlapping portions of the SOAP message to be encrypted in such a way that they are intended to be decrypted by SOAP nodes acting in different Roles. In this case, the or elements identifying these encryption operations will necessarily appear in different headers. Since SOAP does not provide any means of specifying the order in which different Roles will process their respective headers, this order is not specified by this specification and can only be determined by a prior agreement.
Encryption with EncryptedHeader
In certain cases, it is desirable that an entire SOAP header block including the top-level element, descendants and all attributes need to be encrypted. In such a case, the original header block is replaced with a element. The element contains the produced from encrypting the header block. A wsu:Id attribute MAY be added to the element for referencing. If the referencing header block defines a value for the or attribute, that attribute and associated value SHOULD be copied to the element. If the referencing header block defines a value for the S12:Role or S11:Actor attribute, that attribute and associated value SHOULD be copied to the element.
Any header block can be replaced with a corresponding header block. This includes header blocks. In addition, header blocks can be super-encrypted and replaced by other header blocks (for wrapping/tunneling scenarios).
Any header that encrypts a header block targeted to a particular actor SHOULD be targeted to that same actor.
Processing an EncryptedHeader
The processing model for header blocks is as follows:
Resolve references to encrypted data specified in the header block targeted at this node. For each reference, perform the following steps.
If the referenced element does not have a qualified name of then process as per section 9.5.2 Decryption and stop the processing steps here.
Otherwise, extract the element from the element.
Decrypt the contents of the element as per section 9.5.2 Decryption and replace the element with the decrypted contents.
Process the decrypted header block as per SOAP processing guidelines.
Alternatively, a processor may perform a pre-pass over the encryption references in the header:
Resolve references to encrypted data specified in the header block targeted at this node. For each reference, perform the following steps.
If a referenced element has a qualified name of then replace the