Ws Securitypolicy 1.2 Spec Os

1
2WS-SecurityPolicy 1.2
3OASIS Standard
41 July 2007
5Specification URIs:
6This Version:
7 http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702/ws-securitypolicy-1.2-spec-os.doc
8 http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702/ws-securitypolicy-1.2-spec-os.pdf
9 http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702/ws-securitypolicy-1.2-spec-os.html
10Previous Version:
11 http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702/ws-securitypolicy-1.2-spec-cs.doc
12 http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702/ws-securitypolicy-1.2-spec-cs.pdf
13 http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702/ws-securitypolicy-1.2-spec-cs.html
14Latest Version:
15 http://docs.oasis-open.org/ws-sx/ws-securitypolicy/v1.2/ws-securitypolicy.doc
16 http://docs.oasis-open.org/ws-sx/ws-securitypolicy/v1.2/ws-securitypolicy.pdf
17 http://docs.oasis-open.org/ws-sx/ws-securitypolicy/v1.2/ws-securitypolicy.html
18Artifact Type:
19 specification
20Technical Committee:
21 OASIS Web Services Secure Exchange TC
22Chair(s):
23 Kelvin Lawrence, IBM
24 Chris Kaler, Microsoft
25Editor(s):
26 Anthony Nadalin, IBM
27 Marc Goodner, Microsoft
28 Martin Gudgin, Microsoft
29 Abbie Barbir, Nortel
30 Hans Granqvist, VeriSign
31Related work:
32 N/A
33Declared XML Namespace(s):
34 http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702
35Abstract:
36 This document indicates the policy assertions for use with [WS-Policy] which apply to WSS:
37 SOAP Message Security [WSS10, WSS11], [WS-Trust] and [WS-SecureConversation]
38Status:
39 This document was last revised or approved by the WS-SX TC on the above date. The level of
40 approval is also listed above. Check the current location noted above for possible later revisions
41 of this document. This document is updated periodically on no particular schedule.
42 Technical Committee members should send comments on this specification to the Technical
43 Committee’s email list. Others should send comments to the Technical Committee by using the
1ws-securitypolicy-1.2-spec-os 1 July 2007
2Copyright © OASIS® 1993–2007. All Rights Reserved. OASIS trademark, IPR and other policies apply. Page 1 of 113
44 “Send A Comment” button on the Technical Committee’s web page at http://www.oasis-
45 open.org/committees/ws-sx.
46 For information on whether any patents have been disclosed that may be essential to
47 implementing this specification, and any offers of patent licensing terms, please refer to the
48 Intellectual Property Rights section of the Technical Committee web page (http://www.oasis-
49 open.org/committees/ws-sx/ipr.php).
50 The non-normative errata page for this specification is located at http://www.oasis-
51 open.org/committees/ws-sx.

52Notices
53Copyright © OASIS® 1993–2007. All Rights Reserved. OASIS trademark, IPR and other policies apply.
54All capitalized terms in the following text have the meanings assigned to them in the OASIS Intellectual
55Property Rights Policy (the "OASIS IPR Policy"). The full Policy may be found at the OASIS website.
56This document and translations of it may be copied and furnished to others, and derivative works that
57comment on or otherwise explain it or assist in its implementation may be prepared, copied, published,
58and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice
59and this section are included on all such copies and derivative works. However, this document itself may
60not be modified in any way, including by removing the copyright notice or references to OASIS, except as
61needed for the purpose of developing any document or deliverable produced by an OASIS Technical
62Committee (in which case the rules applicable to copyrights, as set forth in the OASIS IPR Policy, must
63be followed) or as required to translate it into languages other than English.
64The limited permissions granted above are perpetual and will not be revoked by OASIS or its successors
65or assigns.
66This document and the information contained herein is provided on an "AS IS" basis and OASIS
67DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY
68WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY
69OWNERSHIP RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A
70PARTICULAR PURPOSE.
71OASIS requests that any OASIS Party or any other party that believes it has patent claims that would
72necessarily be infringed by implementations of this OASIS Committee Specification or OASIS Standard,
73to notify OASIS TC Administrator and provide an indication of its willingness to grant patent licenses to
74such patent claims in a manner consistent with the IPR Mode of the OASIS Technical Committee that
75produced this specification.
76OASIS invites any party to contact the OASIS TC Administrator if it is aware of a claim of ownership of
77any patent claims that would necessarily be infringed by implementations of this specification by a patent
78holder that is not willing to provide a license to such patent claims in a manner consistent with the IPR
79Mode of the OASIS Technical Committee that produced this specification. OASIS may include such
80claims on its website, but disclaims any obligation to do so.
81OASIS takes no position regarding the validity or scope of any intellectual property or other rights that
82might be claimed to pertain to the implementation or use of the technology described in this document or
83the extent to which any license under such rights might or might not be available; neither does it represent
84that it has made any effort to identify any such rights. Information on OASIS' procedures with respect to
85rights in any document or deliverable produced by an OASIS Technical Committee can be found on the
86OASIS website. Copies of claims of rights made available for publication and any assurances of licenses
87to be made available, or the result of an attempt made to obtain a general license or permission for the
88use of such proprietary rights by implementers or users of this OASIS Committee Specification or OASIS
89Standard, can be obtained from the OASIS TC Administrator. OASIS makes no representation that any
90information or list of intellectual property rights will at any time be complete, or that any claims in such list
91are, in fact, Essential Claims.
92The name "OASIS" is a trademark of OASIS, the owner and developer of this specification, and should be
93used only to refer to the organization and its official outputs. OASIS welcomes reference to, and
94implementation and use of, specifications, while reserving the right to enforce its marks against
95misleading uses. Please see http://www.oasis-open.org/who/trademark.php for above guidance.
96

97Table of Contents
981 Introduction..........................................................................................................7
99 1.1 Example.............................................................................................................7
100 1.2 Namespaces.......................................................................................................8
101 1.3 Schema Files.......................................................................................................9
102 1.4 Terminology........................................................................................................9
103 1.4.1 Notational Conventions.....................................................................................9
104 1.5 Normative References..........................................................................................10
105 1.6 Non-Normative References....................................................................................13
1062 Security Policy Model.............................................................................................14
107 2.1 Security Assertion Model.......................................................................................14
108 2.2 Nested Policy Assertions.......................................................................................15
109 2.3 Security Binding Abstraction...................................................................................15
1103 Policy Considerations............................................................................................17
111 3.1 Nested Policy.....................................................................................................17
112 3.2 Policy Subjects...................................................................................................17
1134 Protection Assertions.............................................................................................19
114 4.1 Integrity Assertions..............................................................................................19
115 4.1.1 SignedParts Assertion.....................................................................................19
116 4.1.2 SignedElements Assertion................................................................................20
117 4.2 Confidentiality Assertions.......................................................................................21
118 4.2.1 EncryptedParts Assertion.................................................................................21
119 4.2.2 EncryptedElements Assertion............................................................................22
120 4.2.3 ContentEncryptedElements Assertion..................................................................22
121 4.3 Required Elements Assertion..................................................................................23
122 4.3.1 RequiredElements Assertion.............................................................................23
123 4.3.2 RequiredParts Assertion..................................................................................24
1245 Token Assertions..................................................................................................25
125 5.1 Token Inclusion..................................................................................................25
126 5.1.1 Token Inclusion Values....................................................................................25
127 5.1.2 Token Inclusion and Token References................................................................26
128 5.2 Token Issuer and Required Claims.....................................................................26
129 5.2.1 Token Issuer.............................................................................................26
130 5.2.2 Token Issuer Name....................................................................................26
131 5.2.3 Required Claims........................................................................................26
132 5.2.4 Processing Rules and Token Matching..........................................................27
133 5.3 Token Properties.................................................................................................27
134 5.3.1 [Derived Keys] Property...................................................................................27
135 5.3.2 [Explicit Derived Keys] Property.........................................................................27
136 5.3.3 [Implied Derived Keys] Property.........................................................................27
137 5.4 Token Assertion Types.........................................................................................27

138 5.4.1 UsernameToken Assertion...............................................................................27
139 5.4.2 IssuedToken Assertion....................................................................................29
140 5.4.3 X509Token Assertion......................................................................................31
141 5.4.4 KerberosToken Assertion.................................................................................33
142 5.4.5 SpnegoContextToken Assertion.........................................................................34
143 5.4.6 SecurityContextToken Assertion.........................................................................36
144 5.4.7 SecureConversationToken Assertion...................................................................37
145 5.4.8 SamlToken Assertion......................................................................................40
146 5.4.9 RelToken Assertion........................................................................................42
147 5.4.10 HttpsToken Assertion....................................................................................43
148 5.4.11 KeyValueToken Assertion..........................................................................44
1496 Security Binding Properties......................................................................................47
150 6.1 [Algorithm Suite] Property......................................................................................47
151 6.2 [Timestamp] Property...........................................................................................49
152 6.3 [Protection Order] Property.....................................................................................49
153 6.4 [Signature Protection] Property................................................................................49
154 6.5 [Token Protection] Property....................................................................................49
155 6.6 [Entire Header and Body Signatures] Property.............................................................50
156 6.7 [Security Header Layout] Property............................................................................50
157 6.7.1 Strict Layout Rules for WSS 1.0.........................................................................50
1587 Security Binding Assertions.....................................................................................52
159 7.1 AlgorithmSuite Assertion.......................................................................................52
160 7.2 Layout Assertion.................................................................................................54
161 7.3 TransportBinding Assertion....................................................................................55
162 7.4 SymmetricBinding Assertion...................................................................................56
163 7.5 AsymmetricBinding Assertion..................................................................................58
1648 Supporting Tokens................................................................................................61
165 8.1 SupportingTokens Assertion...................................................................................62
166 8.2 SignedSupportingTokens Assertion..........................................................................63
167 8.3 EndorsingSupportingTokens Assertion......................................................................65
168 8.4 SignedEndorsingSupportingTokens Assertion..............................................................67
169 8.5 SignedEncryptedSupportingTokens Assertion..............................................................69
170 8.6 EncryptedSupportingTokens Assertion......................................................................69
171 8.7 EndorsingEncryptedSupportingTokens Assertion..........................................................69
172 8.8 SignedEndorsingEncryptedSupportingTokens Assertion.................................................69
173 8.9 Interaction between [Token Protection] property and supporting token assertions...................69
174 8.10 Example..........................................................................................................70
1759 WSS: SOAP Message Security Options......................................................................71
176 9.1 Wss10 Assertion.................................................................................................72
177 9.2 Wss11 Assertion.................................................................................................73
17810 WS-Trust Options.................................................................................................75
179 10.1 Trust13 Assertion...............................................................................................76
18011 Guidance on creating new assertions and assertion extensibility.........................................78
181 11.1 General Design Points.........................................................................................78
182 11.2 Detailed Design Guidance....................................................................................78
18312 Security Considerations..........................................................................................80
184A. Assertions and WS-PolicyAttachment.........................................................................81
185 A.1 Endpoint Policy Subject Assertions...........................................................................81
186 A.1.1 Security Binding Assertions..............................................................................81
187 A.1.2 Token Assertions..........................................................................................81
188 A.1.3 WSS: SOAP Message Security 1.0 Assertions.......................................................81
189 A.1.4 WSS: SOAP Message Security 1.1 Assertions.......................................................81
190 A.1.5 Trust 1.0 Assertions.......................................................................................81
191 A.2 Operation Policy Subject Assertions.........................................................................81
192 A.2.1 Security Binding Assertions..............................................................................81
193 A.2.2 Supporting Token Assertions............................................................................81
194 A.3 Message Policy Subject Assertions..........................................................................82
195 A.3.1 Supporting Token Assertions............................................................................82
196 A.3.2 Protection Assertions......................................................................................82
197 A.4 Assertions With Undefined Policy Subject...................................................................82
198 A.4.1 General Assertions........................................................................................82
199 A.4.2 Token Usage Assertions..................................................................................82
200 A.4.3 Token Assertions..........................................................................................82
201B. Issued Token Policy..............................................................................................84
202C. Strict Security Header Layout Examples......................................................................86
203 C.1 Transport Binding...............................................................................................86
204 C.1.1 Policy........................................................................................................86
205 C.1.2 Initiator to Recipient Messages..........................................................................87
206 C.1.3 Recipient to Initiator Messages..........................................................................88
207 C.2 Symmetric Binding..............................................................................................89
208 C.2.1 Policy........................................................................................................90
209 C.2.2 Initiator to Recipient Messages..........................................................................91
210 C.2.3 Recipient to Initiator Messages..........................................................................95
211 C.3 Asymmetric Binding.............................................................................................98
212 C.3.1 Policy........................................................................................................98
213 C.3.2 Initiator to Recipient Messages........................................................................100
214 C.3.3 Recipient to Initiator Messages........................................................................104
215D. Signed and Encrypted Elements in the Security Header.................................................108
216 D.1 Elements signed by the message signature...............................................................108
217 D.2 Elements signed by all endorsing signatures.............................................................108
218 D.3 Elements signed by a specific endorsing signature......................................................108
219 D.4 Elements that are encrypted.................................................................................108
220E. Acknowledgements.............................................................................................109
221
222

2231 Introduction
224WS-Policy defines a framework for allowing web services to express their constraints and requirements.
225Such constraints and requirements are expressed as policy assertions. This document defines a set of
226security policy assertions for use with the [WS-Policy] framework with respect to security features
227provided in WSS: SOAP Message Security [WSS10, WSS11], [WS-Trust] and [WS-SecureConversation].
228The assertions defined within this specification have been designed to work independently of a specific
229version of WS-Policy. At the time of the publication of this specification the versions of WS-Policy known
230to correctly compose with this specification are WS-Policy 1.2 and 1.5. Within this specification the use of
231the namespace prefix wsp refers generically to the WS-Policy namespace, not a specific version. This
232document takes the approach of defining a base set of assertions that describe how messages are to be
233secured. Flexibility with respect to token types, cryptographic algorithms and mechanisms used, including
234using transport level security is part of the design and allows for evolution over time. The intent is to
235provide enough information for compatibility and interoperability to be determined by web service
236participants along with all information necessary to actually enable a participant to engage in a secure
237exchange of messages.
238
239Sections 11, 12 and all examples and all Appendices are non-normative.
2401.1 Example
241Table 1 shows an "Effective Policy" example, including binding assertions and associated property
242assertions, token assertions and integrity and confidentiality assertions. This example has a scope of
243[Endpoint Policy Subject], but for brevity the attachment mechanism is not shown.
244Table 1: Example security policy.
245(1) <wsp:Policy xmlns:wsp="..." xmlns:sp="...">
246(2) <sp:SymmetricBinding>
247(3) <wsp:Policy>
248(4) <sp:ProtectionToken>
249(5) <wsp:Policy>
250(6) <sp:Kerberos sp:IncludeToken=".../IncludeToken/Once" />
251(7) <wsp:Policy>
252(8) <sp:WSSKerberosV5ApReqToken11/>
253(9) <wsp:Policy>
254(10) </sp:Kerberos>
255(11) </wsp:Policy>
256(12) </sp:ProtectionToken>
257(13) <sp:SignBeforeEncrypting />
258(14) <sp:EncryptSignature />
260(16) </sp:SymmetricBinding>
261(17) <sp:SignedParts>
262(18) <sp:Body/>

263(19) <sp:Header
264 Namespace="http://schemas.xmlsoap.org/ws/2004/08/addressing"
265 />
266(20) </sp:SignedParts>
267(21) <sp:EncryptedParts>
268(22) <sp:Body/>
269(23) </sp:EncryptedParts>
271
272Line 1 in Table 1 indicates that this is a policy statement and that all assertions contained by the
273wsp:Policy element are required to be satisfied. Line 2 indicates the kind of security binding in force. Line
2743 indicates a nested wsp:Policy element which contains assertions that qualify the behavior of the
275SymmetricBinding assertion. Line 4 indicates a ProtectionToken assertion. Line 5 indicates a nested
276wsp:Policy element which contains assertions indicating the type of token to be used for the
277ProtectionToken. Lines 6 to 10 indicate that a Kerberos V5 APREQ token is to be used by both parties in
278a message exchange for protection. Line 13 indicates that signatures are generated over plaintext rather
279than ciphertext. Line 14 indicates that the signature over the signed messages parts is required to be
280encrypted. Lines 17-20 indicate which message parts are to be covered by the primary signature; in this
281case the soap:Body element, indicated by Line 18 and any SOAP headers in the WS-Addressing
282namespace, indicated by line 19. Lines 21-23 indicate which message parts are to be encrypted; in this
283case just the soap:Body element, indicated by Line 22.
2841.2 Namespaces
285The XML namespace URI that MUST be used by implementations of this specification is:
286 http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702
287
288Table 2 lists XML namespaces that are used in this specification. The choice of any namespace prefix is
289arbitrary and not semantically significant.
290Table 2: Prefixes and XML Namespaces used in this specification.
Prefix Namespace Specification(s)

S http://schemas.xmlsoap.org/soap/envelope/ [SOAP]
S12 http://www.w3.org/2003/05/soap-envelope [SOAP12]
ds http://www.w3.org/2000/09/xmldsig# [XML-Signature]
enc http://www.w3.org/2001/04/xmlenc# [XML-Encrypt]
wsu http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss- [WSS10]
wssecurity-utility-1.0.xsd
wsse http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss- [WSS10]
wssecurity-secext-1.0.xsd
wsse11 http://docs.oasis-open.org/wss/oasis-wss-wsecurity-secext- [WSS11]
1.1.xsd
xsd http://www.w3.org/2001/XMLSchema [XML-Schema1], [XML-
Schema2]

wst http://docs.oasis-open.org/ws-sx/ws-trust/200512 [WS-Trust]
wsc http://docs.oasis-open.org/ws-sx/ws- [WS-SecureConversation]
secureconversation/200512
wsa http://www.w3.org/2005/08/addressing [WS-Addressing]
sp http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702 This specification
2911.3 Schema Files

292A normative copy of the XML Schema [XML-Schema1, XML-Schema2] description for this specification
293can be retrieved from the following address:
294http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702/ws-securitypolicy-1.2.xsd
2951.4 Terminology
296Policy - A collection of policy alternatives.
297Policy Alternative - A collection of policy assertions.
298Policy Assertion - An individual requirement, capability, other property, or a behavior.
299Initiator - The role sending the initial message in a message exchange.
300Recipient - The targeted role to process the initial message in a message exchange.
301Security Binding - A set of properties that together provide enough information to secure a given
302message exchange.
303Security Binding Property - A particular aspect of securing an exchange of messages.
304Security Binding Assertion - A policy assertion that identifies the type of security binding being used to
305secure an exchange of messages.
306Security Binding Property Assertion - A policy assertion that specifies a particular value for a particular
307aspect of securing an exchange of message.
308Assertion Parameter - An element of variability within a policy assertion.
309Token Assertion -Describes a token requirement. Token assertions defined within a security binding are
310used to satisfy protection requirements.
311Supporting Token - A token used to provide additional claims.
3121.4.1 Notational Conventions

313The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD
314NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” in this document are to be interpreted as described
315in [RFC2119].
316This specification uses the following syntax to define outlines for assertions:
317  The syntax appears as an XML instance, but values in italics indicate data types instead of literal
318 values.
319  Characters are appended to elements and attributes to indicate cardinality:
320 o "?" (0 or 1)
321 o "*" (0 or more)
322 o "+" (1 or more)
323  The character "|" is used to indicate a choice between alternatives.

324  The characters "(" and ")" are used to indicate that contained items are to be treated as a group
325 with respect to cardinality or choice.
326  The characters "[" and "]" are used to call out references and property names.
327  Ellipses (i.e., "...") indicate points of extensibility. Additional children and/or attributes MAY be
328 added at the indicated extension points but MUST NOT contradict the semantics of the parent
329 and/or owner, respectively. By default, if a receiver does not recognize an extension, the receiver
330 SHOULD ignore the extension; exceptions to this processing rule, if any, are clearly indicated
331 below.
332  XML namespace prefixes (see Table 2) are used to indicate the namespace of the element being
333 defined.
334
335Elements and Attributes defined by this specification are referred to in the text of this document using
336XPath 1.0 expressions. Extensibility points are referred to using an extended version of this syntax:
337  An element extensibility point is referred to using {any} in place of the element name. This
338 indicates that any element name can be used, from any namespace other than the namespace of
339 this specification.
340  An attribute extensibility point is referred to using @{any} in place of the attribute name. This
341 indicates that any attribute name can be used, from any namespace other than the namespace of
342 this specification.
343Extensibility points in the exemplar may not be described in the corresponding text.
344In this document reference is made to the wsu:Id attribute and the wsu:Created and wsu:Expires
345elements in a utility schema (http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-
3461.0.xsd). The wsu:Id attribute and the wsu:Created and wsu:Expires elements were added to the
347utility schema with the intent that other specifications requiring such an ID type attribute or timestamp
348element could reference it (as is done here).
349
350WS-SecurityPolicy is designed to work with the general Web Services framework including WSDL service
351descriptions, UDDI businessServices and bindingTemplates and SOAP message structure and message
352processing model, and WS-SecurityPolicy should be applicable to any version of SOAP. The current
353SOAP 1.2 namespace URI is used herein to provide detailed examples, but there is no intention to limit
354the applicability of this specification to a single version of SOAP.
3551.5 Normative References

356[RFC2119] S. Bradner, "Key words for use in RFCs to Indicate Requirement
357 Levels", RFC 2119, Harvard University, March 1997.
358 http://www.ietf.org/rfc/rfc2119.txt
359
360[SOAP] W3C Note, "SOAP: Simple Object Access Protocol 1.1", 08 May 2000.
361 http://www.w3.org/TR/2000/NOTE-SOAP-20000508/
362
363[SOAP12] W3C Recommendation, "SOAP 1.2 Part 1: Messaging Framework", 24
364 June 2003.
365 http://www.w3.org/TR/2003/REC-soap12-part1-20030624/
366
367[SOAPNorm] W3C Working Group Note, "SOAP Version 1.2 Message
368 Normalization”, 8 October 2003.

369 http://www.w3.org/TR/2003/NOTE-soap12-n11n-20031008/
370
371[URI] T. Berners-Lee, R. Fielding, L. Masinter, "Uniform Resource Identifiers
372 (URI): Generic Syntax", RFC 3986, MIT/LCS, Day Software, Adobe
373 Systems, January 2005.
375
376[RFC2068] IETF Standard, "Hypertext Transfer Protocol -- HTTP/1.1" January
377 1997
379
380[RFC2246] IETF Standard, "The TLS Protocol", January 1999.
382
383[SwA] W3C Note, “SOAP Messages with Attachments”, 11 December 2000
384 http://www.w3.org/TR/2000/NOTE-SOAP-attachments-20001211
385
386[WS-Addressing] W3C Recommendation, "Web Services Addressing (WS-Addressing)",
387 9 May 2006.
388 http://www.w3.org/TR/2006/REC-ws-addr-core-20060509
389
390[WS-Policy] W3C Member Submission "Web Services Policy 1.2 - Framework", 25
391 April 2006.
392 http://www.w3.org/Submission/2006/SUBM-WS-Policy-20060425/
393 W3C Candidate Recommendation “Web Services Policy 1.5 –
394 Framework”, 28 February 2007
395 http://www.w3.org/TR/2007/CR-ws-policy-framework-20070228/
396
397[WS-PolicyAttachment] W3C Member Submission "Web Services Policy 1.2 - Attachment", 25
398 April 2006.
399 http://www.w3.org/Submission/2006/SUBM-WS-PolicyAttachment-
400 20060425/
401 W3C Candidate Recommendation “Web Services Policy 1.5 –
402 Attachment”, 28 February 2007
403 http://www.w3.org/TR/2007/CR-ws-policy-attach-20070228/
404
405[WS-Trust] OASIS Committee Draft, "WS-Trust 1.3", September 2006
406 http://docs.oasis-open.org/ws-sx/ws-trust/200512
407
408[WS-SecureConversation] OASIS Committee Draft, “WS-SecureConversation 1.3", September
409 2006
410 http://docs.oasis-open.org/ws-sx/ws-secureconversation/200512
411

412[WSS10] OASIS Standard, "OASIS Web Services Security: SOAP Message
413 Security 1.0 (WS-Security 2004)", March 2004.
414 http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-soap-
415 message-security-1.0.pdf
416
417[WSS11] OASIS Standard, "OASIS Web Services Security: SOAP Message
418 Security 1.1 (WS-Security 2004)", February 2006.
419 http://www.oasis-open.org/committees/download.php/16790/wss-v1.1-
420 spec-os-SOAPMessageSecurity.pdf
421
422[WSS:UsernameToken1.0] OASIS Standard, "Web Services Security: UsernameToken Profile",
423 March 2004
424 http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-username-
425 token-profile-1.0.pdf
426
427[WSS:UsernameToken1.1] OASIS Standard, "Web Services Security: UsernameToken Profile
428 1.1", February 2006
430 spec-os-UsernameTokenProfile.pdf
431
432[WSS:X509Token1.0] OASIS Standard, "Web Services Security X.509 Certificate Token
433 Profile", March 2004
434 http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-x509-token-
435 profile-1.0.pdf
436
437[WSS:X509Token1.1] OASIS Standard, "Web Services Security X.509 Certificate Token
438 Profile", February 2006
440 spec-os-x509TokenProfile.pdf
441
442[WSS:KerberosToken1.1] OASIS Standard, “Web Services Security Kerberos Token Profile 1.1”,
443 February 2006
445 spec-os-KerberosTokenProfile.pdf
446
447[WSS:SAMLTokenProfile1.0] OASIS Standard, “Web Services Security: SAML Token Profile”,
448 December 2004
449 http://docs.oasis-open.org/wss/oasis-wss-saml-token-profile-1.0.pdf
450
451[WSS:SAMLTokenProfile1.1] OASIS Standard, “Web Services Security: SAML Token Profile 1.1”,
452 February 2006
454 spec-os-SAMLTokenProfile.pdf
455
456[WSS:RELTokenProfile1.0] OASIS Standard, “Web Services Security Rights Expression Language
457 (REL) Token Profile”, December 2004

458 http://docs.oasis-open.org/wss/oasis-wss-rel-token-profile-1.0.pdf
459
460[WSS:RELTokenProfile1.1] OASIS Standard, “Web Services Security Rights Expression Language
461 (REL) Token Profile 1.1”, February 2006
462 http://www.oasis-open.org/committees/download.php/16687/oasis-
463 wss-rel-token-profile-1.1.pdf
464
465[WSS:SwAProfile1.1] OASIS Standard, “Web Services Security SOAP Messages with
466 Attachments (SwA) Profile 1.1”, February 2006
468 spec-os-SwAProfile.pdf
469
470[XML-Encrypt] W3C Recommendation, "XML Encryption Syntax and Processing", 10
471 December 2002.
472 http://www.w3.org/TR/2002/REC-xmlenc-core-20021210/
473
474[XML-Signature] W3C Recommendation, "XML-Signature Syntax and Processing", 12
475 February 2002.
476 http://www.w3.org/TR/2002/REC-xmlenc-core-20021210/
477
478[XPATH] W3C Recommendation "XML Path Language (XPath) Version 1.0", 16
479 November 1999.
480 http://www.w3.org/TR/1999/REC-xpath-19991116
481
482[XML-Schema1] W3C Recommendation, "XML Schema Part 1: Structures Second
483 Edition", 28 October 2004.
484 http://www.w3.org/TR/2004/REC-xmlschema-1-20041028/
485
486[XML-Schema2] W3C Recommendation, "XML Schema Part 2: Datatypes Second
487 Edition", 28 October 2004.
488 http://www.w3.org/TR/2004/REC-xmlschema-2-20041028/
489
4901.6 Non-Normative References

491None.
492

4932 Security Policy Model
494This specification defines policy assertions for the security properties for Web services. These assertions
495are primarily designed to represent the security characteristics defined in the WSS: SOAP Message
496Security [WSS10] [WSS11], [WS-Trust] and [WS-SecureConversation] specifications, but they can also
497be used for describing security requirements at a more general or transport-independent level.
498
499The primary goal of this specification is to define an initial set of patterns or sets of assertions that
500represent common ways to describe how messages are secured on a communication path. The intent is
501to allow flexibility in terms of the tokens, cryptography, and mechanisms used, including leveraging
502transport security, but to be specific enough to ensure interoperability based on assertion matching.
503
504It is a goal of the security policy model to leverage the WS-Policy framework’s intersection algorithm for
505selecting policy alternatives and the attachment mechanism for associating policy assertions with web
506service artifacts. Consequently, wherever possible, the security policy assertions do not use parameters
507or attributes. This enables first-level, QName based assertion matching without security domain-specific
508knowledge to be done at the framework level. The first level matching is intended to provide a narrowed
509set of policy alternatives that are shared by the two parties attempting to establish a secure
510communication path.
511
512In general, assertions defined in this specification allow additional attributes, based on schemas, to be
513added on to the assertion element as an extensibility mechanism but the WS-Policy framework will not
514match based on these attributes. Attributes specified on the assertion element that are not defined in this
515specification or in WS-Policy are to be treated as informational properties.
5162.1 Security Assertion Model

517The goal to provide richer semantics for combinations of security constraints and requirements and
518enable first-level QName matching, is enabled by the assertions defined in this specification being
519separated into simple patterns: what parts of a message are being secured (Protection Assertions),
520general aspects or pre-conditions of the security (Conditional Assertions), the security mechanism
521(Security Binding Assertions) that is used to provide the security, the token types and usage patterns
522(Supporting Token Assertions) used to provide additional claims, and token referencing and trust options
523(WSS and Trust Assertions).
524
525To indicate the scope of protection, assertions identify message parts that are to be protected in a specific
526way, such as integrity or confidentiality protection, and are referred to as protection assertions.
527
528The general aspects of security includes the relationships between or characteristics of the environment
529in which security is being applied, such as the tokens being used, which are for integrity or confidentiality
530protection and which are supporting, the applicable algorithms to use, etc.
531
532The security binding assertion is a logical grouping which defines how the general aspects are used to
533protect the indicated parts. For example, that an asymmetric token is used with a digital signature to
534provide integrity protection, and that parts are encrypted with a symmetric key which is then encrypted
535using the public key of the recipient. At its simplest form, the security binding restricts what can be placed
536in the wsse:Security header and the associated processing rules.
537
538The intent of representing characteristics as assertions is so that QName matching will be sufficient to
539find common alternatives and so that many aspects of security can be factored out and re-used. For
540example, it may be common that the mechanism is constant for an endpoint, but that the parts protected
541vary by message action.
5422.2 Nested Policy Assertions

543Assertions may be used to further qualify a specific aspect of another assertion. For example, an
544assertion describing the set of algorithms to use may qualify the specific behavior of a security binding. If
545the schema outline below for an assertion type requires a nested policy expression but the assertion does
546not further qualify one or more aspects of the behavior indicated by the assertion type (i.e., no assertions
547are needed in the nested policy expression), the assertion MUST include an empty <wsp:Policy/>
548element. For further information consult the section Policy Assertion Nesting of [WS-Policy].
5492.3 Security Binding Abstraction

550As previously indicated, individual assertions are designed to be used in multiple combinations. The
551binding represents common usage patterns for security mechanisms. These Security Binding assertions
552are used to determine how the security is performed and what to expect in the wsse:Security header.
553Bindings are described textually and enforced programmatically. This specification defines several
554bindings but others can be defined and agreed to for interoperability if participating parties support it.
555
556A binding defines the following security characteristics:
557  The minimum set of tokens that will be used and how they are bound to messages. Note that
558 services might accept messages containing more tokens than those specified in policy.
559  Any necessary key transport mechanisms
560  Any required message elements (e.g. timestamps) in the wsse:Security header.
561  The content and ordering of elements in the wsse:Security header. Elements not specified in
562 the binding are not allowed.
563  Various parameters, including those describing the algorithms to be used for canonicalization,
564 signing and encryption.
565
566Together the above pieces of information, along with the assertions describing conditions and scope,
567provide enough information to secure messages between an initiator and a recipient. A policy consumer
568has enough information to construct messages that conform to the service's policy and to process
569messages returned by the service. Note that a service may choose to reject messages despite them
570conforming to its policy, for example because a client certificate has been revoked. Note also that a
571service may choose to accept messages that do not conform to its policy.
572
573The following list identifies the bindings defined in this specification. The bindings are identified primarily
574by the style of encryption used to protect the message exchange. A later section of this document
575provides details on the assertions for these bindings.
576  TransportBinding (Section 7.3)
577  SymmetricBinding (Section 7.4)
578  AsymmetricBinding (Section 7.5)

5793 Policy Considerations
580The following sections discuss details of WS-Policy and WS-PolicyAttachment relevant to this
581specification.
5823.1 Nested Policy

583This specification makes extensive use of nested policy assertions as described in the Policy Assertion
584Nesting section of WS-Policy.
585
5863.2 Policy Subjects

587WS-PolicyAttachment defines various attachment points for policy. This section defines properties that
588are referenced later in this document describing the recommended or required attachment points for
589various assertions. In addition, Appendix A groups the various assertions according to policy subject.
590Note: This specification does not define any assertions that have a scope of [Service Policy Subject].
591[Message Policy Subject]
592This property identifies a Message Policy Subject [WS-PolicyAttachment]. WS-PolicyAttachment defines
593seven WSDL [WSDL 1.1] policy attachment points with Message Policy Subject:
594
595wsdl:message
596 A policy expression containing one or more assertions with Message Policy Subject MUST NOT
597 be attached to a wsdl:message.
598wsdl:portType/wsdl:operation/wsdl:input, ./wsdl:output, or ./wsdl:fault
599 A policy expression containing one or more assertions with Message Policy Subject MUST NOT
600 be attached to a descendant of wsdl:portType.
601wsdl:binding/wsdl:operation/wsdl:input, ./wsdl:output, or ./wsdl:fault
602 A policy expression containing one or more of the assertions with Message Policy Subject MUST
603 be attached to a descendant of wsdl:binding.
604[Operation Policy Subject]
605A token assertion with Operation Policy Subject indicates usage of the token on a per-operation basis:
606wsdl:portType/wsdl:operation
607 A policy expression containing one or more token assertions MUST NOT be attached to a
608 wsdl:portType/wsdl:operation.
609wsdl:binding/wsdl:operation
610 A policy expression containing one or more token assertions MUST be attached to a
611 wsdl:binding/wsdl:operation.
612
613
614[Endpoint Policy Subject]
615A token assertion instance with Endpoint Policy Subject indicates usage of the token for the entire set of
616messages described for the endpoint:
617wsdl:portType
618 A policy expression containing one or more assertions with Endpoint Policy Subject MUST NOT
619 be attached to a wsdl:portType.
620wsdl:binding
621 A policy expression containing one or more of the assertions with Endpoint Policy Subject
622 SHOULD be attached to a wsdl:binding.
623wsdl:port
624 A policy expression containing one or more of the assertions with Endpoint Policy Subject MAY
625 be attached to a wsdl:port

6264 Protection Assertions
627The following assertions are used to identify what is being protected and the level of protection provided.
628These assertions SHOULD apply to [Message Policy Subject]. These assertions MAY apply to [Endpoint
629Policy Subject] or [Operation Policy Subject]. Where they apply to [Operation Policy Subject] they apply to
630all messages of that operation. Where they apply to [Endpoint Policy Subject] they apply to all operations
631of that endpoint.
632Note that when assertions defined in this section are present in a policy, the order of those assertions in
633that policy has no effect on the order of signature and encryption operations (see Section 6.3).
6344.1 Integrity Assertions

635Two mechanisms are defined for specifying the set of message parts to integrity protect. One uses
636QNames to specify either message headers or the message body while the other uses XPath
637expressions to identify any part of the message.
6384.1.1 SignedParts Assertion

639The SignedParts assertion is used to specify the parts of the message outside of security headers that
640require integrity protection. This assertion can be satisfied using WSS: SOAP Message Security
641mechanisms or by mechanisms out of scope of SOAP message security, for example by sending the
642message over a secure transport protocol like HTTPS. The binding specific token properties detail the
643exact mechanism by which the protection is provided.
644
645There MAY be multiple SignedParts assertions present. Multiple SignedParts assertions present within a
646policy alternative are equivalent to a single SignedParts assertion containing the union of all specified
647message parts. Note that this assertion does not require that a given part appear in a message, just that if
648such a part appears, it requires integrity protection.
649Syntax
650 <sp:SignedParts xmlns:sp="..." ... >
651 <sp:Body />?
652 <sp:Header Name="xs:NCName"? Namespace="xs:anyURI" ... />*
653 <sp:Attachments />?
654 ...
655 </sp:SignedParts>
656
657The following describes the attributes and elements listed in the schema outlined above:
658/sp:SignedParts
659 This assertion specifies the parts of the message that need integrity protection. If no child
660 elements are specified, all message headers targeted at the UltimateReceiver role [SOAP12] or
661 actor [SOAP11] and the body of the message MUST be integrity protected.
662/sp:SignedParts/sp:Body
663 Presence of this optional empty element indicates that the entire body, that is the soap:Body
664 element, it's attributes and content, of the message needs to be integrity protected.
665/sp:SignedParts/sp:Header

666 Presence of this optional element indicates a specific SOAP header, its attributes and content (or
667 set of such headers) needs to be protected. There may be multiple sp:Header elements within a
668 single sp:SignedParts element. If multiple SOAP headers with the same local name but different
669 namespace names are to be integrity protected multiple sp:Header elements are needed, either
670 as part of a single sp:SignedParts assertion or as part of separate sp:SignedParts assertions.
671 This element only applies to SOAP header elements targeted to the same actor/role as the
672 Security header impacted by the policy. If it is necessary to specify a requirement to sign specific
673 SOAP Header elements targeted to a different actor/role, that may be accomplished using the
674 sp:SignedElements assertion.
675/sp:SignedParts/sp:Header/@Name
676 This optional attribute indicates the local name of the SOAP header to be integrity protected. If
677 this attribute is not specified, all SOAP headers whose namespace matches the Namespace
678 attribute are to be protected.
679/sp:SignedParts/sp:Header/@Namespace
680 This required attribute indicates the namespace of the SOAP header(s) to be integrity protected.
681/sp:SignedParts/sp:Attachments
682 Presence of this optional empty element indicates that all SwA (SOAP Messages with
683 Attachments) attachments [SwA] are to be integrity protected. When SOAP Message Security is
684 used to accomplish this, all message parts other than the part containing the primary SOAP
685 envelope are to be integrity protected as outlined in WSS: SOAP Message Security
686 [WSS:SwAProfile1.1].
6874.1.2 SignedElements Assertion

688The SignedElements assertion is used to specify arbitrary elements in the message that require integrity
689protection. This assertion can be satisfied using WSS: SOAP Message Security mechanisms or by
690mechanisms out of scope of SOAP message security, for example by sending the message over a secure
691transport protocol like HTTPS. The binding specific token properties detail the exact mechanism by which
692the protection is provided.
693
694There MAY be multiple SignedElements assertions present. Multiple SignedElements assertions present
695within a policy alternative are equivalent to a single SignedElements assertion containing the union of all
696specified XPath expressions.
697Syntax
698 <sp:SignedElements XPathVersion="xs:anyURI"? xmlns:sp="..." ... >
699 <sp:XPath>xs:string</sp:XPath>+
700 ...
701 </sp:SignedElements>
703/sp:SignedElements
704 This assertion specifies the parts of the message that need integrity protection.
705/sp:SignedElements/@XPathVersion
706 This optional attribute contains a URI which indicates the version of XPath to use. If no attribute is
707 provided, then XPath 1.0 is assumed.
708/sp:SignedElements/sp:XPath

709 This element contains a string specifying an XPath expression that identifies the nodes to be
710 integrity protected. The XPath expression is evaluated against the S:Envelope element node of
711 the message. Multiple instances of this element may appear within this assertion and should be
712 treated as separate references in a signature when message security is used.
7134.2 Confidentiality Assertions

714Two mechanisms are defined for specifying the set of message parts to confidentiality protect. One uses
715QNames to specify either message headers or the message body while the other uses XPath
716expressions to identify any part of the message.
7174.2.1 EncryptedParts Assertion

718The EncryptedParts assertion is used to specify the parts of the message that require confidentiality. This
719assertion can be satisfied with WSS: SOAP Message Security mechanisms or by mechanisms out of
720scope of SOAP message security, for example by sending the message over a secure transport protocol
721like HTTPS. The binding specific token properties detail the exact mechanism by which the protection is
722provided.
723
724There MAY be multiple EncryptedParts assertions present. Multiple EncryptedParts assertions present
725within a policy alternative are equivalent to a single EncryptedParts assertion containing the union of all
726specified message parts. Note that this assertion does not require that a given part appear in a message,
727just that if such a part appears, it requires confidentiality protection.
728Syntax
729 <sp:EncryptedParts xmlns:sp="..." ... >
730 <sp:Body/>?
731 <sp:Header Name="xs:NCName"? Namespace="xs:anyURI" ... />*
732 <sp:Attachments />?
733 ...
734 </sp:EncryptedParts>
735
737/sp:EncryptedParts
738 This assertion specifies the parts of the message that need confidentiality protection. The single
739 child element of this assertion specifies the set of message parts using an extensible dialect.
740 If no child elements are specified, the body of the message MUST be confidentiality protected.
741/sp:EncryptedParts/sp:Body
742 Presence of this optional empty element indicates that the entire body of the message needs to
743 be confidentiality protected. In the case where mechanisms from WSS: SOAP Message Security
744 are used to satisfy this assertion, then the soap:Body element is encrypted using the #Content
745 encryption type.
746/sp:EncryptedParts/sp:Header
747 Presence of this optional element indicates that a specific SOAP header (or set of such headers)
748 needs to be protected. There may be multiple sp:Header elements within a single Parts element.
749 Each header or set of headers MUST be encrypted. Such encryption will encrypt such elements
750 using WSS 1.1 Encrypted Headers. As such, if WSS 1.1 Encrypted Headers are not supported by
751 a service, then this element cannot be used to specify headers that require encryption using
752 message level security. If multiple SOAP headers with the same local name but different

753 namespace names are to be encrypted then multiple sp:Header elements are needed, either as
754 part of a single sp:EncryptedParts assertion or as part of separate sp:EncryptedParts assertions.
755/sp:EncryptedParts/sp:Header/@Name
756 This optional attribute indicates the local name of the SOAP header to be confidentiality
757 protected. If this attribute is not specified, all SOAP headers whose namespace matches the
758 Namespace attribute are to be protected.
759/sp:EncryptedParts/sp:Header/@Namespace
760 This required attribute indicates the namespace of the SOAP header(s) to be confidentiality
761 protected.
762/sp:EncryptedParts/sp:Attachments
763 Presence of this optional empty element indicates that all SwA (SOAP Messages with
764 Attachments) attachments [SwA] are to be confidentiality protected. When SOAP Message
765 Security is used to accomplish this, all message parts other than the part containing the primary
766 SOAP envelope are to be confidentiality protected as outlined in WSS: SOAP Message Security
767 [WSS:SwAProfile1.1].
7684.2.2 EncryptedElements Assertion

769The EncryptedElements assertion is used to specify arbitrary elements in the message that require
770confidentiality protection. This assertion can be satisfied using WSS: SOAP Message Security
771mechanisms or by mechanisms out of scope of SOAP message security, for example by sending the
772message over a secure transport protocol like HTTPS. The binding specific token properties detail the
773exact mechanism by which the protection is provided.
774
775There MAY be multiple EncryptedElements assertions present. Multiple EncryptedElements assertions
776present within a policy alternative are equivalent to a single EncryptedElements assertion containing the
777union of all specified XPath expressions.
778Syntax
779 <sp:EncryptedElements XPathVersion="xs:anyURI"? xmlns:sp="..." ... >
781 ...
782 </sp:EncryptedElements>
784/sp:EncryptedElements
785 This assertion specifies the parts of the message that need confidentiality protection. Any such
786 elements are subject to #Element encryption.
787/sp:EncryptedElements/@XPathVersion
790/sp:EncryptedElements/sp:XPath
792 confidentiality protected. The XPath expression is evaluated against the S:Envelope element
793 node of the message. Multiple instances of this element may appear within this assertion and
794 should be treated as separate references.

7954.2.3 ContentEncryptedElements Assertion
796The ContentEncryptedElements assertion is used to specify arbitrary elements in the message that
797require confidentiality protection of their content. This assertion can be satisfied using WSS: SOAP
798Message Security mechanisms or by mechanisms out of scope of SOAP message security, for example
799by sending the message over a secure transport protocol like HTTPS. The binding specific token
800properties detail the exact mechanism by which the protection is provided.
801
802There MAY be multiple ContentEncryptedElements assertions present. Multiple
803ContentEncryptedElements assertions present within a policy alternative are equivalent to a single
804ContentEncryptedElements assertion containing the union of all specified XPath expressions.
805Syntax
806 <sp:ContentEncryptedElements XPathVersion="xs:anyURI"? ...>
808 ...
809 </sp:ContentEncryptedElements>
811/sp:ContentEncryptedElements
812 This assertion specifies the parts of the message that need confidentiality protection. Any such
813 elements are subject to #Content encryption.
814/sp:ContentEncryptedElements/@XPathVersion
815 This optional attribute contains a URI which indicates the version of XPath to use.
816/sp:ContentEncryptedElements/sp:XPath
818 confidentiality protected. The XPath expression is evaluated against the S:Envelope element
819 node of the message. Multiple instances of this element MAY appear within this assertion and
820 should be treated as separate references.
8214.3 Required Elements Assertion

822A mechanism is defined for specifying, using XPath expressions, the set of header elements that a
823message MUST contain.
824
825Note: Specifications are expected to provide domain specific assertions that specify which headers are
826expected in a message. This assertion is provided for cases where such domain specific assertions have
827not been defined.
8284.3.1 RequiredElements Assertion

829The RequiredElements assertion is used to specify header elements that the message MUST contain.
830This assertion specifies no security requirements.
831
832There MAY be multiple RequiredElements assertions present. Multiple RequiredElements assertions
833present within a policy alternative are equivalent to a single RequiredElements assertion containing the
834union of all specified XPath expressions.
835Syntax

836 <sp:RequiredElements XPathVersion="xs:anyURI"? xmlns:sp="..." ... >
837 <sp:XPath>xs:string</sp:XPath> +
838 ...
839 </sp:RequiredElements>
840
842/sp:RequiredElements
843 This assertion specifies the headers elements that MUST appear in a message.
844/sp:RequiredElements/@XPathVersion
847/sp:RequiredElements/sp:XPath
848 This element contains a string specifying an XPath expression that identifies the header elements
849 that a message MUST contain. The XPath expression is evaluated against the
850 S:Envelope/S:Header element node of the message. Multiple instances of this element may
851 appear within this assertion and should be treated as a combined XPath expression.
8524.3.2 RequiredParts Assertion

853RequiredParts is a QName based alternative to the RequiredElements assertion (which is based on
854XPATH) for specifying header elements that MUST be present in the message. This assertion specifies
855no security requirements.
856
857There MAY be multiple RequiredParts assertions present. Multiple RequiredParts assertions present
858within a policy alternative are equivalent to a single RequiredParts assertion containing the union of all
859specified Header elements.
860Syntax
861 <sp:RequiredParts XPathVersion="xs:anyURI"? xmlns:sp="..." ... >
862 <sp:Header Name ="..." Namespace= "..." /> +
863 </sp:RequiredParts>
864
866/sp:RequiredParts/sp:Header
867 This assertion specifies the headers elements that MUST be present in the message.
868/sp:RequiredParts/sp:Header/@Name
869 This required attribute indicates the local name of the SOAPHeader that needs to be present in
870 the message.
871/sp:RequiredParts/sp:Header/@Namespace
872 This required attribute indicates the namespace of the SOAP header that needs to be present in
873 the message.

8745 Token Assertions
875Token assertions specify the type of tokens to use to protect or bind tokens and claims to the message.
876These assertions do not recommend usage of a Policy Subject. Assertions which contain them SHOULD
877recommend a policy attachment point. With the exception of transport token assertions, the token
878assertions defined in this section are not specific to any particular security binding.
8795.1 Token Inclusion

880Any token assertion may also carry an optional sp:IncludeToken attribute. The schema type of this
881attribute is xs:anyURI. This attribute indicates whether the token should be included, that is written, in
882the message or whether cryptographic operations utilize an external reference mechanism to refer to the
883key represented by the token. This attribute is defined as a global attribute in the WS-SecurityPolicy
884namespace and is intended to be used by any specification that defines token assertions.
8855.1.1 Token Inclusion Values

886The following table describes the set of valid token inclusion mechanisms supported by this
887specification:
http://docs.oasis-open.org/ws-sx/ws- The token MUST NOT be included in any
securitypolicy/200702/IncludeToken/Never messages sent between the initiator and the
recipient; rather, an external reference to the token
should be used.
http://docs.oasis-open.org/ws-sx/ws- The token MUST be included in only one message
securitypolicy/200702/IncludeToken/Once sent from the initiator to the recipient. References
to the token MAY use an internal reference
mechanism. Subsequent related messages sent
between the recipient and the initiator may refer to
the token using an external reference mechanism.
http://docs.oasis-open.org/ws-sx/ws- The token MUST be included in all messages sent
securitypolicy/200702/IncludeToken/AlwaysToReci from initiator to the recipient. The token MUST
pient NOT be included in messages sent from the
recipient to the initiator.
securitypolicy/200702/IncludeToken/AlwaysToInitia from the recipient to the initiator. The token MUST
tor NOT be included in messages sent from the
initiator to the recipient.
securitypolicy/200702/IncludeToken/Always between the initiator and the recipient. This is the
default behavior.
888
889Note: In examples, the namespace URI is replaced with "..." for brevity. For example,
890.../IncludeToken/Never is actually http://docs.oasis-open.org/ws-sx/ws-
891securitypolicy/200702/IncludeToken/Never. Other token inclusion URI values MAY be defined but are out-
892of-scope of this specification.
893The default behavior characteristics defined by this specification if this attribute is not specified on a token
894assertion are .../IncludeToken/Always.
8955.1.2 Token Inclusion and Token References

896A token assertion may carry a sp:IncludeToken attribute that requires that the token be included in the
897message. The Web Services Security specifications [WSS10, WSS11] define mechanisms for how tokens
898are included in a message.
899Several Token assertions (see Section 5.3) support mechanisms for referencing tokens in addition to
900Direct References, for example external URI references or references using a Thumbprint.
901Certain combination of sp:IncludeToken value and token reference assertions can result in a token
902appearing in a message more than once. For example, if a token assertion carries a sp:IncludeToken
903attribute with a value of '.../Always' and that token assertion also contains a nested
904sp:RequireEmbeddedTokenReference (see Section 5.3.3) assertion, then the token would be included
905twice in the message. While such combinations are not in error, they are probably best avoided for
906efficiency reasons.
907If a token assertion contains multiple reference assertions, then references to that token are required to
908contain all the specified reference types. For example, if a token assertion contains nested
909sp:RequireIssuerSerialReference and sp:RequireThumbprintReference assertions then references to that
910token contain both reference forms. Again, while such combinations are not in error, they are probably
911best avoided for efficiency reasons.
9125.2 Token Issuer and Required Claims
9135.2.1 Token Issuer

914Any token assertion may also carry an optional sp:Issuer element. The schema type of this element is
915wsa:EndpointReferenceType. This element indicates the token issuing authority by pointing to the issuer
916endpoint address. This element is defined as a global element in the WS-SecurityPolicy namespace and
917is intended to be used by any specification that defines token assertions.
9185.2.2 Token Issuer Name

919Any token assertion may also carry an optional sp:IssuerName element. The schema type of this element
920is xs:anyURI. This element indicated the token issuing authority by pointing to the issuer by using its
921logical name. This element is defined as a global element in the WS-SecurityPolicy namespace and is
922intended to be used by any specification that defines token assertions.
923
924It is out of scope of this specification how the relationship between the issuer’s logical name and the
925physical manifestation of the issuer in the security token is defined.
926While both sp:Issuer and sp:IssuerName elements are optional they are also mutually exclusive and
927cannot be specified both at the same time.
9285.2.3 Required Claims

929Any token assertion may also carry an optional wst:Claims element. The element content is defined in the
930WS-Trust namespace. This specification does not further define or limit the content of this element or the
931wst:Claims/@Dialect attribute as it is out of scope of this document.
932
933This element indicates the required claims that the security token must contain in order to satisfy the
934requirements of the token assertion.
935
936Individual token assertions may further limit what claims may be specified for that specific token assertion.
9375.2.4 Processing Rules and Token Matching
938The sender is free to compose the requirements expressed by token assertions inside the receiver’s
939policy to as many tokens as it sees fit. As long as the union of all tokens in the received message
940contains the required set of claims from required token issuers the message is valid according to the
941receiver’s policy.
942For example if the receiver’s policy contains two token assertions, one requires IssuedToken from issuer
943A with claims C1 and C2 and the second requires IssuedToken from issuer B with claims C3 and C4, the
944sender can satisfy such requirements with any of the following security token decomposition:
945
946 1. Two tokens, T1 and T2. T1 is issued by issuer A and contains claims C1 and C2 and
947 T2 is issued by issuer B and contains claims C3 and C4.
948 2. Three tokens, T1, T2 and T3. T1 is issued by issuer A and contains claim C1, T2 is
949 also issued by issuer A and contains claim C2 and T3 is issued by issuer B and
950 contains claims C3 and C4.
951 3. Three tokens, T1, T2 and T3. T1 is issued by issuer A and contains claims C1 and C2,
952 T2 is issued by issuer B and contains claim C3 and T3 is also issued by issuer B and
953 contains claim C4.
954 4. Four tokens, T1, T2, T3 and T4. T1 is issued by issuer A and contains claim C1, T2 is
955 also issued by issuer A and contains claim C2, T3 is issued by issuer B and contains
956 claim C3 and T4 is also issued by issuer B and contains claim C4.
9575.3 Token Properties
9585.3.1 [Derived Keys] Property

959This boolean property specifies whether derived keys should be used as defined in WS-
960SecureConversation. If the value is 'true', derived keys MUST be used. If the value is 'false', derived keys
961MUST NOT be used. The value of this property applies to a specific token. The value of this property is
962populated by assertions specific to the token. The default value for this property is 'false'.
963See the [Explicit Derived Keys] and [Implied Derived Key] properties below for information on how
964particular forms of derived keys are specified.
965Where the key material associated with a token is asymmetric, this property applies to the use of
966symmetric keys encrypted with the key material associated with the token.
9675.3.2 [Explicit Derived Keys] Property

968This boolean property specifies whether Explicit Derived Keys (see Section 7 of [WS-
969SecureConversation]) are allowed. If the value is 'true' then Explicit Derived Keys MAY be used. If the
970value is 'false' then Explicit Derived Keys MUST NOT be used.
9715.3.3 [Implied Derived Keys] Property

972This boolean property specifies whether Implied Derived Keys (see Section 7.3 of [WS-
973SecureConversation]) are allowed. If the value is 'true' then Implied Derived Keys MAY be used. If the
974value is 'false' then Implied Derived Keys MUST NOT be used.
9755.4 Token Assertion Types

976The following sections describe the token assertions defined as part of this specification.

9775.4.1 UsernameToken Assertion
978This element represents a requirement to include a username token.
979There are cases where encrypting the UsernameToken is reasonable. For example:
980 1. When transport security is not used.
981 2. When a plaintext password is used.
982 3. When a weak password hash is used.
983 4. When the username needs to be protected, e.g. for privacy reasons.
984When the UsernameToken is to be encrypted it SHOULD be listed as a
985SignedEncryptedSupportingToken (Section 8.5), EndorsingEncryptedSupportingToken (Section 8.6) or
986SignedEndorsingEncryptedSupportingToken (Section 8.7).
987
988Syntax
989 <sp:UsernameToken sp:IncludeToken="xs:anyURI"? xmlns:sp="..." ... >
990 (
991 <sp:Issuer>wsa:EndpointReferenceType</sp:Issuer> |
992 <sp:IssuerName>xs:anyURI</sp:IssuerName>
993 ) ?
994 <wst:Claims Dialect="..."> ... </wst:Claims> ?
995 <wsp:Policy xmlns:wsp="...">
996 (
997 <sp:NoPassword ... /> |
998 <sp:HashPassword ... />
999 ) ?
1000 (
1001 <sp:RequireDerivedKeys /> |
1002 <sp:RequireImpliedDerivedKeys ... /> |
1003 <sp:RequireExplicitDerivedKeys ... />
1004 ) ?
1005 (
1006 <sp:WssUsernameToken10 ... /> |
1007 <sp:WssUsernameToken11 ... />
1008 ) ?
1009 ...
1010 </wsp:Policy>
1011 ...
1012 </sp:UsernameToken>
1013
1015/sp:UsernameToken
1016 This identifies a UsernameToken assertion.
1017/sp:UsernameToken/@sp:IncludeToken
1018 This optional attribute identifies the token inclusion value for this token assertion.
1019/sp:UsernameToken/sp:Issuer
1020 This optional element, of type wsa:EndpointReferenceType, contains reference to the issuer of
1021 the sp:UsernameToken.
1022/sp:UsernameToken/sp:IssuerName
1023 This optional element, of type xs:anyURI, contains the logical name of the sp:UsernameToken
1024 issuer.

1025/sp:UsernameToken/wst:Claims
1026 This optional element identifies the required claims that a security token must contain in order to
1027 satisfy the token assertion requirements.
1028/sp:UsernameToken/wsp:Policy
1029 This required element identifies additional requirements for use of the sp:UsernameToken
1030 assertion.
1031/sp:UsernameToken/wsp:Policy/sp:NoPassword
1032 This optional element is a policy assertion that indicates that the wsse:Password element MUST
1033 NOT be present in the Username token.
1034/sp:UsernameToken/wsp:Policy/sp:HashPassword
1035 This optional element is a policy assertion that indicates that the wsse:Password element MUST
1036 be present in the Username token and that the content of the wsse:Password element MUST
1037 contain a hash of the timestamp, nonce and password as defined in [WSS: Username Token
1038 Profile].
1039/sp:UsernameToken/wsp:Policy/sp:RequireDerivedKeys
1040 This optional element is a policy assertion that sets the [Derived Keys], [Explicit Derived Keys]
1041 and [Implied Derived Keys] properties for this token to 'true'.
1042/sp:UsernameToken/wsp:Policy/sp:RequireExplicitDerivedKeys
1043 This optional element is a policy assertion that sets the [Derived Keys] and [Explicit Derived Keys]
1044 properties for this token to 'true' and the [Implied Derived Keys] property for this token to 'false'.
1045/sp:UsernameToken/wsp:Policy/sp:RequireImpliedDerivedKeys
1046 This optional element is a policy assertion that sets the [Derived Keys] and [Implied Derived
1047 Keys] properties for this token to 'true' and the [Explicit Derived Keys] property for this token to
1048 'false'.
1049/sp:UsernameToken/wsp:Policy/sp:WssUsernameToken10
1050 This optional element is a policy assertion that indicates that a Username token should be used
1051 as defined in [WSS:UsernameTokenProfile1.0].
1052/sp:UsernameToken/wsp:Policy/sp:WssUsernameToken11
1053 This optional element is a policy assertion that indicates that a Username token should be used
1054 as defined in [WSS:UsernameTokenProfile1.1].
10555.4.2 IssuedToken Assertion

1056This element represents a requirement for an issued token, which is one issued by some token issuer
1057using the mechanisms defined in WS-Trust. This assertion is used in 3rd party scenarios. For example, the
1058initiator may need to request a SAML token from a given token issuer in order to secure messages sent to
1059the recipient.
1060Syntax
1061 <sp:IssuedToken sp:IncludeToken="xs:anyURI"? xmlns:sp="..." ... >
1062 (
1065 ) ?

1067 <sp:RequestSecurityTokenTemplate TrustVersion="xs:anyURI"? >
1068 ...
1069 </sp:RequestSecurityTokenTemplate>
1071 (
1072 <sp:RequireDerivedKeys ... /> |
1075 ) ?
1076 <sp:RequireExternalReference ... /> ?
1077 <sp:RequireInternalReference ... /> ?
1078 ...
1079 </wsp:Policy>
1080 ...
1081 </sp:IssuedToken>
1083/sp:IssuedToken
1084 This identifies an IssuedToken assertion.
1085/sp:IssuedToken/@sp:IncludeToken
1087/sp:IssuedToken/sp:Issuer
1088 This optional element, of type wsa:EndpointReferenceType, contains a reference to the issuer for
1089 the issued token.
1090/sp:IssuedToken/sp:IssuerName
1091 This optional element, of type xs:anyURI, contains the logical name of the sp:IssuedToken issuer.
1092/sp:IssuedToken/wst:Claims
1095/sp:IssuedToken/sp:RequestSecurityTokenTemplate
1096 This required element contains elements which MUST be copied into the
1097 wst:SecondaryParameters of the RST request sent to the specified issuer. Note: the initiator is
1098 not required to understand the contents of this element.
1099 See Appendix B for details of the content of this element.
1100/sp:IssuedToken/sp:RequestSecurityTokenTemplate/@TrustVersion
1101 This optional attribute contains a WS-Trust specification namespace URI identifying the version of
1102 WS-Trust referenced by the contents of this element.
1103/sp:IssuedToken/wsp:Policy
1104 This required element identifies additional requirements for use of the sp:IssuedToken assertion.
1105/sp:IssuedToken/wsp:Policy/sp:RequireDerivedKeys
1108/sp:IssuedToken/wsp:Policy/sp:RequireExplicitDerivedKeys
1111/sp:IssuedToken/wsp:Policy/sp:RequireImpliedDerivedKeys

1114 'false'.
1115/sp:IssuedToken/wsp:Policy/sp:RequireInternalReference
1116 This optional element is a policy assertion that indicates whether an internal reference is required
1117 when referencing this token.
1118 Note: This reference will be supplied by the issuer of the token.
1119/sp:IssuedToken/wsp:Policy/sp:RequireExternalReference
1120 This optional element is a policy assertion that indicates whether an external reference is required
1122 Note: This reference will be supplied by the issuer of the token.
1123Note: The IssuedToken may or may not be associated with key material and such key material may be
1124symmetric or asymmetric. The Binding assertion will imply the type of key associated with this token.
1125Services may also include information in the sp:RequestSecurityTokenTemplate element to
1126explicitly define the expected key type. See Appendix B for details of the
1127sp:RequestSecurityTokenTemplate element.
11285.4.3 X509Token Assertion

1129This element represents a requirement for a binary security token carrying an X509 token.
1130Syntax
1131 <sp:X509Token sp:IncludeToken="xs:anyURI"? xmlns:sp="..." ... >
1132 (
1135 ) ?
1138 (
1140 <sp:RequireExplicitDerivedKeys ... /> |
1141 <sp:RequireImpliedDerivedKeys ... />
1142 ) ?
1143 <sp:RequireKeyIdentifierReference ... /> ?
1144 <sp:RequireIssuerSerialReference ... /> ?
1145 <sp:RequireEmbeddedTokenReference ... /> ?
1146 <sp:RequireThumbprintReference ... /> ?
1147 (
1148 <sp:WssX509V3Token10 ... /> |
1149 <sp:WssX509Pkcs7Token10 ... /> |
1150 <sp:WssX509PkiPathV1Token10 ... /> |
1151 <sp:WssX509V1Token11 ... /> |
1152 <sp:WssX509V3Token11 ... /> |
1153 <sp:WssX509Pkcs7Token11 ... /> |
1154 <sp:WssX509PkiPathV1Token11 ... />
1155 ) ?
1156 ...
1157 </wsp:Policy>
1158 ...
1159 </sp:X509Token>
1160
1162/sp:X509Token
1163 This identifies an X509Token assertion.
1164/sp:X509Token/@sp:IncludeToken
1166/sp:X509Token/sp:Issuer
1168 the sp:X509Token.
1169/sp:X509Token/sp:IssuerName
1170 This optional element, of type xs:anyURI, contains the logical name of the sp:X509Token issuer.
1171/sp:X509Token/wst:Claims
1174/sp:X509Token/wsp:Policy
1175 This required element identifies additional requirements for use of the sp:X509Token assertion.
1176/sp:X509Token/wsp:Policy/sp:RequireDerivedKeys
1179/sp:X509Token/wsp:Policy/sp:RequireExplicitDerivedKeys
1182/sp:X509Token/wsp:Policy/sp:RequireImpliedDerivedKeys
1185 'false'.
1186/sp:X509Token/wsp:Policy/sp:RequireKeyIdentifierReference
1187 This optional element is a policy assertion that indicates that a key identifier reference is required
1189/sp:X509Token/wsp:Policy/sp:RequireIssuerSerialReference
1190 This optional element is a policy assertion that indicates that an issuer serial reference is required
1192/sp:X509Token/wsp:Policy/sp:RequireEmbeddedTokenReference
1193 This optional element is a policy assertion that indicates that an embedded token reference is
1194 required when referencing this token.
1195/sp:X509Token/wsp:Policy/sp:RequireThumbprintReference
1196 This optional element is a policy assertion that indicates that a thumbprint reference is required
1198/sp:X509Token/wsp:Policy/sp:WssX509V3Token10
1199 This optional element is a policy assertion that indicates that an X509 Version 3 token should be
1200 used as defined in [WSS:X509TokenProfile1.0].
1201/sp:X509Token/wsp:Policy/sp:WssX509Pkcs7Token10
1202 This optional element is a policy assertion that indicates that an X509 PKCS7 token should be
1204/sp:X509Token/wsp:Policy/sp:WssX509PkiPathV1Token10

1205 This optional element is a policy assertion that indicates that an X509 PKI Path Version 1 token
1206 should be used as defined in [WSS:X509TokenProfile1.0].
1213/sp:X509Token/wsp:Policy/sp:WssX509Pkcs7Token11
1214 This optional element is a policy assertion that indicates that an X509 PKCS7 token should be
1216/sp:X509Token/wsp:Policy/sp:WssX509PkiPathV1Token11
1217 This optional element is a policy assertion that indicates that an X509 PKI Path Version 1 token
1218 should be used as defined in [WSS:X509TokenProfile1.1].
12195.4.4 KerberosToken Assertion

1220This element represents a requirement for a Kerberos token [WSS:KerberosToken1.1].
1221Syntax
1222 <sp:KerberosToken sp:IncludeToken="xs:anyURI"? xmlns:sp="..." ... >
1223 (
1226 ) ?
1229 (
1233 ) ?
1235 (
1236 <sp:WssKerberosV5ApReqToken11 ... /> |
1237 <sp:WssGssKerberosV5ApReqToken11 ... />
1238 ) ?
1240 ...
1241 </wsp:Policy>
1242 ...
1243 </sp:KerberosToken>
1244
1246/sp:KerberosToken
1247 This identifies a KerberosV5ApReqToken assertion.
1248/sp:KerberosToken/@sp:IncludeToken
1250/sp:KerberosToken/sp:Issuer
1252 the sp:KerberosToken.
1253/sp:KerberosToken/sp:IssuerName
1254 This optional element, of type xs:anyURI, contains the logical name of the sp:KerberosToken
1255 issuer.
1256/sp:KerberosToken/wst:Claims
1259/sp:KerberosToken/wsp:Policy
1260 This required element identifies additional requirements for use of the sp:KerberosToken
1261 assertion.
1262/sp:KerberosToken/wsp:Policy/sp:RequireDerivedKeys
1265/sp:KerberosToken/wsp:Policy/sp:RequireExplicitDerivedKeys
1268/sp:KerberosToken/wsp:Policy/sp:RequireImpliedDerivedKeys
1271 'false'.
1272/sp:KerberosToken/wsp:Policy/sp:RequireKeyIdentifierReference
1275/sp:KerberosToken/wsp:Policy/sp:WssKerberosV5ApReqToken11
1276 This optional element is a policy assertion that indicates that a Kerberos Version 5 AP-REQ token
1277 should be used as defined in [WSS:KerberosTokenProfile1.1].
1278/sp:KerberosToken/wsp:Policy/sp:WssGssKerberosV5ApReqToken11
1279 This optional element is a policy assertion that indicates that a GSS Kerberos Version 5 AP-REQ
1280 token should be used as defined in [WSS:KerberosTokenProfile1.1].
12815.4.5 SpnegoContextToken Assertion

1282This element represents a requirement for a SecurityContextToken obtained by executing an n-leg
1283RST/RSTR SPNEGO binary negotiation protocol with the Web Service, as defined in WS-Trust.
1284Syntax
1285 <sp:SpnegoContextToken sp:IncludeToken="xs:anyURI"? xmlns:sp="..." ... >
1286 (
1289 ) ?
1292 (
1296 ) ?
1297 <sp:MustNotSendCancel ... /> ?
1298 <sp:MustNotSendAmend ... /> ?

1299 <sp:MustNotSendRenew ... /> ?
1300 ...
1301 </wsp:Policy>
1302 ...
1303 </sp:SpnegoContextToken>
1304
1306/sp:SpnegoContextToken
1307 This identifies a SpnegoContextToken assertion.
1308/sp:SpnegoContextToken/@sp:IncludeToken
1310/sp:SpnegoContextToken/sp:Issuer
1312 the Spnego Context Token.
1313/sp:SpnegoContextToken/sp:IssuerName
1314 This optional element, of type xs:anyURI, contains the logical name of the
1315 sp:SpnegoContextToken issuer.
1316/sp:SpnegoContextToken/wst:Claims
1319/sp:SpnegoContextToken/wsp:Policy
1320 This required element identifies additional requirements for use of the sp:SpnegoContextToken
1321 assertion.
1322/sp:SpnegoContextToken/wsp:Policy/sp:RequireDerivedKeys
1325/sp:SpnegoContextToken/wsp:Policy/sp:RequireExplicitDerivedKeys
1328/sp:SpnegoContextToken/wsp:Policy/sp:RequireImpliedDerivedKeys
1331 'false'.
1332sp:SpnegoContextToken/wsp:Policy/sp:MustNotSendCancel
1333 This optional element is a policy assertion that indicates that the STS issuing the SP/Nego token
1334 does not support SCT/Cancel RST messages. If this assertion is missing it means that
1335 SCT/Cancel RST messages are supported by the STS.
1336/sp:SpnegoContextToken/wsp:Policy/sp:MustNotSendAmend
1338 does not support SCT/Amend RST messages. If this assertion is missing it means that
1339 SCT/Amend RST messages are supported by the STS.
1340/sp:SpnegoContextToken/wsp:Policy/sp:MustNotSendRenew

1342 does not support SCT/Renew RST messages. If this assertion is missing it means that
1343 SCT/Renew RST messages are supported by the STS.
13445.4.6 SecurityContextToken Assertion

1345This element represents a requirement for a SecurityContextToken token.
1346Syntax
1347 <sp:SecurityContextToken sp:IncludeToken="xs:anyURI"? xmlns:sp="..." ... >
1348 (
1351 ) ?
1354 (
1358 ) ?
1359 <sp:RequireExternalUriReference ... /> ?
1360 <sp:SC13SecurityContextToken... /> ?
1361 ...
1362 </wsp:Policy>
1363 ...
1364 </sp:SecurityContextToken>
1365
1367/sp:SecurityContextToken
1368 This identifies a SecurityContextToken assertion.
1369/sp:SecurityContextToken/@sp:IncludeToken
1371/sp:SecurityContextToken/sp:Issuer
1373 the sp:SecurityContextToken.
1374/sp:SecurityContextToken/sp:IssuerName
1376 sp:SecurityContextToken issuer.
1377/sp:SecurityContextToken/wst:Claims
1380/sp:SecurityContextToken/wsp:Policy
1381 This required element identifies additional requirements for use of the sp:SecurityContextToken
1382 assertion.
1383/sp:SecurityContextToken/wsp:Policy/sp:RequireDerivedKeys
1386/sp:SecurityContextToken/wsp:Policy/sp:RequireExplicitDerivedKeys

1389/sp:SecurityContextToken/wsp:Policy/sp:RequireImpliedDerivedKeys
1392 'false'.
1393/sp:SecurityContextToken/wsp:Policy/sp:RequireExternalUriReference
1394 This optional element is a policy assertion that indicates that an external URI reference is
1396/sp:SecurityContextToken/wsp:Policy/sp:SC13SecurityContextToken
1397 This optional element is a policy assertion that indicates that a Security Context Token should be
1398 used as defined in [WS-SecureConversation].
1399
1400Note: This assertion does not describe how to obtain a Security Context Token but rather assumes that
1401both parties have the token already or have agreed separately on a mechanism for obtaining the token. If
1402a definition of the mechanism for obtaining the Security Context Token is desired in policy, then either the
1403sp:SecureConversationToken or the sp:IssuedToken assertion should be used instead.
14045.4.7 SecureConversationToken Assertion

1405This element represents a requirement for a Security Context Token retrieved from the indicated issuer
1406address. If the sp:Issuer address is absent, the protocol MUST be executed at the same address as the
1407service endpoint address.
1408
1409Note: This assertion describes the token accepted by the target service. Because this token is issued by
1410the target service and may not have a separate port (with separate policy), this assertion SHOULD
1411contain a bootstrap policy indicating the security binding and policy that is used when requesting this
1412token from the target service. That is, the bootstrap policy is used to obtain the token and then the
1413current (outer) policy is used when making requests with the token. This is illustrated in the diagram
1414
1415below.
Initiator Recipient
RST
Bootstrap Policy
RSTR
Application Request
Outer Policy
...
1416Syntax
1417 <sp:SecureConversationToken sp:IncludeToken="xs:anyURI"? xmlns:sp="..." ... >
1418 (

1421 ) ?
1424 (
1428 ) ?
1429 <sp:RequireExternalUriReference ... /> ?
1430 <sp:SC13SecurityContextToken ... /> ?
1431 <sp:MustNotSendCancel ... /> ?
1432 <sp:MustNotSendAmend ... /> ?
1433 <sp:MustNotSendRenew ... /> ?
1434 <sp:BootstrapPolicy ... >
1435 <wsp:Policy> ... </wsp:Policy>
1436 </sp:BootstrapPolicy> ?
1437 </wsp:Policy>
1438 ...
1439 </sp:SecureConversationToken>
1440
1442/sp:SecureConversationToken
1443 This identifies a SecureConversationToken assertion.
1444/sp:SecureConversationToken/@sp:IncludeToken
1446/sp:SecureConversationToken/sp:Issuer
1448 the Security Context Token.
1449/sp:SecureConversationToken/sp:IssuerName
1451 sp:SecureConversationToken issuer.
1452/sp:SpnegoContextToken/wst:Claims
1455/sp:SecureConversationToken/wsp:Policy
1456 This required element identifies additional requirements for use of the
1457 sp:SecureConversationToken assertion.
1458/sp:SecureConversationToken/wsp:Policy/sp:RequireDerivedKeys
1461/sp:SecureConversationToken/wsp:Policy/sp:RequireExplicitDerivedKeys
1464/sp:SecureConversationToken/wsp:Policy/sp:RequireImpliedDerivedKeys
1467 'false'.

1468/sp:SecureConversationToken/wsp:Policy/sp:RequireExternalUriReference
1469 This optional element is a policy assertion that indicates that an external URI reference is
1471/sp:SecureConversationToken/wsp:Policy/sp:SC13SecurityContextToken
1472 This optional element is a policy assertion that indicates that a Security Context Token should be
1473 used as obtained using the protocol defined in [WS-SecureConversation].
1474/sp:SecureConversationToken/wsp:Policy/sp:MustNotSendCancel
1475 This optional element is a policy assertion that indicates that the STS issuing the secure
1476 conversation token does not support SCT/Cancel RST messages. If this assertion is missing it
1477 means that SCT/Cancel RST messages are supported by the STS.
1478/sp:SecureConversationToken/wsp:Policy/sp:MustNotSendAmend
1480 conversation token does not support SCT/Amend RST messages. If this assertion is missing it
1481 means that SCT/Amend RST messages are supported by the STS.
1482/sp:SecureConversationToken/wsp:Policy/sp:MustNotSendRenew
1484 conversation token does not support SCT/Renew RST messages. If this assertion is missing it
1485 means that SCT/Renew RST messages are supported by the STS.
1486/sp:SecureConversationToken/wsp:Policy/sp:BootstrapPolicy
1487 This optional element is a policy assertion that contains the policy indicating the requirements for
1488 obtaining the Security Context Token.
1489/sp:SecureConversationToken/wsp:Policy/sp:BootstrapPolicy/wsp:Policy
1490 This element contains the security binding requirements for obtaining the Security Context Token.
1491 It will typically contain a security binding assertion (e.g. sp:SymmetricBinding) along with
1492 protection assertions (e.g. sp:SignedParts) describing the parts of the RST/RSTR messages that
1493 are to be protected.
1494Example
1495 <wsp:Policy xmlns:wsp="..." xmlns:sp="...">
1496 <sp:SymmetricBinding>
1497 <wsp:Policy>
1498 <sp:ProtectionToken>
1499 <wsp:Policy>
1500 <sp:SecureConversationToken>
1501 <sp:Issuer>
1502 <wsa:Address>http://example.org/sts</wsa:Address>
1503 </sp:Issuer>
1504 <wsp:Policy>

1505 <sp:SC10SecurityContextToken />
1506 <sp:BootstrapPolicy>
1507 <wsp:Policy>
1508 <sp:AsymmetricBinding>
1509 <wsp:Policy>
1510 <sp:InitiatorToken>
1511 ...
1512 </sp:InitiatorToken>
1513 <sp:RecipientToken>
1514 ...
1515 </sp:RecipientToken>
1516 </wsp:Policy>
1517 </sp:AsymmetricBinding>
1518 <sp:SignedParts>
1519 ...
1521 ...
1522 </wsp:Policy>
1523 </sp:BootstrapPolicy>
1524 </wsp:Policy>
1525 </sp:SecureConversationToken>
1526 </wsp:Policy>
1527 </sp:ProtectionToken>
1528 ...
1529 </wsp:Policy>
1530 </sp:SymmetricBinding>
1532 ...
1534 ...
1535 </wsp:Policy>
15365.4.8 SamlToken Assertion

1537This element represents a requirement for a SAML token.
1538Syntax
1539 <sp:SamlToken sp:IncludeToken="xs:anyURI"? xmlns:sp="..." ... >
1540 (
1543 ) ?
1546 (
1550 ) ?
1552 (
1553 <sp:WssSamlV11Token10 ... /> |
1554 <sp:WssSamlV11Token11 ... /> |
1555 <sp:WssSamlV20Token11 ... />
1556 ) ?
1557 ...
1558 </wsp:Policy>
1559 ...
1560 </sp:SamlToken>
1561

1563/sp:SamlToken
1564 This identifies a SamlToken assertion.
1565/sp:SamlToken/@sp:IncludeToken
1567/sp:SamlToken/sp:Issuer
1569 the sp:SamlToken.
1570/sp:SamlToken/sp:IssuerName
1571 This optional element, of type xs:anyURI, contains the logical name of the sp:SamlToken issuer.
1572/sp:SamlToken/wst:Claims
1575/sp:SamlToken/wsp:Policy
1576 This required element identifies additional requirements for use of the sp:SamlToken assertion.
1577/sp:SamlToken/wsp:Policy/sp:RequireDerivedKeys
1580/sp:SamlToken/wsp:Policy/sp:RequireExplicitDerivedKeys
1583/sp:SamlToken/wsp:Policy/sp:RequireImpliedDerivedKeys
1586 'false'.
1587/sp:SamlToken/wsp:Policy/sp:RequireKeyIdentifierReference
1590/sp:SamlToken/wsp:Policy/sp:WssSamlV11Token10
1591 This optional element is a policy assertion that identifies that a SAML Version 1.1 token should be
1592 used as defined in [WSS:SAMLTokenProfile1.0].
1599
1600Note: This assertion does not describe how to obtain a SAML Token but rather assumes that both parties
1601have the token already or have agreed separately on a mechanism for obtaining the token. If a definition
1602of the mechanism for obtaining the SAML Token is desired in policy, the sp:IssuedToken assertion should
1603be used instead.
16045.4.9 RelToken Assertion
1605This element represents a requirement for a REL token.
1606Syntax
1607 <sp:RelToken sp:IncludeToken="xs:anyURI"? xmlns:sp="..." ... >
1608 (
1611 ) ?
1614 (
1618 ) ?
1620 (
1621 <sp:WssRelV10Token10 ... /> |
1624 <sp:WssRelV20Token11 ... />
1625 ) ?
1626 ...
1627 </wsp:Policy>
1628 ...
1629 </sp:RelToken>
1630
1632/sp:RelToken
1633 This identifies a RelToken assertion.
1634/sp:RelToken/@sp:IncludeToken
1636/sp:RelToken/sp:Issuer
1638 the sp:RelToken.
1639/sp:RelToken/sp:IssuerName
1640 This optional element, of type xs:anyURI, contains the logical name of the sp:RelToken issuer.
1641/sp:RelToken/wst:Claims
1644/sp:RelToken/wsp:Policy
1645 This required element identifies additional requirements for use of the sp:RelToken assertion.
1646/sp:RelToken/wsp:Policy/sp:RequireDerivedKeys
1648 and [Implied Derived Keys] property for this token to 'true'.
1649/sp:RelToken/wsp:Policy/sp:RequireExplicitDerivedKeys
1652/sp:RelToken/wsp:Policy/sp:RequireImpliedDerivedKeys
1655 'false'.
1656/sp:RelToken/wsp:Policy/sp:RequireKeyIdentifierReference
1659/sp:RelToken/wsp:Policy/sp:WssRelV10Token10
1660 This optional element is a policy assertion that identifies that a REL Version 1.0 token should be
1661 used as defined in [WSS:RELTokenProfile1.0].
1671
1672Note: This assertion does not describe how to obtain a REL Token but rather assumes that both parties
1673have the token already or have agreed separately on a mechanism for obtaining the token. If a definition
1674of the mechanism for obtaining the REL Token is desired in policy, the sp:IssuedToken assertion should
1675be used instead.
16765.4.10 HttpsToken Assertion

1677This element represents a requirement for a transport binding to support the use of HTTPS.
1678Syntax
1679 <sp:HttpsToken xmlns:sp="..." ... >
1680 (
1683 ) ?
1686 (
1687 <sp:HttpBasicAuthentication /> |
1688 <sp:HttpDigestAuthentication /> |
1689 <sp:RequireClientCertificate /> |
1690 ...
1691 )?
1692 ...
1693 </wsp:Policy>
1694 ...
1695 </sp:HttpsToken>
1697/sp:HttpsToken

1698 This identifies an Https assertion stating that use of the HTTPS protocol specification is
1699 supported.
1700/sp:HttpsToken/sp:Issuer
1702 the sp:HttpsToken.
1703/sp:HttpsToken/sp:IssuerName
1704 This optional element, of type xs:anyURI, contains the logical name of the sp:HttpsToken issuer.
1705/sp:HttpsToken/wst:Claims
1708/sp:HttpsToken/wsp:Policy
1709 This required element identifies additional requirements for use of the sp:HttpsToken assertion.
1710/sp:HttpsToken/wsp:Policy/sp:HttpBasicAuthentication
1711 This optional element is a policy assertion that indicates that the client MUST use HTTP Basic
1712 Authentication [RFC2068] to authenticate to the service.
1713/sp:HttpsToken/wsp:Policy/sp:HttpDigestAuthentication
1714 This optional element is a policy assertion that indicates that the client MUST use HTTP Digest
1715 Authentication [RFC2068] to authenticate to the service.
1716/sp:HttpsToken/wsp:Policy/sp:RequireClientCertificate
1717 This optional element is a policy assertion that indicates that the client MUST provide a certificate
1718 when negotiating the HTTPS session.
17195.4.11 KeyValueToken Assertion

1720This element represents a requirement for a KeyValue token. The next section defines the KeyValue
1721security token abstraction for purposes of this token assertion.
1722
1723This document defines requirements for KeyValue token when used in combination with RSA
1724cryptographic algorithm. Additional cryptographic algorithms can be introduced in other specifications by
1725introducing new nested assertions besides sp:RsaKeyValue.
1726Syntax
1727 <sp:KeyValueToken sp:IncludeToken="xs:anyURI"? xmlns:sp="..." ... >
1729 <sp:RsaKeyValue ... /> ?
1730 ...
1731 </wsp:Policy>
1732 ...
1733 </sp:KeyValueToken>
1734The following describes the attributes listed in the schema outlined above:
1735/sp:KeyValueToken
1736 This identifies a RsaToken assertion.
1737/sp:KeyValueToken/@sp:IncludeToken
1739/sp:KeyValueToken/wsp:Policy
1740 This required element identifies additional requirements for use of the sp:KeyValueToken
1741 assertion.
1742/sp:KeyValueToken/wsp:Policy/sp:RsaKeyValue
1743 This optional element is a policy assertion that indicates that the ds:RSAKeyValue element must
1744 be present in the KeyValue token. This indicates that an RSA key pair must be used.
17455.4.11.1 KeyValue Token

1746XML Signature specification allows reference an arbitrary key pair by using the corresponding public key
1747value. This allows using an arbitrary key pair to sign or encrypt XML elements. The purpose of this
1748section is to define the KeyValue token abstraction that represents such key pair referencing mechanism.
1749
1750Although the ds:KeyValue element as defined in the XML Signature specification is generic enough to be
1751used with any asymmetric cryptographic algorithm this document only profiles the usage of ds:KeyValue
1752element in combination with RSA cryptographic algorithm.
1753
1754The RSA key pair is represented by the ds:KeyInfo element containing the ds:KeyValue element with the
1755RSA public key value in ds:RSAKeyValue as defined in the XML Signature specification:
1756 <ds:KeyInfo xmlns="http://www.w3/org/2000/09/xmldsig#">
1757 <ds:KeyValue>
1758 <ds:RSAKeyValue>
1759 <ds:Modulus>ds:CryptoBinary</ds:Modulus>
1760 <ds:Exponent>ds:CryptoBinary</ds:Exponent>
1761 </ds:RSAKeyValue>
1762 <ds:KeyValue>
1763 </ds:KeyInfo>
1764
1765When the KeyValue token is used the corresponding public key value appears directly in the signature or
1766encrypted data ds:KeyInfo element like in the following example. There is no KeyValue token
1767manifestation outside the ds:KeyInfo element.
1768 <Signature xmlns="http://www.w3.org/2000/09/xmldsig#">
1769 <SignedInfo>
1770 <CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-
1771 c14n#" />
1772 <SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1" />
1773 <Reference URI="#_1">
1774 <Transforms>
1775 <Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#" />
1776 </Transforms>
1777 <DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1" />
1778 <DigestValue>...</DigestValue>
1779 </Reference>
1780 </SignedInfo>
1781 <SignatureValue>...</SignatureValue>
1782 <KeyInfo>
1783 <KeyValue>
1784 <RSAKeyValue>
1785 <Modulus>...</Modulus>
1786 <Exponent>...</Exponent>
1787 </RSAKeyValue>
1788 </KeyValue>
1789 </KeyInfo>
1790 </Signature>
1791
1792Since there is no representation of the KeyValue token outside the ds:KeyInfo element and thus no
1793identifier can be associated with the token, the KeyValue token cannot be referenced by using
1794wsse:SecurityTokenReference element. However the ds:KeyInfo element representing the KeyValue
1795token can be used whenever a security token can be used as illustrated on the following example:
1796 <t:RequestSecurityToken xmlns:t="...">
1797 <t:RequestType>...</t:RequestType>

1798 ...
1799 <t:UseKey>
1800 <KeyInfo xmlns="http://www.w3.org/2000/09/xmldsig#">
1801 <KeyValue>
1802 <RSAKeyValue>
1803 <Modulus>...</Modulus>
1804 <Exponent>...</Exponent>
1805 </RSAKeyValue>
1806 </KeyValue>
1807 </KeyInfo>
1808 </t:UseKey>
1809 </t:RequestSecurityToken>

18106 Security Binding Properties
1811This section defines the various properties or conditions of a security binding, their semantics, values and
1812defaults where appropriate. Properties are used by a binding in a manner similar to how variables are
1813used in code. Assertions populate, (or set) the value of the property (or variable). When an assertion that
1814populates a value of a property appears in a policy, that property is set to the value indicated by the
1815assertion. The security binding then uses the value of the property to control its behavior. The properties
1816listed here are common to the various security bindings described in Section 7. Assertions that define
1817values for these properties are defined in Section 7. The following properties are used by the security
1818binding assertions.
18196.1 [Algorithm Suite] Property

1820This property specifies the algorithm suite required for performing cryptographic operations with
1821symmetric or asymmetric key based security tokens. An algorithm suite specifies actual algorithms and
1822allowed key lengths. A policy alternative will define what algorithms are used and how they are used. This
1823property defines the set of available algorithms. The value of this property is typically referenced by a
1824security binding and is used to specify the algorithms used for all message level cryptographic operations
1825performed under the security binding.
1826Note: In some cases, this property MAY be referenced under a context other than a security binding and
1827used to control the algorithms used under that context. For example, supporting token assertions define
1828such a context. In such contexts, the specified algorithms still apply to message level cryptographic
1829operations.
1830An algorithm suite defines values for each of the following operations and properties:
1831  [Sym Sig] Symmetric Key Signature
1832  [Asym Sig] Signature with an asymmetric key
1833  [Dig] Digest
1834  [Enc] Encryption
1835  [Sym KW] Symmetric Key Wrap
1836  [Asym KW] Asymmetric Key Wrap
1837  [Comp Key] Computed key
1838  [Enc KD] Encryption key derivation
1839  [Sig KD] Signature key derivation
1840  [Min SKL] Minimum symmetric key length
1841  [Max SKL] Maximum symmetric key length
1842  [Min AKL] Minimum asymmetric key length
1843  [Max AKL] Maximum asymmetric key length
1844
1845The following table provides abbreviations for the algorithm URI used in the table below:
Abbreviation Algorithm URI
HmacSha1 http://www.w3.org/2000/09/xmldsig#hmac-sha1
RsaSha1 http://www.w3.org/2000/09/xmldsig#rsa-sha1
Sha1 http://www.w3.org/2000/09/xmldsig#sha1

Sha256 http://www.w3.org/2001/04/xmlenc#sha256
Sha512 http://www.w3.org/2001/04/xmlenc#sha512
Aes128 http://www.w3.org/2001/04/xmlenc#aes128-cbc
TripleDes http://www.w3.org/2001/04/xmlenc#tripledes-cbc
KwAes128 http://www.w3.org/2001/04/xmlenc#kw-aes128
KwTripleDes http://www.w3.org/2001/04/xmlenc#kw-tripledes
KwRsaOaep http://www.w3.org/2001/04/xmlenc#rsa-oaep-mgf1p
KwRsa15 http://www.w3.org/2001/04/xmlenc#rsa-1_5
PSha1 http://docs.oasis-open.org/ws-sx/ws-secureconversation/200512/dk/p_sha1
PSha1L128 http://docs.oasis-open.org/ws-sx/ws-secureconversation/200512/dk/p_sha1
XPath http://www.w3.org/TR/1999/REC-xpath-19991116
XPath20 http://www.w3.org/2002/06/xmldsig-filter2
C14n http://www.w3.org/2001/10/xml-c14n#
ExC14n http://www.w3.org/2001/10/xml-exc-c14n#
SNT http://www.w3.org/TR/soap12-n11n
http://docs.oasis-open.org/wss/2004/xx/oasis-2004xx-wss-soap-message-
STRT10 security-1.0#STR-Transform
AbsXPath http://docs.oasis-open.org/...TBD.../AbsXPath
1846
1847The tables below show all the base algorithm suites defined by this specification. This table defines
1848values for properties which are common for all suites:
Property Algorithm / Value
[Sym Sig] HmacSha1
[Asym Sig] RsaSha1
[Comp Key] PSha1
[Max SKL] 256
[Min AKL] 1024
[Max AKL] 4096
1849This table defines additional properties whose values can be specified along with the default value for that
1850property.
Property Algorithm / Value
[C14n Algorithm] ExC14n
[Soap Norm] None
[STR Trans] None
[XPath] None
1851This table defines values for the remaining components for each algorithm suite.
Algorithm Suite [Dig] [Enc] [Sym KW] [Asym KW] [Enc KD] [Sig KD] [Min SKL]
Basic256 Sha1 Aes256 KwAes256 KwRsaOaep PSha1L256 PSha1L192 256
TripleDes Sha1 TripleDes KwTripleDes KwRsaOaep PSha1L192 PSha1L192 192
Basic256Rsa15 Sha1 Aes256 KwAes256 KwRsa15 PSha1L256 PSha1L192 256

Algorithm Suite [Dig] [Enc] [Sym KW] [Asym KW] [Enc KD] [Sig KD] [Min SKL]
TripleDesRsa15 Sha1 TripleDes KwTripleDes KwRsa15 PSha1L192 PSha1L192 192
Basic256Sha256 Sha256 Aes256 KwAes256 KwRsaOaep PSha1L256 PSha1L192 256
TripleDesSha256 Sha256 TripleDes KwTripleDes KwRsaOaep PSha1L192 PSha1L192 192
Basic256Sha256Rsa15 Sha256 Aes256 KwAes256 KwRsa15 PSha1L256 PSha1L192 256
TripleDesSha256Rsa15 Sha256 TripleDes KwTripleDes KwRsa15 PSha1L192 PSha1L192 192
18526.2 [Timestamp] Property

1853This boolean property specifies whether a wsu:Timestamp element is present in the wsse:Security
1854header. If the value is 'true', the timestamp element MUST be present and MUST be integrity protected
1855either by transport or message level security. If the value is 'false', the timestamp element MUST NOT be
1856present. The default value for this property is 'false'.
18576.3 [Protection Order] Property

1858This property indicates the order in which integrity and confidentiality are applied to the
1859message, in cases where both integrity and confidentiality are required:
EncryptBeforeSigning Signature MUST computed over ciphertext.
Encryption key and signing key MUST be derived
from the same source key unless distinct keys
are provided, see Section 7.5 on the
AsymmetricBinding.
SignBeforeEncrypting Signature MUST be computed over plaintext. The
resulting signature SHOULD be encrypted.
Supporting signatures MUST be over the plain
text signature.
1860The default value for this property is 'SignBeforeEncrypting'.
18616.4 [Signature Protection] Property

1862This boolean property specifies whether the signature must be encrypted. If the value is 'true', the primary
1863signature MUST be encrypted and any signature confirmation elements MUST also be encrypted. The
1864primary signature element is not required to be encrypted if the value is ‘true’ when there is nothing else
1865in the message that is encrypted. If the value is 'false', the primary signature MUST NOT be encrypted
1866and any signature confirmation elements MUST NOT be encrypted. The default value for this property is
1867'false'.
18686.5 [Token Protection] Property

1869This boolean property specifies whether signatures must cover the token used to generate that signature.
1870If the value is 'true', then each token used to generate a signature MUST be covered by that signature. If
1871the value is 'false', then the token MUST NOT be covered by the signature. Note that in cases where
1872derived keys are used the 'main' token, and NOT the derived key token, is covered by the signature. It is

1873recommended that assertions that define values for this property apply to [Endpoint Policy Subject]. The
1874default value for this property is 'false'.
18756.6 [Entire Header and Body Signatures] Property

1876This boolean property specifies whether signature digests over the SOAP body and SOAP headers must
1877only cover the entire body and entire header elements. If the value is 'true', then each digest over the
1878SOAP body MUST be over the entire SOAP body element and not a descendant of that element. In
1879addition each digest over a SOAP header MUST be over an actual header element and not a descendant
1880of a header element. This restriction does not specifically apply to the wsse:Security header. However
1881signature digests over child elements of the wsse:Security header MUST be over the entire child element
1882and not a descendent of that element. If the value is 'false', then signature digests MAY be over a
1883descendant of the SOAP Body or a descendant of a header element. Setting the value of this property to
1884'true' mitigates against some possible re-writing attacks. It is recommended that assertions that define
1885values for this property apply to [Endpoint Policy Subject]. The default value for this property is 'false'.
18866.7 [Security Header Layout] Property

1887This property indicates which layout rules to apply when adding items to the security header. The
1888following table shows which rules are defined by this specification.
Strict Items are added to the security header following
the numbered layout rules described below
according to a general principle of 'declare before
use'.
Lax Items are added to the security header in any
order that conforms to WSS: SOAP Message
Security
LaxTimestampFirst As Lax except that the first item in the security
header MUST be a wsse:Timestamp. Note that
the [Timestamp] property MUST also be set to
'true' in this case.
LaxTimestampLast As Lax except that the last item in the security
header MUST be a wsse:Timestamp. Note that
the [Timestamp] property MUST also be set to
'true' in this case.
1889
18906.7.1 Strict Layout Rules for WSS 1.0

1891 1. Tokens that are included in the message MUST be declared before use. For example:
1892 a. A local signing token MUST occur before the signature that uses it.
1893 b. A local token serving as the source token for a derived key token MUST occur before that
1894 derived key token.
1895 c. A local encryption token MUST occur before the reference list that points to
1896 xenc:EncryptedData elements that use it.
1897 d. If the same token is used for both signing and encryption, then it should appear before
1898 the ds:Signature and xenc:ReferenceList elements in the security header that are
1899 generated using the token.
1900 2. Signed elements inside the security header MUST occur before the signature that signs them.
1901 For example:
1902 a. A timestamp MUST occur before the signature that signs it.
1903 b. A Username token (usually in encrypted form) MUST occur before the signature that
1904 signs it.
1905 c. A primary signature MUST occur before the supporting token signature that signs the
1906 primary signature's signature value element.
1907 3. When an element in a security header is encrypted, the resulting xenc:EncryptedData element
1908 has the same order requirements as the source plain text element, unless requirement 4
1909 indicates otherwise. For example, an encrypted primary signature MUST occur before any
1910 supporting token signature per 2.c above and an encrypted token has the same ordering
1911 requirements as the unencrypted token.
1912If there are any encrypted elements in the message then a top level xenc:ReferenceList element or a top
1913level xenc:EncryptedKey element which contains an xenc:ReferenceList element MUST be present in the
1914security header. The xenc:ReferenceList or xenc:EncryptedKey MUST occur before any
1915xenc:EncryptedData elements in the security header that are referenced from the reference list. Strict
1916Layout Rules for WSS 1.1
1917 1. Tokens that are included in the message MUST be declared before use. For example:
1918 a. A local signing token MUST occur before the signature that uses it.
1919 b. A local token serving as the source token for a derived key token MUST occur before that
1920 derived key token.
1921 c. A local encryption token MUST occur before the reference list that points to
1922 xenc:EncryptedData elements that use it.
1923 d. If the same token is used for both signing and encryption, then it should appear before
1924 the ds:Signature and xenc:ReferenceList elements in the security header that are
1925 generated using the token.
1926 2. Signed elements inside the security header MUST occur before the signature that signs them.
1927 For example:
1928 a. A timestamp MUST occur before the signature that signs it.
1929 b. A Username token (usually in encrypted form) MUST occur before the signature that
1930 signs it.
1931 c. A primary signature MUST occur before the supporting token signature that signs the
1932 primary signature's signature value element.
1933 d. A wsse11:SignatureConfirmation element MUST occur before the signature that signs it.
1934 3. When an element in a security header is encrypted, the resulting xenc:EncryptedData element
1935 has the same order requirements as the source plain text element, unless requirement 4
1936 indicates otherwise. For example, an encrypted primary signature MUST occur before any
1937 supporting token signature per 2.c above and an encrypted token has the same ordering
1938 requirements as the unencrypted token.
1939 4. If there are any encrypted elements in the message then a top level xenc:ReferenceList element
1940 MUST be present in the security header. The xenc:ReferenceList MUST occur before any
1941 xenc:EncryptedData elements in the security header that are referenced from the reference list.
1942 However, the xenc:ReferenceList is not required to appear before independently encrypted
1943 tokens such as the xenc:EncryptedKey token as defined in WSS.
1944 5. An xenc:EncryptedKey element without an internal reference list [WSS: SOAP Message Security
1945 1.1] MUST obey rule 1 above.

19467 Security Binding Assertions
1947The appropriate representation of the different facets of security mechanisms requires distilling the
1948common primitives (to enable reuse) and then combining the primitive elements into patterns. The policy
1949scope of assertions defined in this section is the policy scope of their containing element.
19507.1 AlgorithmSuite Assertion

1951This assertion indicates a requirement for an algorithm suite as defined under the [Algorithm Suite]
1952property described in Section 6.1. The scope of this assertion is defined by its containing assertion.
1953Syntax
1954 <sp:AlgorithmSuite xmlns:sp="..." ... >
1956 (<sp:Basic256 ... /> |
1957 <sp:Basic192 ... /> |
1958 <sp:Basic128 ... /> |
1959 <sp:TripleDes ... /> |
1960 <sp:Basic256Rsa15 ... /> |
1961 <sp:Basic192Rsa15 ... /> |
1962 <sp:Basic128Rsa15 ... /> |
1963 <sp:TripleDesRsa15 ... /> |
1964 <sp:Basic256Sha256 ... /> |
1965 <sp:Basic192Sha256 ... /> |
1966 <sp:Basic128Sha256 ... /> |
1967 <sp:TripleDesSha256 ... /> |
1968 <sp:Basic256Sha256Rsa15 ... /> |
1969 <sp:Basic192Sha256Rsa15 ... /> |
1970 <sp:Basic128Sha256Rsa15 ... /> |
1971 <sp:TripleDesSha256Rsa15 ... /> |
1972 ...)
1973 <sp:InclusiveC14N ... /> ?
1974 <sp:SOAPNormalization10 ... /> ?
1975 <sp:STRTransform10 ... /> ?
1976 (<sp:XPath10 ... /> |
1977 <sp:XPathFilter20 ... /> |
1978 <sp:AbsXPath ... /> |
1979 ...)?
1980 ...
1981 </wsp:Policy>
1982 ...
1983 </sp:AlgorithmSuite>
1984
1986/sp:AlgorithmSuite
1987 This identifies an AlgorithmSuite assertion.
1988/sp:AlgorithmSuite/wsp:Policy
1989 This required element contains one or more policy assertions that indicate the specific algorithm
1990 suite to use.
1991/sp:AlgorithmSuite/wsp:Policy/sp:Basic256
1992 This optional element is a policy assertion that indicates that the [Algorithm Suite] property is set
1993 to 'Basic256'.

1996 to 'Basic192'.
1999 to 'Basic128'.
2000/sp:AlgorithmSuite/wsp:Policy/sp:TripleDes
2002 to 'TripleDes'.
2003/sp:AlgorithmSuite/wsp:Policy/sp:Basic256Rsa15
2005 to 'Basic256Rsa15'.
2012/sp:AlgorithmSuite/wsp:Policy/sp:TripleDesRsa15
2014 to 'TripleDesRsa15'.
2015/sp:AlgorithmSuite/wsp:Policy/sp:Basic256Sha256
2017 to 'Basic256Sha256'.
2024/sp:AlgorithmSuite/wsp:Policy/sp:TripleDesSha256
2026 to 'TripleDesSha256'.
2027/sp:AlgorithmSuite/wsp:Policy/sp:Basic256Sha256Rsa15
2029 to 'Basic256Sha256Rsa15'.

2036/sp:AlgorithmSuite/wsp:Policy/sp:TripleDesSha256Rsa15
2038 to 'TripleDesSha256Rsa15'.
2039/sp:AlgorithmSuite/wsp:Policy/sp:InclusiveC14N
2040 This optional element is a policy assertion that indicates that the [C14N] property of an algorithm
2041 suite is set to 'C14N'. Note: as indicated in Section 6.1 the default value of the [C14N] property is
2042 'ExcC14N'.
2043/sp:AlgorithmSuite/wsp:Policy/sp:SoapNormalization10
2044 This optional element is a policy assertion that indicates that the [SOAP Norm] property is set to
2045 'SNT'.
2046/sp:AlgorithmSuite/wsp:Policy/sp:STRTransform10
2047 This optional element is a policy assertion that indicates that the [STR Transform] property is set
2048 to 'STRT10'.
2049/sp:AlgorithmSuite/wsp:Policy/sp:XPath10
2050 This optional element is a policy assertion that indicates that the [XPath] property is set to 'XPath'.
2051/sp:AlgorithmSuite/wsp:Policy/sp:XPathFilter20
2052 This optional element is a policy assertion that indicates that the [XPath] property is set to
2053 'XPath20'.
2054/sp:AlgorithmSuite/wsp:Policy/sp:AbsXPath
2055 This optional element is a policy assertion that indicates that the [XPath] property is set to
2056 'AbsXPath' (see AbsoluteLocationPath in [XPATH]).
2057
20587.2 Layout Assertion

2059This assertion indicates a requirement for a particular security header layout as defined under the
2060[Security Header Layout] property described in Section 6.7. The scope of this assertion is defined by its
2061containing assertion.
2062Syntax
2063 <sp:Layout xmlns:sp="..." ... >
2065 <sp:Strict ... /> |
2066 <sp:Lax ... /> |
2067 <sp:LaxTsFirst ... /> |
2068 <sp:LaxTsLast ... /> |
2069 ...
2070 </wsp:Policy>
2071 ...
2072 </sp:Layout>
2073
2075/sp:Layout
2076 This identifies a Layout assertion.
2077/sp:Layout/wsp:Policy
2078 This required element contains one or more policy assertions that indicate the specific security
2079 header layout to use.
2080/sp:Layout/wsp:Policy/sp:Strict
2081 This optional element is a policy assertion that indicates that the [Security Header Layout]
2082 property is set to 'Strict'.
2083/sp:Layout/wsp:Policy/sp:Lax
2085 property is set to 'Lax'.
2086/sp:Layout/wsp:Policy/sp:LaxTsFirst
2088 property is set to 'LaxTimestampFirst'. Note that the [Timestamp] property MUST also be set to
2089 'true' by the presence of an sp:IncludeTimestamp assertion.
2090/sp:Layout/wsp:Policy/sp:LaxTsLast
2092 property is set to 'LaxTimestampLast'. Note that the [Timestamp] property MUST also be set to
2093 'true' by the presence of an sp:IncludeTimestamp assertion.
20947.3 TransportBinding Assertion

2095The TransportBinding assertion is used in scenarios in which message protection and security correlation
2096is provided by means other than WSS: SOAP Message Security, for example by a secure transport like
2097HTTPS. Specifically, this assertion indicates that the message is protected using the means provided by
2098the transport. This binding has one binding specific token property; [Transport Token]. This assertion
2099MUST apply to [Endpoint Policy Subject].
2100Syntax
2101 <sp:TransportBinding xmlns:sp="..." ... >
2103 <sp:TransportToken ... >
2105 ...
2106 </sp:TransportToken>
2107 <sp:AlgorithmSuite ... > ... </sp:AlgorithmSuite>
2108 <sp:Layout ... > ... </sp:Layout> ?
2109 <sp:IncludeTimestamp ... /> ?
2110 ...
2111 </wsp:Policy>
2112 ...
2113 </sp:TransportBinding>
2114
2116/sp:TransportBinding
2117 This identifies a TransportBinding assertion.
2118/sp:TransportBinding/wsp:Policy
2119 This indicates a nested wsp:Policy element that defines the behavior of the TransportBinding
2120 assertion.
2121/sp:TransportBinding/wsp:Policy/sp:TransportToken
2122 This required element is a policy assertion that indicates a requirement for a Transport Token.
2123 The specified token populates the [Transport Token] property and indicates how the transport is
2124 secured.
2125/sp:TransportBinding/wsp:Policy/sp:TransportToken/wsp:Policy
2126 This indicates a nested policy that identifies the type of Transport Token to use.
2127/sp:TransportBinding/wsp:Policy/sp:AlgorithmSuite
2128 This required element is a policy assertion that indicates a value that populates the [Algorithm
2129 Suite] property. See Section 6.1 for more details.
2130/sp:TransportBinding/wsp:Policy/sp:Layout
2131 This optional element is a policy assertion that indicates a value that populates the [Security
2132 Header Layout] property. See Section 6.7 for more details.
2133/sp:TransportBinding/wsp:Policy/sp:IncludeTimestamp
2134 This optional element is a policy assertion that indicates that the [Timestamp] property is set to
2135 'true'.
21367.4 SymmetricBinding Assertion

2137The SymmetricBinding assertion is used in scenarios in which message protection is provided by means
2138defined in WSS: SOAP Message Security. This binding has two binding specific token properties;
2139[Encryption Token] and [Signature Token]. If the message pattern requires multiple messages, this
2140binding defines that the [Encryption Token] used from initiator to recipient is also used from recipient to
2141initiator. Similarly, the [Signature Token] used from initiator to recipient is also use from recipient to
2142initiator. If a sp:ProtectionToken assertion is specified, the specified token populates both token properties
2143and is used as the basis for both encryption and signature in both directions. This assertion SHOULD
2144apply to [Endpoint Policy Subject]. This assertion MAY apply to [Operation Policy Subject].
2145Syntax
2146 <sp:SymmetricBinding xmlns:sp="..." ... >
2148 (
2149 <sp:EncryptionToken ... >
2151 </sp:EncryptionToken>
2152 <sp:SignatureToken ... >
2154 </sp:SignatureToken>
2155 ) | (
2156 <sp:ProtectionToken ... >
2159 )
2163 <sp:EncryptBeforeSigning ... /> ?
2164 <sp:EncryptSignature ... /> ?
2165 <sp:ProtectTokens ... /> ?
2166 <sp:OnlySignEntireHeadersAndBody ... /> ?
2167 ...
2168 </wsp:Policy>
2169 ...
2171
2173/sp:SymmetricBinding
2174 This identifies a SymmetricBinding assertion.

2175/sp:SymmetricBinding/wsp:Policy
2176 This indicates a nested wsp:Policy element that defines the behavior of the SymmetricBinding
2177 assertion.
2178/sp:SymmetricBinding/wsp:Policy/sp:EncryptionToken
2179 This optional element is a policy assertion that indicates a requirement for an Encryption Token.
2180 The specified token populates the [Encryption Token] property and is used for encryption. It is an
2181 error for both an sp:EncryptionToken and an sp:ProtectionToken assertion to be specified.
2182/sp:SymmetricBinding/wsp:Policy/sp:EncryptionToken/wsp:Policy
2183 The policy contained here MUST identify exactly one token to use for encryption.
2184/sp:SymmetricBinding/wsp:Policy/sp:SignatureToken
2185 This optional element is a policy assertion that indicates a requirement for a Signature Token.
2186 The specified token populates the [Signature Token] property and is used for the message
2187 signature. It is an error for both an sp:SignatureToken and an sp:ProtectionToken assertion to be
2188 specified.
2189/sp:SymmetricBinding/wsp:Policy/sp:SignatureToken/wsp:Policy
2190 The policy contained here MUST identify exactly one token to use for signatures.
2191/sp:SymmetricBinding/wsp:Policy/sp:ProtectionToken
2192 This optional element is a policy assertion that indicates a requirement for a Protection Token.
2193 The specified token populates the [Encryption Token] and [Signature Token properties] and is
2194 used for the message signature and for encryption. It is an error for both an sp:ProtectionToken
2195 assertion and either an sp:EncryptionToken assertion or an sp:SignatureToken assertion to be
2196 specified.
2197/sp:SymmetricBinding/wsp:Policy/sp:ProtectionToken/wsp:Policy
2198 The policy contained here MUST identify exactly one token to use for protection.
2199/sp:SymmetricBinding/wsp:Policy/sp:AlgorithmSuite
2202/sp:SymmetricBinding/wsp:Policy/sp:Layout
2205/sp:SymmetricBinding/wsp:Policy/sp:IncludeTimestamp
2207 'true'.
2208/sp:SymmetricBinding/wsp:Policy/sp:EncryptBeforeSigning
2209 This optional element is a policy assertion that indicates that the [Protection Order] property is set
2210 to 'EncryptBeforeSigning'.
2211/sp:SymmetricBinding/wsp:Policy/sp:EncryptSignature
2212 This optional element is a policy assertion that indicates that the [Signature Protection] property is
2213 set to 'true'.
2214/sp:SymmetricBinding/wsp:Policy/sp:ProtectTokens
2215 This optional element is a policy assertion that indicates that the [Token Protection] property is
2216 set to 'true'.
2217/sp:SymmetricBinding/wsp:Policy/sp:OnlySignEntireHeadersAndBody
2218 This optional element is a policy assertion that indicates that the [Entire Header And Body
2219 Signatures] property is set to 'true'.
22207.5 AsymmetricBinding Assertion

2221The AsymmetricBinding assertion is used in scenarios in which message protection is provided by means
2222defined in WSS: SOAP Message Security using asymmetric key (Public Key) technology. Commonly
2223used asymmetric algorithms, such as RSA, allow the same key pair to be used for both encryption and
2224signature. However it is also common practice to use distinct keys for encryption and signature, because
2225of their different lifecycles.
2226
2227This binding enables either of these practices by means of four binding specific token properties: [Initiator
2228Signature Token], [Initiator Encryption Token], [Recipient Signature Token] and [Recipient Encryption
2229Token].
2230
2231If the same key pair is used for signature and encryption, then [Initiator Signature Token] and [Initiator
2232Encryption Token] will both refer to the same token. Likewise [Recipient Signature Token] and [Recipient
2233Encryption Token] will both refer to the same token.
2234
2235If distinct key pairs are used for signature and encryption then [Initiator Signature Token] and [Initiator
2236Encryption Token] will refer to different tokens. Likewise [Recipient Signature Token] and [Recipient
2237Encryption Token] will refer to different tokens.
2238
2239If the message pattern requires multiple messages, the [Initiator Signature Token] is used for the
2240message signature from initiator to the recipient. The [Initiator Encryption Token] is used for the response
2241message encryption from recipient to the initiator. The [Recipient Signature Token] is used for the
2242response message signature from recipient to the initiator. The [Recipient Encryption Token] is used for
2243the message encryption from initiator to the recipient. Note that in each case, the token is associated with
2244the party (initiator or recipient) who knows the secret.
2245This assertion SHOULD apply to [Endpoint Policy Subject]. This assertion MAY apply to [Operation Policy
2246Subject].
2247Syntax
2248 <sp:AsymmetricBinding xmlns:sp="..." ... >
2250 (
2254 ) | (
2255 <sp:InitiatorSignatureToken>
2257 </sp:InitiatorSignatureToken>
2258 <sp:InitiatorEncryptionToken>
2260 </sp:InitiatorEncryptionToken>
2261 )
2262 (
2266 ) | (

2267 <sp:RecipientSignatureToken>
2269 </sp:RecipientSignatureToken>
2270 <sp:RecipientEncryptionToken>
2272 </sp:RecipientEncryptionToken>
2273 )
2277 <sp:EncryptBeforeSigning ... /> ?
2278 <sp:EncryptSignature ... /> ?
2279 <sp:ProtectTokens ... /> ?
2280 <sp:OnlySignEntireHeadersAndBody ... /> ?
2281 ...
2282 </wsp:Policy>
2283 ...
2285
2287/sp:AsymmetricBinding
2288 This identifies a AsymmetricBinding assertion.
2289/sp:AsymmetricBinding/wsp:Policy
2290 This indicates a nested wsp:Policy element that defines the behavior of the AsymmetricBinding
2291 assertion.
2292/sp:AsymmetricBinding/wsp:Policy/sp:InitiatorToken
2293 This optional element is a policy assertion that indicates a requirement for an Initiator Token. The
2294 specified token populates the [Initiator Signature Token] and [Initiator Encryption Token]
2295 properties and is used for the message signature from initiator to recipient, and encryption from
2296 recipient to initiator.
2297/sp:AsymmetricBinding/wsp:Policy/sp:InitiatorToken/wsp:Policy
2298 The policy contained here MUST identify one or more token assertions.
2299/sp:AsymmetricBinding/wsp:Policy/sp:InitiatorToken/wsp:Policy/sp:InitiatorSignatureToken
2300 This optional element is a policy assertion that indicates a requirement for an Initiator Signature
2301 Token. The specified token populates the [Initiator Signature Token] property and is used for the
2302 message signature from initiator to recipient.
2303/sp:AsymmetricBinding/wsp:Policy/sp:InitiatorToken/wsp:Policy/sp:InitiatorSignatureToken/wsp:Policy
2305/sp:AsymmetricBinding/wsp:Policy/sp:InitiatorToken/wsp:Policy/sp:InitiatorEncryptionToken
2306 This optional element is a policy assertion that indicates a requirement for an Initiator Encryption
2307 Token. The specified token populates the [Initiator Encryption Token] property and is used for the
2308 message encryption from recipient to initiator.
2309/sp:AsymmetricBinding/wsp:Policy/sp:InitiatorToken/wsp:Policy/sp:InitiatorEncryptionToken/wsp:Policy
2311/sp:AsymmetricBinding/wsp:Policy/sp:RecipientToken
2312 This optional element is a policy assertion that indicates a requirement for a Recipient Token. The
2313 specified token populates the [Recipient Signature Token] and [Recipient Encryption Token]

2314 property and is used for encryption from initiator to recipient, and for the message signature from
2315 recipient to initiator.
2316/sp:AsymmetricBinding/wsp:Policy/sp:RecipientToken/wsp:Policy
2318/sp:AsymmetricBinding/wsp:Policy/sp:RecipientToken/wsp:Policy/sp:RecipientSignatureToken
2319 This optional element is a policy assertion that indicates a requirement for a Recipient Signature
2320 Token. The specified token populates the [Recipient Signature Token] property and is used for
2321 the message signature from Recipient to recipient.
2322/sp:AsymmetricBinding/wsp:Policy/sp:RecipientToken/wsp:Policy/sp:RecipientSignatureToken/wsp:Policy
2324/sp:AsymmetricBinding/wsp:Policy/sp:RecipientToken/wsp:Policy/sp:RecipientEncryptionToken
2325 This optional element is a policy assertion that indicates a requirement for a Recipient Encryption
2326 Token. The specified token populates the [Recipient Encryption Token] property and is used for
2327 the message encryption from recipient to Recipient.
2328/sp:AsymmetricBinding/wsp:Policy/sp:RecipientToken/wsp:Policy/sp:RecipientEncryptionToken/wsp:Policy
2330/sp:AsymmetricBinding/wsp:Policy/sp:AlgorithmSuite
2333/sp:AsymmetricBinding/wsp:Policy/sp:Layout
2336/sp:AsymmetricBinding/wsp:Policy/sp:IncludeTimestamp
2338 'true'.
2339/sp:AsymmetricBinding/wsp:Policy/sp:EncryptBeforeSigning
2340 This optional element is a policy assertion that indicates that the [Protection Order] property is set
2341 to 'EncryptBeforeSigning'.
2342/sp:AsymmetricBinding/wsp:Policy/sp:EncryptSignature
2343 This optional element is a policy assertion that indicates that the [Signature Protection] property is
2344 set to 'true'.
2345/sp:AsymmetricBinding/wsp:Policy/sp:ProtectTokens
2346 This optional element is a policy assertion that indicates that the [Token Protection] property is
2347 set to 'true'.
2348/sp:AsymmetricBinding/wsp:Policy/sp:OnlySignEntireHeadersAndBody
2349 This optional element is a policy assertion that indicates that the [Entire Header And Body
2350 Signatures] property is set to 'true'.

23518 Supporting Tokens
2352Security Bindings use tokens to secure the message exchange. The Security Binding will require one to
2353create a signature using the token identified in the Security Binding policy. This signature will here-to-fore
2354be referred to as the “message signature”. In case of Transport Binding the message is signed outside of
2355the message XML by the underlying transport protocol and the signature itself is not part of the message.
2356Additional tokens may be specified to augment the claims provided by the token associated with the
2357“message signature” provided by the Security Binding. This section defines seven properties related to
2358supporting token requirements which may be referenced by a Security Binding: [Supporting Tokens],
2359[Signed Supporting Tokens], [Endorsing Supporting Tokens], [Signed Endorsing Supporting Tokens],
2360[Signed Encrypted Supporting Tokens], [Endorsing Encrypted Supporting Tokens] and [Signed Endorsing
2361Encrypted Supporting Tokens]. Seven assertions are defined to populate those properties:
2362SupportingTokens, SignedSupportingTokens, EndorsingSupportingTokens,
2363SignedEndorsingSupportingTokens, SignedEncryptedSupportingTokens,
2364EndorsingEncryptedSupportingTokens and SignedEndorsingEncryptedSupportingTokens. These
2365assertions SHOULD apply to [Endpoint Policy Subject]. These assertions MAY apply to [Message Policy
2366Subject] or [Operation Policy Subject].
2367
2368Supporting tokens may be specified at a different scope than the binding assertion which provides
2369support for securing the exchange. For instance, a binding is specified at the scope of an endpoint, while
2370the supporting tokens might be defined at the scope of a message. When assertions that populate this
2371property are defined in overlapping scopes, the sender should merge the requirements by including all
2372tokens from the outer scope and any additional tokens for a specific message from the inner scope.
2373
2374In cases where multiple tokens are specified that sign and/or encrypt overlapping message parts, all the
2375tokens should sign and encrypt the various message parts. In such cases ordering of elements (tokens,
2376signatures, reference lists etc.) in the security header would be used to determine which order signature
2377and encryptions occurred in.
2378
2379Policy authors need to ensure that the tokens they specify as supporting tokens can satisfy any additional
2380constraints defined by the supporting token assertion. For example, if the supporting token assertion
2381specifies message parts that need to be encrypted, the specified tokens need to be capable of encryption.
2382
2383To illustrate the different ways that supporting tokens may be bound to the message, let’s consider a
2384message with three components: Header1, Header2, and Body.
2385
Header1
Header2
Body
2386

2387Even before any supporting tokens are added, each binding requires that the message is signed using a
2388token satisfying the required usage for that binding, and that the signature (Sig1) covers important parts
2389of the message including the message timestamp (TS) facilitate replay detection. The signature is then
2390included as part of the Security header as illustrated below:
2391
Header1
Header2
Security
TS
Sig1
Body
2392
2393Note: if required, the initiator may also include in the Security header the token used as the basis for the
2394message signature (Sig1), not shown in the diagram.
2395If transport security is used, only the message timestamp (TS) is included in the Security header as
2396illustrated below. The “message signature” is provided by the underlying transport protocol and is not part
2397of the message XML.
Header1
Header2
Security
TS
Body
2398
23998.1 SupportingTokens Assertion

2400Supporting tokens are included in the security header and may optionally include additional message
2401parts to sign and/or encrypt. The supporting tokens can be added to any SOAP message and do not
2402require any protection (signature or encryption) to be applied to the message before they are added. More
2403specifically there is no requirement on “message signature” being present before the supporting tokens
2404are added. However it is RECOMMENDED to employ underlying protection mechanism to ensure that the
2405supporting tokens are cryptographically bound to the message during the transmission.
2406Syntax
2407 <sp:SupportingTokens xmlns:sp="..." ... >
2409 [Token Assertion]+
2410 <sp:AlgorithmSuite ... > ... </sp:AlgorithmSuite> ?
2411 (
2412 <sp:SignedParts ... > ... </sp:SignedParts> |

2413 <sp:SignedElements ... > ... </sp:SignedElements> |
2414 <sp:EncryptedParts ... > ... </sp:EncryptedParts> |
2415 <sp:EncryptedElements ... > ... </sp:EncryptedElements> |
2416 ) *
2417 ...
2418 </wsp:Policy>
2419 ...
2420 </sp:SupportingTokens>
2421
2423/sp:SupportingTokens
2424 This identifies a SupportingTokens assertion. The specified tokens populate the [Supporting
2425 Tokens] property.
2426/sp:SupportingTokens/wsp:Policy
2427 This describes additional requirements for satisfying the SupportingTokens assertion.
2428/sp:SupportingTokens/wsp:Policy/[Token Assertion]
2429 The policy MUST identify one or more token assertions.
2430/sp:SupportingTokens/wsp:Policy/sp:AlgorithmSuite
2431 This optional element is a policy assertion that follows the schema outlined in Section 7.1 and
2432 describes the algorithms to use for cryptographic operations performed with the tokens identified
2433 by this policy assertion.
2434/sp:SupportingTokens/wsp:Policy/sp:SignedParts
2435 This optional element is a policy assertion that follows the schema outlined in Section 4.1.1 and
2436 describes additional message parts that MUST be included in the signature generated with the
2437 token identified by this policy assertion.
2438/sp:SupportingTokens/wsp:Policy/sp:SignedElements
2440 describes additional message elements that MUST be included in the signature generated with
2441 the token identified by this policy assertion.
2442/sp:SupportingTokens/wsp:Policy/sp:EncryptedParts
2444 describes additional message parts that MUST be encrypted using the token identified by this
2445 policy assertion.
2446/sp:SupportingTokens/wsp:Policy/sp:EncryptedElements
2448 describes additional message elements that MUST be encrypted using the token identified by this
24508.2 SignedSupportingTokens Assertion

2451Signed tokens are included in the “message signature” as defined above and may optionally include
2452additional message parts to sign and/or encrypt. The diagram below illustrates how the attached token
2453(Tok2) is signed by the message signature (Sig1):
2454

Header1
Header2
Security
TS
Tok2
Sig1
Body
2455
2456If transport security is used, the token (Tok2) is included in the Security header as illustrated below:
2457
Header1
Header2
Security
TS
Tok2
Body
2458
2459Syntax
2460 <sp:SignedSupportingTokens xmlns:sp="..." ... >
2464 (
2468 <sp:EncryptedElements ... > ... </sp:EncryptedElements>
2469 ) *
2470 ...
2471 </wsp:Policy>
2472 ...
2473 </sp:SignedSupportingTokens>
2474
2476/sp:SignedSupportingTokens
2477 This identifies a SignedSupportingTokens assertion. The specified tokens populate the [Signed
2478 Supporting Tokens] property.
2479/sp:SignedSupportingTokens/wsp:Policy
2480 This describes additional requirements for satisfying the SignedSupportingTokens assertion.
2481/sp:SignedSupportingTokens/wsp:Policy/[Token Assertion]
2483/sp:SignedSupportingTokens/wsp:Policy/sp:AlgorithmSuite
2487/sp:SignedSupportingTokens/wsp:Policy/sp:SignedParts
2491/sp:SignedSupportingTokens/wsp:Policy/sp:SignedElements
2495/sp:SignedSupportingTokens/wsp:Policy/sp:EncryptedParts
2499/sp:SignedSupportingTokens/wsp:Policy/sp:EncryptedElements
25038.3 EndorsingSupportingTokens Assertion

2504Endorsing tokens sign the message signature, that is they sign the entire ds:Signature element
2505produced from the message signature and may optionally include additional message parts to sign and/or
2506encrypt. The diagram below illustrates how the endorsing signature (Sig2) signs the message signature
2507(Sig1):
2508
Header1
Header2
Security
TS
Sig1
Sig2
Body
2509
2510If transport security is used, the signature (Sig2) MUST cover the message timestamp as illustrated
2511below:
2512
Header1
Header2
Security
TS
Sig2
Body
2513
2514Syntax
2515 <sp:EndorsingSupportingTokens xmlns:sp="..." ... >
2519 (
2524 ) *
2525 ...
2526 </wsp:Policy>
2527 ...
2528 </sp:EndorsingSupportingTokens>
2529
2531/sp:EndorsingSupportingTokens
2532 This identifies an EndorsingSupportingTokens assertion. The specified tokens populate the
2533 [Endorsing Supporting Tokens] property.
2534/sp:EndorsingSupportingTokens/wsp:Policy
2535 This describes additional requirements for satisfying the EndorsingSupportingTokens assertion.
2536/sp:EndorsingSupportingTokens/wsp:Policy/[Token Assertion]
2538/sp:EndorsingSupportingTokens/wsp:Policy/sp:AlgorithmSuite
2542/sp:EndorsingSupportingTokens/wsp:Policy/sp:SignedParts
2546/sp:EndorsingSupportingTokens/wsp:Policy/sp:SignedElements

2550/sp:EndorsingSupportingTokens/wsp:Policy/sp:EncryptedParts
2554/sp:EndorsingSupportingTokens/wsp:Policy/sp:EncryptedElements
25588.4 SignedEndorsingSupportingTokens Assertion

2559Signed endorsing tokens sign the entire ds:Signature element produced from the message signature
2560and are themselves signed by that message signature, that is both tokens (the token used for the
2561message signature and the signed endorsing token) sign each other. This assertion may optionally
2562include additional message parts to sign and/or encrypt. The diagram below illustrates how the signed
2563token (Tok2) is signed by the message signature (Sig1) and the endorsing signature (Sig2) signs the
2564message signature (Sig1):
2565
Header1
Header2
Security
TS
Tok2
Sig1
Sig2
Body
2566
2567If transport security is used, the token (Tok2) is included in the Security header and the signature (Sig2)
2568should cover the message timestamp as illustrated below:
2569

Header1
Header2
Security
TS
Tok2
Sig2
Body
2570
2571Syntax
2572 <sp:SignedEndorsingSupportingTokens xmlns:sp="..." ... >
2576 (
2581 ) *
2582 ...
2583 </wsp:Policy>
2584 ...
2585 </sp:SignedEndorsingSupportingTokens>
2586
2588/sp:SignedEndorsingSupportingTokens
2589 This identifies a SignedEndorsingSupportingTokens assertion. The specified tokens populate the
2590 [Signed Endorsing Supporting Tokens] property.
2591/sp:SignedEndorsingSupportingTokens/wsp:Policy
2592 This describes additional requirements for satisfying the EndorsingSupportingTokens assertion.
2593/sp:SignedEndorsingSupportingTokens/wsp:Policy/[Token Assertion]
2595/sp:SignedEndorsingSupportingTokens/wsp:Policy/sp:AlgorithmSuite
2599/sp:SignedEndorsingSupportingTokens/wsp:Policy/sp:SignedParts
2603/sp:SignedEndorsingSupportingTokens/wsp:Policy/sp:SignedElements

2604 This optional element follows the schema outlined in Section 4.1.2 and describes additional
2605 message elements that MUST be included in the signature generated with the token identified by
2606 this policy assertion.
2607/sp:SignedEndorsingSupportingTokens/wsp:Policy/sp:EncryptedParts
2611/sp:SignedEndorsingSupportingTokens/wsp:Policy/sp:EncryptedElements
26158.5 SignedEncryptedSupportingTokens Assertion

2616Signed, encrypted supporting tokens are Signed supporting tokens (See section 8.2) that are also
2617encrypted when they appear in the wsse:SecurityHeader. Element Encryption SHOULD be used for
2618encrypting the supporting tokens.
2619The syntax for the sp:SignedEncryptedSupportingTokens differs from the syntax of
2620sp:SignedSupportingTokens only in the name of the assertion itself. All nested policy is as per the
2621sp:SignedSupportingTokens assertion.
26228.6 EncryptedSupportingTokens Assertion

2623Encrypted supporting tokens are supporting tokens (See section 8.1) that are included in
2624the security header and MUST be encrypted when they appear in the security header.
2625Element encryption SHOULD be used for encrypting these tokens. The encrypted supporting
2626tokens can be added to any SOAP message and do not require the “message signature”
2627being present before the encrypted supporting tokens are added.
2628The syntax for the sp:EncryptedSupportingTokens differs from the syntax of
2629sp:SupportingTokens only in the name of the assertion itself. All nested policy is as per the
2630sp:SupportingTokens assertion.
2631The encrypted supporting tokens SHOULD be used only when the sender cannot provide the
2632“message signature” and it is RECOMMENDED that the receiver employs some security
2633mechanisms external to the message to prevent the spoofing attacks. In all other cases it is
2634RECOMMENDED to use signed encrypted supporting tokens instead to ensure that the
2635encrypted tokens are cryptographically bound to the message (See section 8.5).
26368.7 EndorsingEncryptedSupportingTokens Assertion

2637Endorsing, encrypted supporting tokens are Endorsing supporting tokens (See section 8.3) that are also
2638encrypted when they appear in the wsse:SecurityHeader. Element Encryption SHOULD be used for
2639encrypting the supporting tokens.
2640The syntax for the sp:EndorsingEncryptedSupportingTokens differs from the syntax of
2641sp:EndorsingSupportingTokens only in the name of the assertion itself. All nested policy is as per the
2642sp:EndorsingSupportingTokens assertion.

26438.8 SignedEndorsingEncryptedSupportingTokens Assertion
2644Signed, endorsing, encrypted supporting tokens are signed, endorsing supporting tokens (See section
26458.4) that are also encrypted when they appear in the wsse:SecurityHeader. Element Encryption SHOULD
2646be used for encrypting the supporting tokens.
2647The syntax for the sp:SignedEndorsingEncryptedSupportingTokens differs from the syntax of
2648sp:SignedEndorsingSupportingTokens only in the name of the assertion itself. All nested policy is as per
2649the sp:SignedEndorsingSupportingTokens assertion.
26508.9 Interaction between [Token Protection] property and supporting

2651 token assertions
2652If [Token Protection] (see Section 6.5) is true, then each signature covers the token that generated that
2653signature and the following statements hold with respect to the various tokens that sign or are signed;
2654  The message signature, generated from the [Initiator Token] in the Asymmetric Binding case or
2655 the [Signature Token] in the Symmetric binding case, covers that token.
2656  Endorsing signatures cover the main signature and the endorsing token.
2657  For signed, endorsing supporting tokens, the supporting token is signed twice, once by the
2658 message signature and once by the endorsing signature.
2659In addition, signed supporting tokens are covered by the message signature, although this is independent
2660of [Token Protection].
26618.10 Example
2662Example policy containing supporting token assertions:
2663 
2665 <sp:SymmetricBinding xmlns:sp="...">
2666 <wsp:Policy>
2668 <sp:IssuedToken sp:IncludeToken=".../IncludeToken/Once" >
2669 <sp:Issuer>...</sp:Issuer>
2670 <sp:RequestSecurityTokenTemplate>
2671 ...
2675 <sp:AlgorithmSuite>
2676 <wsp:Policy>
2677 <sp:Basic256 />
2678 </wsp:Policy>
2680 ...
2681 </wsp:Policy>
2683 ...
2684 <sp:SignedSupportingTokens>
2685 <wsp:Policy>
2686 <sp:UsernameToken sp:IncludeToken=".../IncludeToken/Once" />
2687 </wsp:Policy>
2689 <sp:SignedEndorsingSupportingTokens>
2690 <wsp:Policy>
2691 <sp:X509Token sp:IncludeToken=".../IncludeToken/Once" >
2692 <wsp:Policy>

2693 <sp:WssX509v3Token10 />
2694 </wsp:Policy>
2696 </wsp:Policy>
2698 ...
2699 </wsp:Policy>
2700The sp:SignedSupportingTokens assertion in the above policy indicates that a Username Token must be
2701included in the security header and covered by the message signature. The
2702sp:SignedEndorsingSupportingTokens assertion indicates that an X509 certificate must be included in the
2703security header and covered by the message signature. In addition, a signature over the message
2704signature based on the key material associated with the X509 certificate must be included in the security
2705header.

27069 WSS: SOAP Message Security Options
2707There are several optional aspects to the WSS: SOAP Message Security specification that are
2708independent of the trust and token taxonomies. This section describes another class of properties and
2709associated assertions that indicate the supported aspects of WSS: SOAP Message Security. The
2710assertions defined here MUST apply to [Endpoint Policy Subject].
2711The properties and assertions dealing with token references defined in this section indicate whether the
2712initiator and recipient MUST be able to process a given reference mechanism, or whether the initiator and
2713recipient MAY send a fault if such references are encountered.
2714
2715Note: This approach is chosen because:
2716 A) [WSS: SOAP Message Security] allows for multiple equivalent reference mechanisms to be used
2717 in a single reference.
2718 B) In a multi-message exchange, a token may be referenced using different mechanisms depending
2719 on which of a series of messages is being secured.
2720
2721If a message sent to a recipient does not adhere to the recipient’s policy the recipient MAY raise a
2722wsse:InvalidSecurity fault.
2723
2724WSS: SOAP Message Security 1.0 Properties
2725[Direct References]
2726This property indicates whether the initiator and recipient MUST be able to process direct token
2727references (by ID or URI reference). This property always has a value of 'true'. i.e. All implementations
2728MUST be able to process such references.
2729
2730[Key Identifier References]
2731This boolean property indicates whether the initiator and recipient MUST be able to process key-specific
2732identifier token references. A value of 'true' indicates that the initiator and recipient MUST be able to
2733generate and process such references. A value of 'false' indicates that the initiator and recipient MUST
2734NOT generate such references and that the initiator and recipient MAY send a fault if such references are
2735encountered. This property has a default value of 'false'.
2736
2737[Issuer Serial References]
2738This boolean property indicates whether the initiator and recipient MUST be able to process references
2739using the issuer and token serial number. A value of 'true' indicates that the initiator and recipient MUST
2740be able to process such references. A value of 'false' indicates that the initiator and recipient MUST NOT
2741generate such references and that the initiator and recipient MAY send a fault if such references are
2743
2744[External URI References]
2745This boolean property indicates whether the initiator and recipient MUST be able to process references to
2746tokens outside the message using URIs. A value of 'true' indicates that the initiator and recipient MUST

2747be able to process such references. A value of 'false' indicates that the initiator and recipient MUST NOT
2748generate such references and that the initiator and recipient MAY send a fault if such references are
2750[Embedded Token References]
2752that contain embedded tokens. A value of 'true' indicates that the initiator and recipient MUST be able to
2753process such references. A value of 'false' indicates that the initiator and recipient MUST NOT generate
2754such references and that the initiator and recipient MAY send a fault if such references are encountered.
2755This property has a default value of 'false'.
2756
2757WSS: SOAP Message Security 1.1 Properties
2758[Thumbprint References]
2760using token thumbprints. A value of 'true' indicates that the initiator and recipient MUST be able to
2764
2765[EncryptedKey References]
2767using EncryptedKey references. A value of 'true' indicates that the initiator and recipient MUST be able to
2771
2772[Signature Confirmation]
2773This boolean property specifies whether wsse11:SignatureConfirmation elements should be used
2774as defined in WSS: Soap Message Security 1.1. If the value is 'true',
2775wsse11:SignatureConfirmation elements MUST be used and signed by the message signature. If
2776the value is 'false', signature confirmation elements MUST NOT be used. The value of this property
2777applies to all signatures that are included in the security header. This property has a default value of
2778'false'.
27799.1 Wss10 Assertion

2780The Wss10 assertion allows you to specify which WSS: SOAP Message Security 1.0 options are
2781supported.
2782Syntax
2783 <sp:Wss10 xmlns:sp="..." ... >
2785 <sp:MustSupportRefKeyIdentifier ... /> ?
2786 <sp:MustSupportRefIssuerSerial ... /> ?
2787 <sp:MustSupportRefExternalURI ... /> ?
2788 <sp:MustSupportRefEmbeddedToken ... /> ?
2789 ...
2790 </wsp:Policy>
2791 ...
2792 </sp:Wss10>

2793
2795/sp:Wss10
2796 This identifies a WSS10 assertion.
2797/sp:Wss10/wsp:Policy
2798 This indicates a policy that controls WSS: SOAP Message Security 1.0 options.
2799/sp:Wss10/wsp:Policy/sp:MustSupportRefKeyIdentifier
2800 This optional element is a policy assertion indicates that the [Key Identifier References] property
2801 is set to 'true'.
2802/sp:Wss10/wsp:Policy/sp:MustSupportRefIssuerSerial
2803 This optional element is a policy assertion indicates that the [Issuer Serial References] property is
2804 set to 'true'.
2805/sp:Wss10/wsp:Policy/sp:MustSupportRefExternalURI
2806 This optional element is a policy assertion indicates that the [External URI References] property is
2807 set to 'true'.
2808/sp:Wss10/wsp:Policy/sp:MustSupportRefEmbeddedToken
2809 This optional element is a policy assertion indicates that the [Embedded Token References]
2810 property is set to 'true'.
28119.2 Wss11 Assertion

2812The Wss11 assertion allows you to specify which WSS: SOAP Message Security 1.1 options are
2813supported.
2814Syntax
2815 <sp:Wss11 xmlns:sp="..." ... >
2817 <sp:MustSupportRefKeyIdentifier ... /> ?
2818 <sp:MustSupportRefIssuerSerial ... /> ?
2819 <sp:MustSupportRefExternalURI ... /> ?
2820 <sp:MustSupportRefEmbeddedToken ... /> ?
2821 <sp:MustSupportRefThumbprint ... /> ?
2822 <sp:MustSupportRefEncryptedKey ... /> ?
2823 <sp:RequireSignatureConfirmation ... /> ?
2824 ...
2825 </wsp:Policy>
2826 </sp:Wss11>
2827
2829/sp:Wss11
2830 This identifies an WSS11 assertion.
2831/sp:Wss11/wsp:Policy
2832 This indicates a policy that controls WSS: SOAP Message Security 1.1 options.
2833/sp:Wss11/wsp:Policy/sp:MustSupportRefKeyIdentifier
2834 This optional element is a policy assertion indicates that the [Key Identifier References] property

2836/sp:Wss11/wsp:Policy/sp:MustSupportRefIssuerSerial
2837 This optional element is a policy assertion indicates that the [Issuer Serial References] property is
2838 set to 'true'.
2839/sp:Wss11/wsp:Policy/sp:MustSupportRefExternalURI
2840 This optional element is a policy assertion indicates that the [External URI References] property is
2841 set to 'true'.
2842/sp:Wss11/wsp:Policy/sp:MustSupportRefEmbeddedToken
2843 This optional element is a policy assertion indicates that the [Embedded Token References]
2844 property is set to 'true'.
2845/sp:Wss11/wsp:Policy/sp:MustSupportRefThumbprint
2846 This optional element is a policy assertion indicates that the [Thumbprint References] property is
2847 set to 'true'.
2848/sp:Wss11/wsp:Policy/sp:MustSupportRefEncryptedKey
2849 This optional element is a policy assertion indicates that the [EncryptedKey References] property
2851/sp:Wss11/wsp:Policy/sp:RequireSignatureConfirmation
2852 This optional element is a policy assertion indicates that the [Signature Confirmation] property is
2853 set to 'true'.

285410 WS-Trust Options
2855This section defines the various policy assertions related to exchanges based on WS-Trust, specifically
2856with client and server challenges and entropy behaviors. These assertions relate to interactions with a
2857Security Token Service and may augment the behaviors defined by the Binding Property Assertions
2858defined in Section 6. The assertions defined here MUST apply to [Endpoint Policy Subject].
2859
2860WS-Trust 1.3 Properties
2861[Client Challenge]
2862This boolean property indicates whether client challenges are supported. A value of 'true' indicates that a
2863wst:SignChallenge element is supported inside of an RST sent by the client to the server. A value of
2864'false' indicates that a wst:SignChallenge is not supported. There is no change in the number of
2865messages exchanged by the client and service in satisfying the RST. This property has a default value of
2866'false'.
2867
2868[Server Challenge]
2869This boolean property indicates whether server challenges are supported. A value of 'true' indicates that a
2870wst:SignChallenge element is supported inside of an RSTR sent by the server to the client. A value of
2871'false' indicates that a wst:SignChallenge is not supported. A challenge issued by the server may
2872increase the number of messages exchanged by the client and service in order to accommodate the
2873wst:SignChallengeResponse element sent by the client to the server in response to the
2874wst:SignChallenge element. A final RSTR containing the issued token will follow subsequent to the
2875server receiving the wst:SignChallengeResponse element. This property has a default value of 'false'.
2876
2877[Client Entropy]
2878This boolean property indicates whether client entropy is required to be used as key material for a
2879requested proof token. A value of 'true' indicates that client entropy is required. A value of 'false' indicates
2880that client entropy is not required. This property has a default value of 'false'.
2881
2882[Server Entropy]
2883This boolean property indicates whether server entropy is required to be used as key material for a
2884requested proof token. A value of 'true' indicates that server entropy is required. A value of 'false'
2885indicates that server entropy is not required. This property has a default value of 'false'.
2886Note: If both the [Client Entropy] and [Server Entropy] properties are set to true, Client and server entropy
2887are combined to produce a computed key using the Computed Key algorithm defined by the [Algorithm
2888Suite] property.
2889
2890[Issued Tokens]
2891This boolean property indicates whether the wst:IssuedTokens header is supported as described in
2892WS-Trust. A value of 'true' indicates that the wst:IssuedTokens header is supported. A value of 'false'
2893indicates that the wst:IssuedTokens header is not supported. This property has a default value of
2894'false'.
2895[Collection]
2896This boolean property specifies whether a wst:RequestSecurityTokenCollection element is present. A
2897value of 'true' indicates that the wst:RequestSecurityTokenCollection element MUST be present and
2898MUST be integrity protected either by transport or message level security. A value of 'false' indicates that
2899the wst:RequestSecurityTokenCollection element MUST NOT be present. This property has a default
2900value of 'false'.
2901
290210.1 Trust13 Assertion

2903The Trust13 assertion allows you to specify which WS-Trust 1.3 options are supported.
2904Syntax
2905 <sp:Trust13 xmlns:sp="..." ... >
2907 <sp:MustSupportClientChallenge ... />?
2908 <sp:MustSupportServerChallenge ... />?
2909 <sp:RequireClientEntropy ... />?
2910 <sp:RequireServerEntropy ... />?
2911 <sp:MustSupportIssuedTokens ... />?
2912 <sp:RequireRequestSecurityTokenCollection />?
2913 <sp:RequireAppliesTo />?
2914 ...
2915 </wsp:Policy>
2916 ...
2917 </sp:Trust13 ... >
2918
2920/sp:Trust13
2921 This identifies a Trust13 assertion.
2922/sp:Trust13/wsp:Policy
2923 This indicates a policy that controls WS-Trust 1.3 options.
2924/sp:Trust13/wsp:Policy/sp:MustSupportClientChallenge
2925 This optional element is a policy assertion indicates that the [Client Challenge] property is set to
2926 'true'.
2927/sp:Trust13/wsp:Policy/sp:MustSupportServerChallenge
2928 This optional element is a policy assertion indicates that the [Server Challenge] property is set to
2929 'true'.
2930/sp:Trust13/wsp:Policy/sp:RequireClientEntropy
2931 This optional element is a policy assertion indicates that the [Client Entropy] property is set to
2932 'true'.
2933/sp:Trust13/wsp:Policy/sp:RequireServerEntropy
2934 This optional element is a policy assertion indicates that the [Server Entropy] property is set to
2935 'true'.
2936/sp:Trust13/wsp:Policy/sp:MustSupportIssuedTokens
2937 This optional element is a policy assertion indicates that the [Issued Tokens] property is set to
2938 'true'.
2939/sp:Trust13/wsp:Policy/sp:RequireRequestSecurityTokenCollection

2940 This optional element is a policy assertion that indicates that the [Collection] property is set to
2941 'true'.
2942/sp:Trust10/wsp:Policy/sp:RequireAppliesTo
2943 This optional element is a policy assertion that indicates that the STS requires the requestor to
2944 specify the scope for the issued token using wsp:AppliesTo in the RST.

294511 Guidance on creating new assertions and assertion
2946 extensibility
2947This non-normative appendix provides guidance for designers of new assertions intended for use with this
2948specification.
294911.1 General Design Points

2950  Prefer Distinct Qnames
2951  Parameterize using nested policy where possible.
2952  Parameterize using attributes and/or child elements where necessary.
295311.2 Detailed Design Guidance

2954Assertions in WS-SP are XML elements that are identified by their QName. Matching of assertions per
2955WS-Policy is performed by matching element QNames. Matching does not take into account attributes
2956that are present on the assertion element. Nor does it take into account child elements except for
2957wsp:Policy elements. If a wsp:Policy element is present, then matching occurs against the assertions
2958nested inside that wsp:Policy element recursively (see Policy Assertion Nesting [WS-Policy]).
2959
2960When designing new assertions for use with WS-SP, the above matching behaviour needs to be taken
2961into account. In general, multiple assertions with distinct QNames are preferably to a single assertion that
2962uses attributes and/or content to distinguish different cases. For example, given two possible assertion
2963designs;
2964
2965 Design 1
2966
2967 <A1/>
2968 <A2/>
2969 <A3/>
2970
2971 Design 2.
2972
2973 <A Parameter='1' />
2977then design 1. would generally be prefered because it allows the policy matching logic to provide more
2978accurate matches between policies.
2979
2980A good example of design 1 is the token assertions defined in Section 5. The section defines 10 distinct
2981token assertions, rather than a single sp:Token assertion with, for example, a TokenType attribute. These
2982distinct token assertions make policy matching much more useful as less false positives are generated
2983when performing policy matching.
2984
2985There are cases where using attributes or child elements as parameters in assertion design is
2986reasonable. Examples include cases when implementations are expected to understand all the values for

2987a given parameter and when encoding the parameter information into the assertion QName would result
2988in an unmanageable number of assertions. A good example is the sp:IncludeToken attribute that appears
2989on the various token assertions. Five possible values are currently specified for the sp:IncludeToken
2990attribute and implementations are expected to understand the meaning of all 5 values. If this information
2991was encoded into the assertion QNames, each existing token assertion would require five variants, one
2992for each Uri value which would result in 45 assertions just for the tokens defined in Section 5.
2993
2994Nested policy is ideal for encoding parameters that can be usefully matched using policy matching. For
2995example, the token version assertions defined in Section 5 use such an approach. The overall token type
2996assertion is parameterized by the nested token version assertions. Policy matching can use these
2997parameters to find matches between policies where the broad token type is support by both parties but
2998they might not support the same specific versions.
2999
3000Note, when designing assertions for new token types such assertions SHOULD allow the
3001sp:IncludeToken attribute and SHOULD allow nested policy.
3002

300312Security Considerations
3004It is strongly recommended that policies and assertions be signed to prevent tampering.
3005It is recommended that policies should not be accepted unless they are signed and have an associated
3006security token to specify the signer has proper claims for the given policy. That is, a party shouldn't rely
3007on a policy unless the policy is signed and presented with sufficient claims. It is further recommended that
3008the entire policy exchange mechanism be protected to prevent man-in-the-middle downgrade attacks.
3009
3010It should be noted that the mechanisms described in this document could be secured as part of a SOAP
3011message using WSS: SOAP Message Security [WSS10, WSS11] or embedded within other objects using
3012object-specific security mechanisms.
3013
3014It is recommended that policies not specify two (or more) SignedSupportingTokens or
3015SignedEndorsingSupportingTokens of the same token type. Messages conforming to such policies are
3016subject to modification which may be undetectable.
3017
3018It is recommended that policies specify the OnlySignEntireHeadersAndBody assertion along with the rest
3019of the policy in order to combat certain XML substitution attacks.

3020A. Assertions and WS-PolicyAttachment
3021This non-normative appendix classifies assertions according to their suggested scope in WSDL 1.1 per
3022Section 4 of [WS-PolicyAttachment]. See Figure 1 in Section 4.1 of [WS-PolicyAttachment] for a graphical
3023representation of the relationship between policy scope and WSDL. Unless otherwise noted above, any
3024assertion that is listed under multiple [Policy Subjects] below MUST only apply to only one [Policy
3025Subject] in a WSDL 1.1 hierarchy for calculating an Effective Policy.
3026A.1 Endpoint Policy Subject Assertions
3027A.1.1 Security Binding Assertions

3028TransportBinding Assertion (Section 7.3)
3029SymmetricBinding Assertion (Section 7.4)
3030AsymmetricBinding Assertion (Section 7.5)
3031A.1.2 Token Assertions

3032SupportingTokens Assertion (Section 8.1)
3033SignedSupportingTokens Assertion (Section 8.2)
3034EndorsingSupportingTokens Assertion (Section 8.3)
3035SignedEndorsingSupportingTokens Assertion (Section 8.4)
3036SignedEncryptedSupportingTokens Assertion (Section 8.5)
3037EndorsingEncryptedSupportingTokens Assertion (Section 8.6)
3038SignedEndorsingEncryptedSupportingTokens Assertion (Section 8.7)
3039A.1.3 WSS: SOAP Message Security 1.0 Assertions

3040Wss10 Assertion (Section 9.1)
3041A.1.4 WSS: SOAP Message Security 1.1 Assertions

3042Wss11 Assertion (Section 9.2)
3043A.1.5 Trust 1.0 Assertions

3044Trust13 Assertion (Section 10.1)
3045A.2 Operation Policy Subject Assertions
3046A.2.1 Security Binding Assertions

3047SymmetricBinding Assertion (Section 7.4)
3048AsymmetricBinding Assertion (Section 7.5)
3049A.2.2 Supporting Token Assertions


3057A.3 Message Policy Subject Assertions
3058A.3.1 Supporting Token Assertions

3066A.3.2 Protection Assertions

3067SignedParts Assertion (Section 4.1.1)
3068SignedElements Assertion (Section 4.1.2)
3069EncryptedParts Assertion (Section 4.2.1)
3070EncryptedElements Assertion (Section 4.2.2)
3071ContentEncryptedElements Assertion (Section 4.2.3)
3072RequiredElements Assertion (Section 4.3.1)
3073RequiredParts Assertion (Section 4.3.2)
3074A.4 Assertions With Undefined Policy Subject

3075The assertions listed in this section do not have a defined policy subject because they appear nested
3076inside some other assertion which does have a defined policy subject. This list is derived from nested
3077assertions in the specification that have independent sections. It is not a complete list of nested
3078assertions. Many of the assertions previously listed in this appendix as well as the ones below have
3079additional nested assertions.
3080A.4.1 General Assertions

3081AlgorithmSuite Assertion (Section 7.1)
3082Layout Assertion (Section 7.2)
3083A.4.2 Token Usage Assertions

3084See the nested assertions under the TransportBinding, SymmetricBinding and AssymetricBinding
3085assertions.

3086A.4.3 Token Assertions
3087UsernameToken Assertion (Section 5.3.1)
3088IssuedToken Assertion (Section 5.3.2)
3089X509Token Assertion (Section 5.3.3)
3090KerberosToken Assertion (Section 5.3.4)
3091SpnegoContextToken Assertion (Section 5.3.5)
3092SecurityContextToken Assertion (Section 5.3.6)
3093SecureConversationToken Assertion (Section 5.3.7)
3094SamlToken Assertion (Section 5.3.8)
3095RelToken Assertion (Section 5.3.9)
3096HttpsToken Assertion (Section 5.3.10)

3097B. Issued Token Policy
3098The section provides further detail about behavior associated with the IssuedToken assertion in section
30995.3.2.
3100
3101The issued token security model involves a three-party setup. There’s a target Server, a Client, and a
3102trusted third party called a Security Token Service or STS. Policy flows from Server to Client, and from
3103STS to Client. Policy may be embedded inside an Issued Token assertion, or acquired out-of-band. There
3104may be an explicit trust relationship between the Server and the STS. There must be a trust relationship
3105between the Client and the STS.
3106
3107The Issued Token policy assertion includes two parts: 1) client-specific parameters that must be
3108understood and processed by the client and 2) STS specific parameters which are to be processed by the
3109STS. The format of the Issued Token policy assertion is illustrated in the figure below.
Issued Token Policy
Client Parameters
STS Parameters
3110
3111The client-specific parameters of the Issued Token policy assertion along with the remainder of the server
3112policy are consumed by the client. The STS specific parameters of the Issued Token policy assertion are
3113passed on to the STS by copying the parameters directly into the wst:SecondaryParameters of the
3114RST request sent by the Client to the STS as illustrated in the figure below.
3115
STS
3 2
RST STS Policy
1
Client Server
Server Policy
3116
3117Before the Client sends the RST to the STS, it will need to obtain the policy for the STS. This will help to
3118formulate the RST request and will include any security-specific requirements of the STS.
3119
3120The Client may augment or replace the contents of the RST made to the STS based on the Client-specific
3121parameters received from the Issued Token policy assertion contained in the Server policy, from policy it
3122received for the STS, or any other local parameters.
3123
3124The Issued Token Policy Assertion contains elements which must be understood by the Client. The
3125assertion contains one element which contains a list of arbitrary elements which should be sent along to
3126the STS by copying the elements as-is directly into the wst:SecondaryParameters of the RST
3127request sent by the Client to the STS following the protocol defined in WS-Trust.
3128
3129Elements inside the sp:RequestSecurityTokenTemplate element MUST conform to WS-Trust [WS-
3130Trust]. All items are optional, since the Server and STS may already have a pre-arranged relationship
3131which specifies some or all of the conditions and constraints for issued tokens.

3132C. Strict Security Header Layout Examples
3133The following sections describe the security header layout for specific bindings when applying the ‘Strict’
3134layout rules defined in Section 6.7.
3135C.1 Transport Binding

3136This section describes how the ‘Strict’ security header layout rules apply to the Transport Binding.
3137C.1.1 Policy
3138The following example shows a policy indicating a Transport Binding, an Https Token as the Transport
3139Token, an algorithm suite, a requirement to include tokens in the supporting signatures, a username
3140token attached to the message, and finally an X509 token attached to the message and endorsing the
3141message signature. No message protection requirements are described since the transport covers all
3142message parts.
3144 <sp:TransportBinding>
3145 <wsp:Policy>
3146 <sp:TransportToken>
3147 <wsp:Policy>
3148 <sp:HttpsToken />
3149 </wsp:Policy>
3150 </sp:TransportToken>
3152 <wsp:Policy>
3153 <sp:Basic256 />
3154 </wsp:Policy>
3156 <sp:Layout>
3157 <wsp:Policy>
3158 <sp:Strict />
3159 </wsp:Policy>
3160 </sp:Layout>
3161 <sp:IncludeTimestamp />
3162 </wsp:Policy>
3163 </sp:TransportBinding>
3165 <wsp:Policy>
3167 </wsp:Policy>
3170 <wsp:Policy>
3171 <sp:X509Token sp:IncludeToken=".../IncludeToken/Once">
3172 <wsp:Policy>
3174 </wsp:Policy>
3176 </wsp:Policy>
3178 <sp:Wss11>
3179 <sp:RequireSignatureConfirmation />
3180 </sp:Wss11>
3181 </wsp:Policy>

3182This policy is used as the basis for the examples shown in the subsequent section describing the security
3183header layout for this binding.
3184C.1.2 Initiator to Recipient Messages

3185Messages sent from initiator to recipient have the following layout for the security header:
3186 1. A wsu:Timestamp element.
3187 2. Any tokens contained in the [Signed Supporting Tokens] property.
3188 3. Any tokens contained in the [Signed Endorsing Supporting Tokens] property each followed by the
3189 corresponding signature. Each signature MUST cover the wsu:Timestamp element from 1
3190 above and SHOULD cover any other unique identifier for the message in order to prevent
3191 replays. If [Token Protection] is 'true', the signature MUST also cover the supporting token. If
3192 [Derived Keys] is 'true' and the supporting token is associated with a symmetric key, then a
3193 Derived Key Token, based on the supporting token, appears between the supporting token and
3194 the signature.
3195 4. Any signatures for tokens contained in the [Endorsing Supporting Tokens] property. Each
3196 signature MUST cover the wsu:Timestamp element from 1 above and SHOULD cover at least
3197 some other unique identifier for the message in order to prevent replays. If [Token Protection] is
3198 'true', the signature MUST also cover the supporting token. If [Derived Keys] is 'true' and the
3199 supporting token is associated with a symmetric key, then a Derived Key Token, based on the
3200 supporting token, appears before the signature.
3201The following diagram illustrates the security header layout for the initiator to recipient message:

Header1
Header2
Security
TS
ST1
ST2
Sig2
Body
3202
3203The outer box shows that the entire message is protected (signed and encrypted) by the transport. The
3204arrows on the left from the box labeled Sig2 indicate the parts signed by the supporting token labeled ST2,
3205namely the message timestamp labeled TS and the token used as the basis for the signature labeled ST 2.
3206The dotted arrow indicates the token that was used as the basis for the signature. In general, the ordering
3207of the items in the security header follows the most optimal layout for a receiver to process its contents.
3208Example:
3209Initiator to recipient message

3210 <S:Envelope xmlns:S="..." xmlns:wsse="..." xmlns:wsu="..." xmlns:ds="...">
3211 <S:Header>
3212 ...
3213 <wsse:Security>
3214 <wsu:Timestamp wsu:Id="timestamp">
3215 <wsu:Created>[datetime]</wsu:Created>
3216 <wsu:Expires>[datetime]</wsu:Expires>
3217 </wsu:Timestamp>
3218 <wsse:UsernameToken wsu:Id='SomeSignedToken' >
3219 ...
3220 </wsse:UsernameToken>
3221 <wsse:BinarySecurityToken wsu:Id="SomeSignedEndorsingToken" >
3222 ...
3223 </wsse:BinarySecurityToken>
3224 <ds:Signature>
3225 <ds:SignedInfo>
3226 <ds:References>
3227 <ds:Reference URI="#timestamp" />
3228 <ds:Reference URI="#SomeSignedEndorsingToken" />
3229 </ds:References>
3230 </ds:SignedInfo>
3231 <ds:SignatureValue>...</ds:SignatureValue>
3232 <ds:KeyInfo>
3233 <wsse:SecurityTokenReference>
3234 <wsse:Reference URI="#SomeSignedEndorsingToken" />
3235 </wsse:SecurityTokenReference>
3236 </ds:KeyInfo>
3237 </ds:Signature>
3238 ...
3239 </wsse:Security>
3240 ...
3241 </S:Header>
3242 <S:Body>
3243 ...
3244 </S:Body>
3245 </S:Envelope>
3246C.1.3 Recipient to Initiator Messages

3247Messages sent from recipient to initiator have the following layout for the security header:
3248 1. A wsu:Timestamp element.
3249 2. If the [Signature Confirmation] property has a value of 'true', then a
3250 wsse11:SignatureConfirmation element for each signature in the corresponding message
3251 sent from initiator to recipient. If there are no signatures in the corresponding message from the
3252 initiator to the recipient, then a wsse11:SignatureConfirmation element with no Value
3253 attribute.
3254The following diagram illustrates the security header layout for the recipient to initiator message:

Header1
Header2
Security
TS
SC1
Body
3255
3256The outer box shows that the entire message is protected (signed and encrypted) by the transport. One
3257wsse11:SignatureConfirmation element labeled SC1 corresponding to the signature in the initial
3258message illustrated previously is included. In general, the ordering of the items in the security header
3259follows the most optimal layout for a receiver to process its contents.
3260Example:
3261Recipient to initiator message
3262 <S:Envelope xmlns:S="..." xmlns:wsse="..." xmlns:wsu="..." xmlns:wsse11="...">
3263 <S:Header>
3264 ...
3266 <wsu:Timestamp wsu:Id="timestamp">
3267 <wsu:Created>[datetime]</wsu:Created>
3268 <wsu:Expires>[datetime]</wsu:Expires>
3270 <wsse11:SignatureConfirmation Value="..." />
3271 ...
3273 ...
3274 </S:Header>
3275 <S:Body>
3276 ...
3277 </S:Body>
3278 </S:Envelope>
3279C.2 Symmetric Binding

3280This section describes how the ‘Strict’ security header layout rules apply to the Symmetric Binding.
3281C.2.1 Policy
3282The following example shows a policy indicating a Symmetric Binding, a symmetric key based
3283IssuedToken provided as the Protection Token, an algorithm suite, a requirement to encrypt the message
3284parts before signing, a requirement to encrypt the message signature, a requirement to include tokens in
3285the message signature and the supporting signatures, a username token attached to the message, and
3286finally an X509 token attached to the message and endorsing the message signature. Minimum message
3287protection requirements are described as well.
3290 <sp:SymmetricBinding>
3291 <wsp:Policy>
3293 <sp:IssuedToken sp:IncludeToken=".../IncludeToken/Once" >
3294 <sp:Issuer>...</sp:Issuer>
3295 <sp:RequestSecurityTokenTemplate>
3296 ...
3301 <wsp:Policy>
3302 <sp:Basic256 />
3303 </wsp:Policy>
3305 <sp:Layout>
3306 <wsp:Policy>
3307 <sp:Strict />
3308 </wsp:Policy>
3309 </sp:Layout>
3311 <sp:EncryptBeforeSigning />
3312 <sp:EncryptSignature />
3313 <sp:ProtectTokens />
3314 </wsp:Policy>
3317 <wsp:Policy>
3319 </wsp:Policy>
3322 <wsp:Policy>
3324 <wsp:Policy>
3326 </wsp:Policy>
3328 </wsp:Policy>
3330 <sp:Wss11>
3331 <wsp:Policy>
3333 </wsp:Policy>
3334 </sp:Wss11>
3335 </wsp:Policy>

3337
3338 
3341 <sp:Header Name="Header1" Namespace="..." />
3343 <sp:Body/>
3345 <sp:EncryptedParts>
3347 <sp:Body/>
3349 </wsp:Policy>

3353Messages sent from initiator to recipient have the following layout for the security header:
3354 1. A wsu:Timestamp element if [Timestamp] is 'true'.
3355 2. If the sp:IncludeToken attribute on the [Encryption Token] is .../IncludeToken/Once or
3356 .../IncludeToken/Always, then the [Encryption Token].
3357 3. If [Derived Keys] is 'true', then a Derived Key Token, based on the [Encryption Token]. This
3358 Derived Key Token is used for encryption.
3359 4. A reference list including references to encrypted items. If [Signature Protection] is 'true', then the
3360 reference list MUST include a reference to the message signature. If [Protection Order] is
3361 'SignBeforeEncrypting', then the reference list MUST include a reference to all the message parts
3362 specified in the EncryptedParts assertions in the policy. If [Derived Keys] is 'true', then the key in
3363 the token from 3 above MUST be used, otherwise the key in the [Encryption Token].
3364 5. Any tokens from the [Signed Supporting Tokens] and [Signed Endorsing Supporting Tokens]
3365 properties whose sp:IncludeToken attribute is .../IncludeToken/Once or
3366 .../IncludeToken/Always.
3367 6. If the [Signature Token] is not the same as the [Encryption Token], and the sp:IncludeToken
3368 attribute on the [Signature Token] is .../IncludeToken/Once or .../IncludeToken/Always, then the
3369 [Signature Token].
3370 7. If [Derived Keys] is 'true', then a Derived Key Token based on the [Signature Token]. This
3371 Derived Key Token is used for signature.
3372 8. A signature over the wsu:Timestamp from 1 above, any tokens from 5 above regardless of
3373 whether they are included in the message, and any message parts specified in SignedParts
3374 assertions in the policy. If [Token Protection] is 'true', the signature MUST cover the [Signature
3375 Token] regardless of whether it is included in the message. If [Derived Keys] is 'true', the key in
3376 the token from 7 above MUST be used, otherwise the key in the [Signature Token] from 6 above.
3377 9. Signatures covering the main signature from 8 above for any tokens from the [Endorsing
3378 Supporting Tokens] and [Signed Endorsing Supporting Tokens] properties. If [Token Protection]
3379 is 'true', the signature MUST also cover the endorsing token. If [Derived Keys] is 'true' and the
3380 endorsing token is associated with a symmetric key, then a Derived Key Token, based on the
3381 endorsing token, appears before the signature.
3382 10. If [Protection Order] is 'EncryptBeforeSigning', then a reference list referencing all the message
3383 parts specified in EncryptedParts assertions in the policy. If [Derived Keys] is 'true', then the key

3384 in the token from 3 above MUST be used, otherwise the key in the [Encryption Token] from 2
3385 above.
3386
3387The following diagram illustrates the security header layout for the initiator to recipient message:
Encrypt Then Sign Sign Then Encrypt
Header1 Header1
Header2
Header2
Security
Security
TS
TS
ST1
ST1
Ref1
Ref1
ST3
ST3
ST2
ST2
Sig1
Sig1
Sig2
Sig2
Ref1
Body Body
3388
3389The arrows on the right indicate parts that were signed as part of the message signature labeled Sig 1. The
3390dashed arrows on the left from the box labeled Sig2 indicate the parts signed by the supporting token
3391labeled ST2, namely the message signature labeled Sig1 and the token used as the basis for the signature
3392labeled ST2. The arrows on the left from boxes labeled Ref1 indicate references to parts encrypted using a
3393key based on the Shared Secret Token labeled ST1. The dotted arrows inside the box labeled Security
3394indicate the token that was used as the basis for each cryptographic operation. In general, the ordering of
3395the items in the security header follows the most optimal layout for a receiver to process its contents.
3396Example:
3397Initiator to recipient message using EncryptBeforeSigning:
3398 <S:Envelope xmlns:S="..." xmlns:x="..." xmlns:wsu="..."
3399 xmlns:wsse11="..." xmlns:wsse="..." xmlns:saml="..."
3400 xmlns:xenc="..." xmlns:ds="...">
3401 <S:Header>
3402 <x:Header1 wsu:Id="Header1" >
3403 ...
3404 </x:Header1>

3406 <wsse11:EncryptedHeader wsu:Id="enc_Header2">
3407 
3412 ...
3413 </wsse11:EncryptedHeader>
3414 ...
3416 <wsu:Timestamp wsu:Id="Timestamp">
3417 <wsu:Created>...</wsu:Created>
3418 <wsu:Expires>...</wsu:Expires>
3420 <saml:Assertion AssertionId="_SharedSecretToken" ...>
3421 ...
3422 </saml:Assertion>
3423 <xenc:ReferenceList>
3424 <xenc:DataReference URI="#enc_Signature" />
3425 <xenc:DataReference URI="#enc_SomeUsernameToken" />
3426 ...
3427 </xenc:ReferenceList>
3428 <xenc:EncryptedData ID="enc_SomeUsernameToken" >
3429 
3434 ...
3435 <ds:KeyInfo>
3437 <wsse:Reference URI="#_SharedSecretToken" />
3439 </ds:KeyInfo>
3440 </xenc:EncryptedData>
3441 <wsse:BinarySecurityToken wsu:Id="SomeSupportingToken" >
3442 ...
3444 <xenc:EncryptedData ID="enc_Signature">
3445 
3466 ...
3467 <ds:KeyInfo>

3471 </ds:KeyInfo>
3473 <ds:Signature>
3476 <ds:Reference URI="#Signature" >...</ds:Reference>
3481 <ds:KeyInfo>
3483 <wsse:Reference URI="#SomeSupportingToken" />
3485 </ds:KeyInfo>
3488 <xenc:DataReference URI="#enc_Body" />
3489 <xenc:DataReference URI="#enc_Header2" />
3490 ...
3493 </S:Header>
3494 <S:Body wsu:Id="Body">
3495 <xenc:EncryptedData Id="enc_Body">
3496 ...
3497 <ds:KeyInfo>
3501 </ds:KeyInfo>
3503 </S:Body>
3504 </S:Envelope>

3506Messages send from recipient to initiator have the following layout for the security header:
3508 2. If the sp:IncludeToken attribute on the [Encryption Token] is .../IncludeToken/Always, then the
3509 [Encryption Token].
3510 3. If [Derived Keys] is 'true', then a Derived Key Token, based on the [Encryption Token]. This
3511 Derived Key Token is used for encryption.
3512 4. A reference list including references to encrypted items. If [Signature Protection] is 'true', then the
3513 reference list MUST include a reference to the message signature from 6 below, and the
3514 wsse11:SignatureConfirmation elements from 5 below if any. If [Protection Order] is
3515 'SignBeforeEncrypting', then the reference list MUST include a reference to all the message parts
3516 specified in the EncryptedParts assertions in the policy. If [Derived Keys] is 'true', then the key in
3517 the token from 2 above MUST be used, otherwise the key in the [Encryption Token] from 2
3518 above.
3519 5. If [Signature Confirmation] is 'true' then a wsse11:SignatureConfirmation element for each
3520 signature in the corresponding message sent from initiator to recipient. If there are no signatures

3521 in the corresponding message from the initiator to the recipient, then a
3522 wsse11:SignatureConfirmation element with no Value attribute.
3523 6. If the [Signature Token] is not the same as the [Encryption Token], and the sp:IncludeToken
3524 attribute on the [Signature Token] is .../IncludeToken/Always, then the [Signature Token].
3525 7. If [Derived Keys] is 'true', then a Derived Key Token, based on the [Signature Token]. This
3526 Derived Key Token is used for signature.
3527 8. A signature over the wsu:Timestamp from 1 above, any wsse11:SignatureConfirmation
3528 elements from 5 above, and all the message parts specified in SignedParts assertions in the
3529 policy. If [Token Protection] is 'true', the signature MUST also cover the [Signature Token]
3530 regardless of whether it is included in the message. If [Derived Keys] is 'true', the key in the token
3531 from 6 above MUST be used, otherwise the key in the [Signature Token].
3532 9. If [Protection Order] is 'EncryptBeforeSigning' then a reference list referencing all the message
3533 parts specified in EncryptedParts assertions in the policy. If [Derived Keys] is 'true', then the key
3534 in the Derived Key Token from 3 above MUST be used, otherwise the key in the [Encryption
3535 Token].
3536The following diagram illustrates the security header layout for the recipient to initiator message:
Header1 Header1
Header2 Header2
Security
Security
TS
TS
Ref1
Ref1
SC2
SC2
SC1
SC1
Sig1
Sig1
Ref1
Body Body
3537
3538The arrows on the right indicate parts that were signed as part of the message signature labeled Sig 1. The
3539arrows on the left from boxes labeled Ref1 indicate references to parts encrypted using a key based on
3540the [SharedSecret Token] (not shown in these diagrams as it is referenced as an external token). Two
3541wsse11:SignatureConfirmation elements labeled SC1 and SC2 corresponding to the two signatures
3542in the initial message illustrated previously is included. In general, the ordering of the items in the security
3543header follows the most optimal layout for a receiver to process its contents. The rules used to determine
3544this ordering are described in Appendix C.
3545Example:
3546Recipient to initiator message using EncryptBeforeSigning:
3547 <S:Envelope>
3548 <S:Header>
3550 ...
3551 </x:Header1>
3555 ...
3556 </x:Header2>
3557 -->
3558 ...
3560 ...
3568 <xenc:DataReference URI="#enc_SigConf1" />
3570 ...
3572 <xenc:EncryptedData ID="enc_SigConf1" >
3573 
3578 ...
3582 <wsse11:SignatureConfirmation wsu:Id="SigConf2" >
3583 ...
3585 -->
3586 ...

3588
3589 <xenc:EncryptedData Id="enc_Signature">
3595 <ds:Reference URI="#SigConf1" >...</ds:Reference>
3603 <ds:KeyInfo>
3605 <wsse:Reference URI="#_SomeIssuedToken" />
3607 </ds:KeyInfo>
3609 -->
3611 ...
3612 <ds:KeyInfo>
3616 </ds:KeyInfo>
3617 <xenc:EncryptedData>
3621 ...
3625 </S:Header>
3628 ...
3629 <ds:KeyInfo>
3633 </ds:KeyInfo>
3635 </S:Body>
3636 </S:Envelope>
3637C.3 Asymmetric Binding

3638This section describes how the ‘Strict’ security header layout rules apply to the Asymmetric Binding.
3639C.3.1 Policy
3640The following example shows a policy indicating an Asymmetric Binding, an X509 token as the [Initiator
3641Token], an X509 token as the [Recipient Token], an algorithm suite, a requirement to encrypt the
3642message parts before signing, a requirement to encrypt the message signature, a requirement to include
3643tokens in the message signature and the supporting signatures, a requirement to include

3644wsse11:SignatureConfirmation elements, a username token attached to the message, and finally
3645an X509 token attached to the message and endorsing the message signature. Minimum message
3646protection requirements are described as well.
3649 <sp:AsymmetricBinding>
3650 <wsp:Policy>
3652 <wsp:Policy>
3653 <sp:X509Token sp:IncludeToken=".../IncludeToken/Always" />
3654 </wsp:Policy>
3657 <wsp:Policy>
3658 <sp:X509Token sp:IncludeToken=".../IncludeToken/Always" />
3659 </wsp:Policy>
3662 <wsp:Policy>
3663 <sp:Basic256 />
3664 </wsp:Policy>
3666 <sp:Layout>
3667 <wsp:Policy>
3668 <sp:Strict />
3669 </wsp:Policy>
3670 </sp:Layout>
3672 <sp:EncryptBeforeSigning />
3673 <sp:EncryptSignature />
3674 <sp:ProtectTokens />
3675 </wsp:Policy>
3677 <sp:SignedEncryptedSupportingTokens>
3678 <wsp:Policy>
3680 </wsp:Policy>
3681 </sp:SignedEncryptedSupportingTokens>
3683 <wsp:Policy>
3685 <wsp:Policy>
3687 </wsp:Policy>
3689 </wsp:Policy>
3691 <sp:Wss11>
3692 <wsp:Policy>
3694 </wsp:Policy>
3695 </sp:Wss11>
3696 </wsp:Policy>
3698

3699 
3700 <wsp:All xmlns:wsp="..." xmlns:sp="...">
3704 <sp:Body/>
3706 <sp:EncryptedParts>
3708 <sp:Body/>
3710 </wsp:All>
3711

3715Messages sent from initiator to recipient have the following layout:
3717 2. If a [Recipient Token] is specified, and the associated sp:IncludeToken attribute is
3718 .../IncludeToken/Once or .../IncludeToken/Always, then the [Recipient Token].
3719 3. If a [Recipient Token] is specified and [Protection Order] is 'SignBeforeEncrypting' or
3720 [SignatureProtection] is 'true' then an xenc:EncryptedKey element, containing a key encrypted for
3721 the recipient. The xenc:EncryptedKey element MUST include an xenc:ReferenceList containing a
3722 reference to all the message parts specified in EncryptedParts assertions in the policy. If
3723 [Signature Protection] is 'true' then the reference list MUST contain a reference to the message
3724 signature from 6 below. It is an error if [Signature Protection] is 'true' and there is not a message
3725 signature.
3726 4. Any tokens from the supporting tokens properties (as defined in section 8) whose
3727 sp:IncludeToken attribute is .../IncludeToken/Once or .../IncludeToken/Always.
3728 5. If an [Initiator Token] is specified, and the associated sp:IncludeToken attribute is
3729 .../IncludeToken/Once or .../IncludeToken/Always, then the [Initiator Token].
3730 6. A signature based on the key in the [Initiator Token] if specified, over the wsu:Timestamp from 1
3731 above, any tokens from 4 above regardless of whether they are included in the message, and any
3732 message parts specified in SignedParts assertions in the policy. If [Token Protection] is 'true', the
3733 signature MUST also cover the [Initiator Token] regardless of whether it is included in the
3734 message.
3735 7. Signatures for tokens from the [Endorsing Supporting Tokens] and [Signed Endorsing Supporting
3736 Tokens] properties. If [Derived Keys] is 'true' and the supporting token is associated with a
3737 symmetric key, then a Derived Key Token, based on the supporting token, appears before the
3738 signature. If [Token Protection] is 'true', the signature MUST also cover the supporting token
3739 regardless of whether it is included in the message.
3740 8. If a [Recipient Token] is specified and [Protection Order] is 'EncryptBeforeSigning' then if
3741 [Signature Protection] is 'false' then an xenc:EncryptedKey element, containing a key encrypted
3742 for the recipient and a reference list, else if [Signature Protection] is 'true', a reference list. The
3743 reference list includes a reference to all the message parts specified in EncryptedParts assertions
3744 in the policy. The encrypted parts MUST reference the key contained in the xenc:EncryptedKey
3745 element from 3 above.

3746
3747The following diagram illustrates the security header layout for the initiator to recipient messages:
Header1 Header1
Header2 Header2
Security Security
TS TS
ST1 ST1
EK1 EK1
ST4 ST4
ST3 ST3
ST2 ST2
Sig2 Sig2
Sig3 Sig3
Ref1
Body
Body
3748
3749The arrows on the right indicate parts that were signed as part of the message signature labeled Sig 2
3750using the [Initiator Token] labeled ST2. The dashed arrows on the left from the box labeled Sig3 indicate
3751the parts signed by the supporting token ST3, namely the message signature Sig2 and the token used as
3752the basis for the signature labeled ST3. The arrows on the left from boxes labeled EK1 indicate references
3753to parts encrypted using a key encrypted for the [Recipient Token] labeled ST 1. The arrows on the left
3754from boxes labeled Ref1 indicate additional references to parts encrypted using the key contained in the
3755encrypted key labeled EK1. The dotted arrows inside the box labeled Security indicate the token used as
3756the basis for each cryptographic operation. In general, the ordering of the items in the security header
3757follows the most optimal layout for a receiver to process its contents. The rules used to determine this
3758ordering are described in Appendix C.
3759
3760Note: In most typical scenarios, the recipient key is not included in the message, but rather the encrypted
3761key contains an external reference to the token containing the encryption key. The diagram illustrates how
3762one might attach a security token related to the encrypted key for completeness. One possible use-case
3763for this approach might be a stack which does not support the STR Dereferencing Transform, but wishes
3764to include the encryption token in the message signature.
3765Initiator to recipient message Example

3767 xmlns:wsse11="..." xmlns:wsse="..." xmlns:xenc="..." xmlns:ds="...">
3768 <S:Header>
3770 ...
3771 </x:Header1>
3775 ...
3776 </x:Header2>
3777 -->
3778 ...
3780 ...
3786 <wsse:BinarySecurityToken wsu:Id="RecipientToken" >
3787 ...
3789 <xenc:EncryptedKey wsu:Id="RecipientEncryptedKey" >
3790 ...
3793 <xenc:DataReference URI="#enc_SomeUsernameToken" />
3794 ...
3796 </xenc:EncryptedKey>
3797 <xenc:EncryptedData ID="enc_SomeUsernameToken" >
3798 
3803 ...
3805 <wsse:BinarySecurityToken wsu:Id="SomeSupportingToken" >
3806 ...
3808 <wsse:BinarySecurityToken wsu:Id="InitiatorToken" >
3809 ...
3817 <ds:Reference URI="#SomeUsernameToken" >...</ds:Reference>
3819 <ds:Reference URI="#InitiatorToken" >...</ds:Reference>
3826 <ds:KeyInfo>
3828 <wsse:Reference URI="#InitiatorToken" />

3830 </ds:KeyInfo>
3832 -->
3833 ...
3835 <ds:Signature>
3838 <ds:Reference URI="#Signature" >...</ds:Reference>
3843 <ds:KeyInfo>
3845 <wsse:Reference URI="#SomeSupportingToken" />
3847 </ds:KeyInfo>
3852 ...
3855 </S:Header>
3858 ...
3859 <ds:KeyInfo>
3861 <wsse:Reference URI="#RecipientEncryptedKey" />
3863 </ds:KeyInfo>
3865 </S:Body>
3866 </S:Envelope>

3868Messages sent from recipient to initiator have the following layout:
3870 2. If an [Initiator Token] is specified, and the associated sp:IncludeToken attribute is
3871 .../IncludeToken/Always, then the [Initiator Token].
3872 3. If an [Initiator Token] is specified and [Protection Order] is 'SignBeforeEncrypting' or
3873 [SignatureProtection] is 'true' then an xenc:EncryptedKey element, containing a key encrypted for
3874 the initiator. The xenc:EncryptedKey element MUST include an xenc:ReferenceList containing a
3875 reference to all the message parts specified in EncryptedParts assertions in the policy. If
3876 [Signature Protection] is 'true' then the reference list MUST also contain a reference to the
3877 message signature from 6 below, if any and references to the
3878 wsse11:SignatureConfirmation elements from 4 below, if any.
3879 4. If [Signature Confirmation] is 'true', then a wsse11:SignatureConfirmation element for each
3880 signature in the corresponding message sent from initiator to recipient. If there are no signatures
3881 in the corresponding message from the initiator to the recipient, then a
3882 wsse11:SignatureConfirmation element with no Value attribute.

3883 5. If a [Recipient Token] is specified, and the associated sp:IncludeToken attribute is
3884 .../IncludeToken/Always, then the [Recipient Token].
3885 6. If a [Recipient Token] is specified, then a signature based on the key in the [Recipient Token],
3886 over the wsu:Timestamp from 1 above, the wsse11:SignatureConfirmation elements
3887 from 4 above, and any message parts specified in SignedParts assertions in the policy. If [Token
3888 Protection] is 'true' then the signature MUST also cover the [Recipient Token].
3889 7. If an [Initiator Token] is specified and [Protection Order] is 'EncryptBeforeSigning' then if
3890 [Signature Protection] is 'false' then an xenc:EncryptedKey element, containing a key encrypted
3891 for the recipient and a reference list, else if [Signature Protection] is 'true', a reference list. The
3892 reference list includes a reference to all the message parts specified in EncryptedParts assertions
3893 in the policy. The encrypted parts MUST reference the key contained in the xenc:EncryptedKey
3894 element from 3 above.
3895
3896The following diagram illustrates the security header layout for the recipient to initiator messages:
Header1 Header1
Header2 Header2
Security Security
TS TS
ST1 ST1
EK1 EK1
SC2 SC2
SC1 SC1
ST2 ST2
Sig2 Sig2
Ref1
Body
Body
3897
3898The arrows on the right indicate parts that were signed as part of the message signature labeled Sig 2
3899using the [Recipient Token] labeled ST2. The arrows on the left from boxes labeled EK1 indicate
3900references to parts encrypted using a key encrypted for the [Recipient Token] labeled ST 1. The arrows on
3901the left from boxes labeled Ref1 indicate additional references to parts encrypted using the key contained
3902in the encrypted key labeled EK1. The dotted arrows inside the box labeled Security indicate the token
3903used as the basis for each cryptographic operation. Two wsse11:SignatureConfirmation elements
3904labeled SC1 and SC2 corresponding to the two signatures in the initial message illustrated previously is
3905included. In general, the ordering of the items in the security header follows the most optimal layout for a
3906receiver to process its contents. The rules used to determine this ordering are described in Appendix C.
3907Recipient to initiator message Example:
3909 xmlns:wsse11="..." xmlns:wsse="..."
3910 xmlns:xenc="..." xmlns:ds="...">
3911 <S:Header>
3913 ...
3914 </x:Header1>
3918 ...
3919 </x:Header2>
3920 -->
3921 ...
3923 ...
3929 <wsse:BinarySecurityToken wsu:Id="InitiatorToken" >
3930 ...
3932 <xenc:EncryptedKey wsu:Id="InitiatorEncryptedKey" >
3933 ...
3938 ...
3940 </xenc:EncryptedKey>
3943 <wsse11:SignatureConfirmation wsu:Id="SigConf2" ...>
3944 ...
3946 -->
3947 ...
3951 <wsse11:SignatureConfirmation wsu:Id="SigConf1" ...>
3952 ...
3954 -->
3955 ...
3957 <wsse:BinarySecurityToken wsu:Id="RecipientToken" >
3958 ...

3969 <ds:Reference URI="#RecipientToken" >...</ds:Reference>
3976 <ds:KeyInfo>
3978 <wsse:Reference URI=”#RecipientToken” />
3980 </ds:KeyInfo>
3982 -->
3983 ...
3988 ...
3991 </S:Header>
3994 ...
3995 <ds:KeyInfo>
3997 <wsse:Reference URI="#InitiatorEncryptedKey" />
3999 </ds:KeyInfo>
4001 </S:Body>
4002 </S:Envelope>

4003D. Signed and Encrypted Elements in the Security
4004 Header
4005This section lists the criteria for when various child elements of the Security header are signed and/or
4006encrypted at the message level including whether they are signed by the message signature or a
4007supporting signature. It assumes that there are no sp:SignedElements and no
4008sp:EncryptedElements assertions in the policy. If such assertions are present in the policy then
4009additional child elements of the security header might be signed and/or encrypted.
4010D.1 Elements signed by the message signature

4011 1. The wsu:Timestamp element (Section 6.2).
4012 2. All wsse11:SignatureConfirmation elements (Section 9).
4013 3. Security Tokens corresponding to [Initiator Signature Token],[Recipient Signature Token],
4014 [Initiator Encryption Token], [Recipient Encryption Token], [Signature Token] or [Encryption
4015 Token] when [Token Protection] has a value of 'true' (Section 6.5).
4016 4. Security Tokens corresponding to [Signed Supporting Tokens] (see Section 8.2) or [Signed
4017 Endorsing Supporting Tokens] (Section 8.5).
4018D.2 Elements signed by all endorsing signatures

4019 1. The ds:Signature element that forms the message signature (Section 8.3).
4020 2. The wsu:Timestamp element in the case of a transport binding (Section 8.3).
4021D.3 Elements signed by a specific endorsing signature

4022 1. Security Tokens corresponding to [Endorsing Supporting Tokens] or [Signed Endorsing
4023 Supporting Tokens] when [Token Protection] has a value of 'true' (Section 8.8).
4024D.4 Elements that are encrypted

4025 1. The ds:Signature element that forms the message signature when [Signature Protection]
4026 has a value of 'true' (Section 6.4).
4027 2. All wsse11:SignatureConfirmation elements when [Signature Protection] has a value
4028 of 'true' (Section 6.4).
4029 3. A wsse:UsernameToken may be encrypted when a transport binding is not being used
4030 (Section 5.3.1).
4031

4032E. Acknowledgements
4033The following individuals have participated in the creation of this specification and are gratefully
4034acknowledged:
4035Original Authors of the intial contribution:
4036 Giovanni Della-Libera, Microsoft
4037 Martin Gudgin, Microsoft
4038 Phillip Hallam-Baker, VeriSign
4039 Maryann Hondo, IBM
4040 Hans Granqvist, Verisign
4041 Chris Kaler, Microsoft (editor)
4042 Hiroshi Maruyama, IBM
4043 Michael McIntosh, IBM
4044 Anthony Nadalin, IBM (editor)
4045 Nataraj Nagaratnam, IBM
4046 Rob Philpott, RSA Security
4047 Hemma Prafullchandra, VeriSign
4048 John Shewchuk, Microsoft
4049 Doug Walter, Microsoft
4050 Riaz Zolfonoon, RSA Security
4051
4052Original Acknowledgements of the initial contribution:
4053 Vaithialingam B. Balayoghan, Microsoft
4054 Francisco Curbera, IBM
4055 Christopher Ferris, IBM
4056 Cédric Fournet, Microsoft
4057 Andy Gordon, Microsoft
4058 Tomasz Janczuk, Microsoft
4059 David Melgar, IBM
4060 Mike Perks, IBM
4061 Bruce Rich, IBM
4062 Jeffrey Schlimmer, Microsoft
4063 Chris Sharp, IBM
4064 Kent Tamura, IBM
4065 T.R. Vishwanath, Microsoft
4066 Elliot Waingold, Microsoft
4067
4068TC Members during the development of this specification:
4069 Don Adams, Tibco Software Inc.
4070 Jan Alexander, Microsoft Corporation
4071 Steve Anderson, BMC Software
4072 Donal Arundel, IONA Technologies
4073 Howard Bae, Oracle Corporation
4074 Abbie Barbir, Nortel Networks Limited
4075 Charlton Barreto, Adobe Systems
4076 Mighael Botha, Software AG, Inc.
4077 Toufic Boubez, Layer 7 Technologies Inc.
4078 Norman Brickman, Mitre Corporation
4079 Melissa Brumfield, Booz Allen Hamilton
4080 Lloyd Burch, Novell
4081 Scott Cantor, Internet2
4082 Greg Carpenter, Microsoft Corporation
4083 Steve Carter, Novell
4084 Symon Chang, BEA Systems, Inc.
4085 Ching-Yun (C.Y.) Chao, IBM
4086 Martin Chapman, Oracle Corporation
4087 Kate Cherry, Lockheed Martin
4088 Henry (Hyenvui) Chung, IBM
4089 Luc Clement, Systinet Corp.
4090 Paul Cotton, Microsoft Corporation
4091 Glen Daniels, Sonic Software Corp.
4092 Peter Davis, Neustar, Inc.
4093 Martijn de Boer, SAP AG
4094 Werner Dittmann, Siemens AG
4095 Abdeslem DJAOUI, CCLRC-Rutherford Appleton Laboratory
4096 Fred Dushin, IONA Technologies
4097 Petr Dvorak, Systinet Corp.
4098 Colleen Evans, Microsoft Corporation
4099 Ruchith Fernando, WSO2
4100 Mark Fussell, Microsoft Corporation
4101 Vijay Gajjala, Microsoft Corporation
4102 Marc Goodner, Microsoft Corporation
4103 Hans Granqvist, VeriSign
4104 Martin Gudgin, Microsoft Corporation
4105 Tony Gullotta, SOA Software Inc.
4106 Jiandong Guo, Sun Microsystems
4107 Phillip Hallam-Baker, VeriSign
4108 Patrick Harding, Ping Identity Corporation
4109 Heather Hinton, IBM
4110 Frederick Hirsch, Nokia Corporation
4111 Jeff Hodges, Neustar, Inc.
4112 Will Hopkins, BEA Systems, Inc.
4113 Alex Hristov, Otecia Incorporated
4114 John Hughes, PA Consulting
4115 Diane Jordan, IBM
4116 Venugopal K, Sun Microsystems
4117 Chris Kaler, Microsoft Corporation
4118 Dana Kaufman, Forum Systems, Inc.
4119 Paul Knight, Nortel Networks Limited
4120 Ramanathan Krishnamurthy, IONA Technologies
4121 Christopher Kurt, Microsoft Corporation
4122 Kelvin Lawrence, IBM
4123 Hubert Le Van Gong, Sun Microsystems
4124 Jong Lee, BEA Systems, Inc.
4125 Rich Levinson, Oracle Corporation
4126 Tommy Lindberg, Dajeil Ltd.
4127 Mark Little, JBoss Inc.
4128 Hal Lockhart, BEA Systems, Inc.
4129 Mike Lyons, Layer 7 Technologies Inc.
4130 Eve Maler, Sun Microsystems
4131 Ashok Malhotra, Oracle Corporation
4132 Anand Mani, CrimsonLogic Pte Ltd
4133 Jonathan Marsh, Microsoft Corporation
4134 Robin Martherus, Oracle Corporation
4135 Miko Matsumura, Infravio, Inc.
4136 Gary McAfee, IBM
4137 Michael McIntosh, IBM
4138 John Merrells, Sxip Networks SRL
4139 Jeff Mischkinsky, Oracle Corporation
4140 Prateek Mishra, Oracle Corporation
4141 Bob Morgan, Internet2
4142 Vamsi Motukuru, Oracle Corporation
4143 Raajmohan Na, EDS
4144 Anthony Nadalin, IBM
4145 Andrew Nash, Reactivity, Inc.
4146 Eric Newcomer, IONA Technologies
4147 Duane Nickull, Adobe Systems
4148 Toshihiro Nishimura, Fujitsu Limited
4149 Rob Philpott, RSA Security
4150 Denis Pilipchuk, BEA Systems, Inc.
4151 Darren Platt, Ping Identity Corporation
4152 Martin Raepple, SAP AG
4153 Nick Ragouzis, Enosis Group LLC
4154 Prakash Reddy, CA
4155 Alain Regnier, Ricoh Company, Ltd.
4156 Irving Reid, Hewlett-Packard
4157 Bruce Rich, IBM
4158 Tom Rutt, Fujitsu Limited
4159 Maneesh Sahu, Actional Corporation
4160 Frank Siebenlist, Argonne National Laboratory
4161 Joe Smith, Apani Networks
4162 Davanum Srinivas, WSO2
4163 Yakov Sverdlov, CA
4164 Gene Thurston, AmberPoint
4165 Victor Valle, IBM
4166 Asir Vedamuthu, Microsoft Corporation
4167 Greg Whitehead, Hewlett-Packard
4168 Ron Williams, IBM
4169 Corinna Witt, BEA Systems, Inc.
4170 Kyle Young, Microsoft Corporation

Ws Securitypolicy 1.2 Spec Os

Caricato da

Informazioni sul documento

Titolo originale

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

Ws Securitypolicy 1.2 Spec Os

Caricato da

Copyright:

Formati disponibili

1

4ws-securitypolicy-1.2-spec-os 1 July 2007

7ws-securitypolicy-1.2-spec-os 1 July 2007

10ws-securitypolicy-1.2-spec-os 1 July 2007

16ws-securitypolicy-1.2-spec-os 1 July 2007

19ws-securitypolicy-1.2-spec-os 1 July 2007

Prefix Namespace Specification(s)

22ws-securitypolicy-1.2-spec-os 1 July 2007

2911.3 Schema Files

3121.4.1 Notational Conventions

25ws-securitypolicy-1.2-spec-os 1 July 2007

3551.5 Normative References

28ws-securitypolicy-1.2-spec-os 1 July 2007

31ws-securitypolicy-1.2-spec-os 1 July 2007

34ws-securitypolicy-1.2-spec-os 1 July 2007

4901.6 Non-Normative References

37ws-securitypolicy-1.2-spec-os 1 July 2007

5162.1 Security Assertion Model

5422.2 Nested Policy Assertions

5492.3 Security Binding Abstraction

46ws-securitypolicy-1.2-spec-os 1 July 2007

5823.1 Nested Policy

5863.2 Policy Subjects

52ws-securitypolicy-1.2-spec-os 1 July 2007

6344.1 Integrity Assertions

6384.1.1 SignedParts Assertion

55ws-securitypolicy-1.2-spec-os 1 July 2007

6874.1.2 SignedElements Assertion

58ws-securitypolicy-1.2-spec-os 1 July 2007

7134.2 Confidentiality Assertions

7174.2.1 EncryptedParts Assertion

61ws-securitypolicy-1.2-spec-os 1 July 2007

7684.2.2 EncryptedElements Assertion

64ws-securitypolicy-1.2-spec-os 1 July 2007

8214.3 Required Elements Assertion

8284.3.1 RequiredElements Assertion

67ws-securitypolicy-1.2-spec-os 1 July 2007

8524.3.2 RequiredParts Assertion

70ws-securitypolicy-1.2-spec-os 1 July 2007

8795.1 Token Inclusion

8855.1.1 Token Inclusion Values

8955.1.2 Token Inclusion and Token References

9125.2 Token Issuer and Required Claims

9135.2.1 Token Issuer

9185.2.2 Token Issuer Name

9285.2.3 Required Claims

9575.3 Token Properties

9585.3.1 [Derived Keys] Property

9675.3.2 [Explicit Derived Keys] Property

9715.3.3 [Implied Derived Keys] Property

9755.4 Token Assertion Types

79ws-securitypolicy-1.2-spec-os 1 July 2007

82ws-securitypolicy-1.2-spec-os 1 July 2007

10555.4.2 IssuedToken Assertion

85ws-securitypolicy-1.2-spec-os 1 July 2007

88ws-securitypolicy-1.2-spec-os 1 July 2007

11285.4.3 X509Token Assertion

94ws-securitypolicy-1.2-spec-os 1 July 2007

12195.4.4 KerberosToken Assertion

12815.4.5 SpnegoContextToken Assertion

100ws-securitypolicy-1.2-spec-os 1 July 2007

103ws-securitypolicy-1.2-spec-os 1 July 2007

13445.4.6 SecurityContextToken Assertion