Specification URIs:

This Version:

http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702/ws-securitypolicy-1.2-spec-errata-cd-01.doc

http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702/ws-securitypolicy-1.2-spec-errata-cd-01.pdf

http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702/ws-securitypolicy-1.2-spec-errata-cd-01.html

Previous Version:

http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702/ws-securitypolicy-1.2-spec-os.doc

http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702/ws-securitypolicy-1.2-spec-os.pdf

http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702/ws-securitypolicy-1.2-spec-os.html

Latest Version:

http://docs.oasis-open.org/ws-sx/ws-securitypolicy/v1.2/ws-securitypolicy.doc

http://docs.oasis-open.org/ws-sx/ws-securitypolicy/v1.2/ws-securitypolicy.pdf

http://docs.oasis-open.org/ws-sx/ws-securitypolicy/v1.2/ws-securitypolicy.html 

Artifact Type:

specification

Technical Committee:

OASIS Web Services Secure Exchange TC

Chair(s):

Kelvin Lawrence, IBM

Chris Kaler, Microsoft

Editor(s):

Anthony Nadalin, IBM

Marc Goodner, Microsoft

Martin Gudgin, Microsoft

Abbie Barbir, Nortel

Hans Granqvist, VeriSign

Related work:

N/A

Declared XML Namespace(s):

http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702

Abstract:

This document indicates the policy assertions for use with [WS-Policy] which apply to WSS: SOAP Message Security [WSS10, WSS11], [WS-Trust] and [WS-SecureConversation]

Status:

This document was last revised or approved by the WS-SX TC on the above date. The level of approval is also listed above. Check the current location noted above for possible later revisions of this document. This document is updated periodically on no particular schedule.

Technical Committee members should send comments on this specification to the Technical Committee’s email list. Others should send comments to the Technical Committee by using the “Send A Comment” button on the Technical Committee’s web page at http://www.oasis-open.org/committees/ws-sx.

For information on whether any patents have been disclosed that may be essential to implementing this specification, and any offers of patent licensing terms, please refer to the Intellectual Property Rights section of the Technical Committee web page (http://www.oasis-open.org/committees/ws-sx/ipr.php).

The non-normative errata page for this specification is located at http://www.oasis-open.org/committees/ws-sx.

Copyright © OASIS® 1993–2008. All Rights Reserved. OASIS trademark, IPR and other policies apply.

All capitalized terms in the following text have the meanings assigned to them in the OASIS Intellectual Property Rights Policy (the "OASIS IPR Policy"). The full Policy may be found at the OASIS website.

This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published, and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this section are included on all such copies and derivative works. However, this document itself may not be modified in any way, including by removing the copyright notice or references to OASIS, except as needed for the purpose of developing any document or deliverable produced by an OASIS Technical Committee (in which case the rules applicable to copyrights, as set forth in the OASIS IPR Policy, must be followed) or as required to translate it into languages other than English.

The limited permissions granted above are perpetual and will not be revoked by OASIS or its successors or assigns.

This document and the information contained herein is provided on an "AS IS" basis and OASIS DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY OWNERSHIP RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

OASIS requests that any OASIS Party or any other party that believes it has patent claims that would necessarily be infringed by implementations of this OASIS Committee Specification or OASIS Standard, to notify OASIS TC Administrator and provide an indication of its willingness to grant patent licenses to such patent claims in a manner consistent with the IPR Mode of the OASIS Technical Committee that produced this specification.

OASIS invites any party to contact the OASIS TC Administrator if it is aware of a claim of ownership of any patent claims that would necessarily be infringed by implementations of this specification by a patent holder that is not willing to provide a license to such patent claims in a manner consistent with the IPR Mode of the OASIS Technical Committee that produced this specification. OASIS may include such claims on its website, but disclaims any obligation to do so.

OASIS takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on OASIS' procedures with respect to rights in any document or deliverable produced by an OASIS Technical Committee can be found on the OASIS website. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this OASIS Committee Specification or OASIS Standard, can be obtained from the OASIS TC Administrator. OASIS makes no representation that any information or list of intellectual property rights will at any time be complete, or that any claims in such list are, in fact, Essential Claims.

The name "OASIS" is a trademark of OASIS, the owner and developer of this specification, and should be used only to refer to the organization and its official outputs. OASIS welcomes reference to, and implementation and use of, specifications, while reserving the right to enforce its marks against misleading uses. Please see http://www.oasis-open.org/who/trademark.php for above guidance.

 

1         Introduction 7

1.1 Example 7

1.2 Namespaces 8

1.3 Schema Files 9

1.4 Terminology 9

1.4.1 Notational Conventions 9

1.5 Normative References 10

1.6 Non-Normative References 13

2         Security Policy Model 14

2.1 Security Assertion Model 14

2.2 Nested Policy Assertions 15

2.3 Security Binding Abstraction 15

3         Policy Considerations 17

3.1 Nested Policy 17

3.2 Policy Subjects 17

4         Protection Assertions 19

4.1 Integrity Assertions 19

4.1.1 SignedParts Assertion 19

4.1.2 SignedElements Assertion 20

4.2 Confidentiality Assertions 21

4.2.1 EncryptedParts Assertion 21

4.2.2 EncryptedElements Assertion 22

4.2.3 ContentEncryptedElements Assertion 22

4.3 Required Elements Assertion 23

4.3.1 RequiredElements Assertion 23

4.3.2 RequiredParts Assertion 24

5         Token Assertions 25

5.1 Token Inclusion 25

5.1.1 Token Inclusion Values 25

5.1.2 Token Inclusion and Token References 26

5.2 Token Issuer and Required Claims 26

5.2.1 Token Issuer 26

5.2.2 Token Issuer Name. 26

5.2.3 Required Claims 26

5.2.4 Processing Rules and Token Matching. 27

5.3 Token Properties 27

5.3.1 [Derived Keys] Property 27

5.3.2 [Explicit Derived Keys] Property 27

5.3.3 [Implied Derived Keys] Property 27

5.4 Token Assertion Types 27

5.4.1 UsernameToken Assertion 27

5.4.2 IssuedToken Assertion 29

5.4.3 X509Token Assertion 31

5.4.4 KerberosToken Assertion 33

5.4.5 SpnegoContextToken Assertion 34

5.4.6 SecurityContextToken Assertion 36

5.4.7 SecureConversationToken Assertion 37

5.4.8 SamlToken Assertion 40

5.4.9 RelToken Assertion 42

5.4.10 HttpsToken Assertion 43

5.4.11 KeyValueToken Assertion. 44

6         Security Binding Properties 47

6.1 [Algorithm Suite] Property 47

6.2 [Timestamp] Property 49

6.3 [Protection Order] Property 49

6.4 [Signature Protection] Property 49

6.5 [Token Protection] Property 49

6.6 [Entire Header and Body Signatures] Property 50

6.7 [Security Header Layout] Property 50

6.7.1 Strict Layout Rules for WSS 1.0 50

7         Security Binding Assertions 52

7.1 AlgorithmSuite Assertion 52

7.2 Layout Assertion 54

7.3 TransportBinding Assertion 55

7.4 SymmetricBinding Assertion 56

7.5 AsymmetricBinding Assertion 58

8         Supporting Tokens 61

8.1 SupportingTokens Assertion 62

8.2 SignedSupportingTokens Assertion 63

8.3 EndorsingSupportingTokens Assertion 65

8.4 SignedEndorsingSupportingTokens Assertion 67

8.5 SignedEncryptedSupportingTokens Assertion 69

8.6 EncryptedSupportingTokens Assertion 69

8.7 EndorsingEncryptedSupportingTokens Assertion 69

8.8 SignedEndorsingEncryptedSupportingTokens Assertion 69

8.9 Interaction between [Token Protection] property and supporting token assertions 69

8.10 Example 70

9         WSS: SOAP Message Security Options 71

9.1 Wss10 Assertion 72

9.2 Wss11 Assertion 73

10       WS-Trust Options 75

10.1 Trust13 Assertion 76

11       Guidance on creating new assertions and assertion extensibility 78

11.1 General Design Points 78

11.2 Detailed Design Guidance 78

12       Security Considerations 80

A.       Assertions and WS-PolicyAttachment 81

A.1 Endpoint Policy Subject Assertions 81

A.1.1 Security Binding Assertions 81

A.1.2 Token Assertions 81

A.1.3 WSS: SOAP Message Security 1.0 Assertions 81

A.1.4 WSS: SOAP Message Security 1.1 Assertions 81

A.1.5 Trust 1.0 Assertions 81

A.2 Operation Policy Subject Assertions 81

A.2.1 Security Binding Assertions 81

A.2.2 Supporting Token Assertions 81

A.3 Message Policy Subject Assertions 82

A.3.1 Supporting Token Assertions 82

A.3.2 Protection Assertions 82

A.4 Assertions With Undefined Policy Subject 82

A.4.1 General Assertions 82

A.4.2 Token Usage Assertions 82

A.4.3 Token Assertions 82

B.       Issued Token Policy 84

C.       Strict Security Header Layout Examples 86

C.1 Transport Binding. 86

C.1.1 Policy 86

C.1.2 Initiator to Recipient Messages 87

C.1.3 Recipient to Initiator Messages 88

C.2 Symmetric Binding. 89

C.2.1 Policy 90

C.2.2 Initiator to Recipient Messages 91

C.2.3 Recipient to Initiator Messages 95

C.3 Asymmetric Binding. 98

C.3.1 Policy 98

C.3.2 Initiator to Recipient Messages 100

C.3.3 Recipient to Initiator Messages 104

D.       Signed and Encrypted Elements in the Security Header 108

D.1 Elements signed by the message signature 108

D.2 Elements signed by all endorsing signatures 108

D.3 Elements signed by a specific endorsing signature 108

D.4 Elements that are encrypted. 108

E.       Acknowledgements 109

 

 

WS-Policy defines a framework for allowing web services to express their constraints and requirements. Such constraints and requirements are expressed as policy assertions. This document defines a set of security policy assertions for use with the [WS-Policy] framework with respect to security features provided in WSS: SOAP Message Security [WSS10, WSS11], [WS-Trust] and [WS-SecureConversation]. The assertions defined within this specification have been designed to work independently of a specific version of WS-Policy. At the time of the publication of this specification the versions of WS-Policy known to correctly compose with this specification are WS-Policy 1.2 and 1.5. Within this specification the use of the namespace prefix wsp refers generically to the WS-Policy namespace, not a specific version. This document takes the approach of defining a base set of assertions that describe how messages are to be secured. Flexibility with respect to token types, cryptographic algorithms and mechanisms used, including using transport level security is part of the design and allows for evolution over time. The intent is to provide enough information for compatibility and interoperability to be determined by web service participants along with all information necessary to actually enable a participant to engage in a secure exchange of messages.

Sections 11, 12 and all examples and all Appendices are non-normative.

1.1 Example

Table 1 shows an "Effective Policy" example, including binding assertions and associated property assertions, token assertions and integrity and confidentiality assertions. This example has a scope of [Endpoint Policy Subject], but for brevity the attachment mechanism is not shown.

Table 1: Example security policy.

(01) <wsp:Policy xmlns:wsp="..." xmlns:sp="...">

(02)   <sp:SymmetricBinding>

(03)     <wsp:Policy>

(04)       <sp:ProtectionToken>

(05)         <wsp:Policy>

(06)           <sp:Kerberos sp:IncludeToken=".../IncludeToken/Once" />

(07)             <wsp:Policy>

(08)               <sp:WSSKerberosV5ApReqToken11/>

(09)             <wsp:Policy>

(10)           </sp:Kerberos>

(11)         </wsp:Policy>

(12)       </sp:ProtectionToken>

(13)       <sp:SignBeforeEncrypting />

(14)       <sp:EncryptSignature />

(15)     </wsp:Policy>

(16)   </sp:SymmetricBinding>

(17)   <sp:SignedParts>

(18)     <sp:Body/>

(19)     <sp:Header
       Namespace="http://schemas.xmlsoap.org/ws/2004/08/addressing"
    />

(20)   </sp:SignedParts>

(21)   <sp:EncryptedParts>

(22)     <sp:Body/>

(23)   </sp:EncryptedParts>

(24) </wsp:Policy>

 

Line 1 in Table 1 indicates that this is a policy statement and that all assertions contained by the wsp:Policy element are required to be satisfied. Line 2 indicates the kind of security binding in force. Line 3 indicates a nested wsp:Policy element which contains assertions that qualify the behavior of the SymmetricBinding assertion. Line 4 indicates a ProtectionToken assertion. Line 5 indicates a nested wsp:Policy element which contains assertions indicating the type of token to be used for the ProtectionToken. Lines 6 to 10 indicate that a Kerberos V5 APREQ token is to be used by both parties in a message exchange for protection. Line 13 indicates that signatures are generated over plaintext rather than ciphertext. Line 14 indicates that the signature over the signed messages parts is required to be encrypted. Lines 17-20 indicate which message parts are to be covered by the primary signature; in this case the soap:Body element, indicated by Line 18 and any SOAP headers in the WS-Addressing namespace, indicated by line 19. Lines 21-23 indicate which message parts are to be encrypted; in this case just the soap:Body element, indicated by Line 22.

1.2   Namespaces

The XML namespace URI that MUST be used by implementations of this specification is:

 

Table 2 lists XML namespaces that are used in this specification. The choice of any namespace prefix is arbitrary and not semantically significant.

Table 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-wssecurity-utility-1.0.xsd	[WSS10]
wsse	http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd	[WSS10]
wsse11	http://docs.oasis-open.org/wss/oasis-wss-wsecurity-secext-1.1.xsd	[WSS11]
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-secureconversation/200512	[WS-SecureConversation]
wsa	http://www.w3.org/2005/08/addressing	[WS-Addressing]
sp	http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702	This specification

1.3  Schema Files

A normative copy of the XML Schema [XML-Schema1, XML-Schema2] description for this specification can be retrieved from the following address:

1.4 Terminology

Policy - A collection of policy alternatives.

Policy Alternative - A collection of policy assertions.

Policy Assertion - An individual requirement, capability, other property, or a behavior.

Initiator - The role sending the initial message in a message exchange.

Recipient - The targeted role to process the initial message in a message exchange.

Security Binding - A set of properties that together provide enough information to secure a given message exchange.

Security Binding Property - A particular aspect of securing an exchange of messages.

Security Binding Assertion - A policy assertion that identifies the type of security binding being used to secure an exchange of messages.

Security Binding Property Assertion- A policy assertion that specifies a particular value for a particular aspect of securing an exchange of message.

Assertion Parameter - An element of variability within a policy assertion.

Token Assertion -Describes a token requirement. Token assertions defined within a security binding are used to satisfy protection requirements.

Supporting Token - A token used to provide additional claims.

1.4.1 Notational Conventions

The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” in this document are to be interpreted as described in [RFC2119].

This specification uses the following syntax to define outlines for assertions:

• The syntax appears as an XML instance, but values in italics indicate data types instead of literal values.
• Characters are appended to elements and attributes to indicate cardinality:
• • "?" (0 or 1)
  • "*" (0 or more)
  • "+" (1 or more)
• The character "|" is used to indicate a choice between alternatives.
• The characters "(" and ")" are used to indicate that contained items are to be treated as a group with respect to cardinality or choice.
• The characters "[" and "]" are used to call out references and property names.
• Ellipses (i.e., "...") indicate points of extensibility. Additional children and/or attributes MAY be added at the indicated extension points but MUST NOT contradict the semantics of the parent and/or owner, respectively. By default, if a receiver does not recognize an extension, the receiver SHOULD ignore the extension; exceptions to this processing rule, if any, are clearly indicated below.
• XML namespace prefixes (see Table 2) are used to indicate the namespace of the element being defined.

 

Elements and Attributes defined by this specification are referred to in the text of this document using XPath 1.0 expressions. Extensibility points are referred to using an extended version of this syntax:

• An element extensibility point is referred to using {any} in place of the element name. This indicates that any element name can be used, from any namespace other than the namespace of this specification.
• An attribute extensibility point is referred to using @{any} in place of the attribute name. This indicates that any attribute name can be used, from any namespace other than the namespace of this specification.

Extensibility points in the exemplar may notMAY NOT be described in the corresponding text.

In this document reference is made to the wsu:Idattribute and the wsu:Created and wsu:Expires elements in a utility schema ( http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd). The wsu:Idattribute and the wsu:Created and wsu:Expires elements were added to the utility schema with the intent that other specifications requiring such an ID type attribute or timestamp element could reference it (as is done here).

 

WS-SecurityPolicy is designed to work with the general Web Services framework including WSDL service descriptions, UDDI businessServices and bindingTemplates and SOAP message structure and message processing model, and WS-SecurityPolicy should SHOULD be applicable to any version of SOAP. The current SOAP 1.2 namespace URI is used herein to provide detailed examples, but there is no intention to limit the applicability of this specification to a single version of SOAP.

1.5 NormativeReferences

[RFC2119]                                    S. Bradner, "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, Harvard University, March 1997.

http://www.ietf.org/rfc/rfc2119.txt

 

[SOAP]                                        W3C Note, "SOAP: Simple Object Access Protocol 1.1", 08 May 2000.

http://www.w3.org/TR/2000/NOTE-SOAP-20000508/

 

[SOAP12]                                    W3C Recommendation, "SOAP 1.2 Part 1: Messaging Framework", 24 June 2003.

http://www.w3.org/TR/2003/REC-soap12-part1-20030624/

 

[SOAPNorm]                                W3C Working Group Note, "SOAP Version 1.2 Message Normalization”, 8 October 2003.

http://www.w3.org/TR/2003/NOTE-soap12-n11n-20031008/

 

[URI]                                            T. Berners-Lee, R. Fielding, L. Masinter, "Uniform Resource Identifiers (URI): Generic Syntax", RFC 3986, MIT/LCS, Day Software, Adobe Systems, January 2005.

http://www.ietf.org/rfc/rfc3986.txt

 

[RFC2068]                                    IETF Standard, "Hypertext Transfer Protocol -- HTTP/1.1" January 1997

http://www.ietf.org/rfc/rfc2068.txt

 

[RFC2246]                                    IETF Standard, "The TLS Protocol", January 1999.

http://www.ietf.org/rfc/rfc2246.txt

 

[SwA]                                          W3C Note, “SOAP Messages with Attachments”, 11 December 2000

http://www.w3.org/TR/2000/NOTE-SOAP-attachments-20001211

 

[WS-Addressing]                          W3C Recommendation, "Web Services Addressing (WS-Addressing)", 9 May 2006.

http://www.w3.org/TR/2006/REC-ws-addr-core-20060509

 

[WS-Policy]                                  W3C Member Submission "Web Services Policy 1.2 - Framework", 25 April 2006.

http://www.w3.org/Submission/2006/SUBM-WS-Policy-20060425/

W3C Candidate Recommendation “Web Services Policy 1.5 – Framework”, 28 February 2007

http://www.w3.org/TR/2007/CR-ws-policy-framework-20070228/

 

[WS-PolicyAttachment]                 W3C Member Submission "Web Services Policy 1.2 - Attachment", 25 April 2006.

http://www.w3.org/Submission/2006/SUBM-WS-PolicyAttachment-20060425/

W3C Candidate Recommendation “Web Services Policy 1.5 – Attachment”, 28 February 2007

http://www.w3.org/TR/2007/CR-ws-policy-attach-20070228/

 

[WS-Trust]                                    OASIS Committee Draft, "WS-Trust 1.3", September 2006

http://docs.oasis-open.org/ws-sx/ws-trust/200512

 

[WS-SecureConversation]             OASIS Committee Draft, “WS-SecureConversation 1.3", September 2006

http://docs.oasis-open.org/ws-sx/ws-secureconversation/200512

 

[WSS10]                                      OASIS Standard, "OASIS Web Services Security: SOAP Message Security 1.0 (WS-Security 2004)", March 2004.

http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-soap-message-security-1.0.pdf

 

[WSS11]                                      OASIS Standard, "OASIS Web Services Security: SOAP Message Security 1.1 (WS-Security 2004)", February 2006.

http://www.oasis-open.org/committees/download.php/16790/wss-v1.1-spec-os-SOAPMessageSecurity.pdf

 

[WSS:UsernameToken1.0]            OASIS Standard, "Web Services Security: UsernameToken Profile", March 2004

http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-username-token-profile-1.0.pdf

 

[WSS:UsernameToken1.1]            OASIS Standard, "Web Services Security: UsernameToken Profile 1.1", February 2006

http://www.oasis-open.org/committees/download.php/16782/wss-v1.1-spec-os-UsernameTokenProfile.pdf

 

[WSS:X509Token1.0]                    OASIS Standard, "Web Services Security X.509 Certificate Token Profile", March 2004

http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-x509-token-profile-1.0.pdf

 

[WSS:X509Token1.1]                    OASIS Standard, "Web Services Security X.509 Certificate Token Profile", February 2006

http://www.oasis-open.org/committees/download.php/16785/wss-v1.1-spec-os-x509TokenProfile.pdf

 

[WSS:KerberosToken1.1]              OASIS Standard, “Web Services Security Kerberos Token Profile 1.1”, February 2006

http://www.oasis-open.org/committees/download.php/16788/wss-v1.1-spec-os-KerberosTokenProfile.pdf

 

[WSS:SAMLTokenProfile1.0]        OASIS Standard, “Web Services Security: SAML Token Profile”, December 2004

http://docs.oasis-open.org/wss/oasis-wss-saml-token-profile-1.0.pdf

 

[WSS:SAMLTokenProfile1.1]        OASIS Standard, “Web Services Security: SAML Token Profile 1.1”, February 2006

http://www.oasis-open.org/committees/download.php/16768/wss-v1.1-spec-os-SAMLTokenProfile.pdf

 

[WSS:RELTokenProfile1.0]           OASIS Standard, “Web Services Security Rights Expression Language (REL) Token Profile”, December 2004

http://docs.oasis-open.org/wss/oasis-wss-rel-token-profile-1.0.pdf

 

[WSS:RELTokenProfile1.1]           OASIS Standard, “Web Services Security Rights Expression Language (REL) Token Profile 1.1”, February 2006

http://www.oasis-open.org/committees/download.php/16687/oasis-wss-rel-token-profile-1.1.pdf

 

[WSS:SwAProfile1.1]                    OASIS Standard, “Web Services Security SOAP Messages with Attachments (SwA) Profile 1.1”, February 2006

http://www.oasis-open.org/committees/download.php/16672/wss-v1.1-spec-os-SwAProfile.pdf

 

[XML-Encrypt]                              W3C Recommendation, "XML Encryption Syntax and Processing", 10 December 2002.

http://www.w3.org/TR/2002/REC-xmlenc-core-20021210/

 

[XML-Signature]                           W3C Recommendation, "XML-Signature Syntax and Processing", 12 February 2002.    

http://www.w3.org/TR/2002/REC-xmlenc-core-20021210/

 

[XPATH]                                      W3C Recommendation "XML Path Language (XPath) Version 1.0", 16 November 1999.

http://www.w3.org/TR/1999/REC-xpath-19991116

 

[XML-Schema1]                            W3C Recommendation, "XML Schema Part 1: Structures Second Edition", 28 October 2004.

http://www.w3.org/TR/2004/REC-xmlschema-1-20041028/

 

[XML-Schema2]                            W3C Recommendation, "XML Schema Part 2: Datatypes Second Edition", 28 October 2004.

http://www.w3.org/TR/2004/REC-xmlschema-2-20041028/

 

1.6 Non-Normative References

None.

 

This specification defines policy assertions for the security properties for Web services. These assertions are primarily designed to represent the security characteristics defined in the WSS: SOAP Message Security [WSS10] [WSS11], [WS-Trust] and [WS-SecureConversation] specifications, but they can also be used for describing security requirements at a more general or transport-independent level.

 

The primary goal of this specification is to define an initial set of patterns or sets of assertions that represent common ways to describe how messages are secured on a communication path.  The intent is to allow flexibility in terms of the tokens, cryptography, and mechanisms used, including leveraging transport security, but to be specific enough to ensure interoperability based on assertion matching.

 

It is a goal of the security policy model to leverage the WS-Policy framework’s intersection algorithm for selecting policy alternatives and the attachment mechanism for associating policy assertions with web service artifacts.  Consequently, wherever possible, the security policy assertions do not use parameters or attributes. This enables first-level, QName based assertion matching without security domain-specific knowledge to be done at the framework level. The first level matching is intended to provide a narrowed set of policy alternatives that are shared by the two parties attempting to establish a secure communication path.Parameters defined by this specification represent additional information for engaging behaviors that do not need to participate in matching. When multiple security policy assertions of the same type with parameters present occur in the same policy alternative the parameters should be treated as a union.  Note that a service maychoose to accept messages that do not matchits policy.

 

In general, assertions defined in this specification allow additional attributes, based on schemas, to be added on to the assertion element as an extensibility mechanism but the WS-Policy framework will not match based on these attributes. Attributes specified on the assertion element that are not defined in this specification or in WS-Policy are to be treated as informational properties.

2.1 Security Assertion Model

The goal to provide richer semantics for combinations of security constraints and requirements and enable first-level QName matching, is enabled by the assertions defined in this specification being separated into simple patterns: what parts of a message are being secured (Protection Assertions), general aspects or pre-conditions of the security (Conditional Assertions), the security mechanism (Security Binding Assertions) that is used to provide the security, the token types and usage patterns (Supporting Token Assertions) used to provide additional claims, and token referencing and trust options (WSS and Trust Assertions).

 

To indicate the scope of protection, assertions identify message parts that are to be protected in a specific way, such as integrity or confidentiality protection, and are referred to as protection assertions.

 

The general aspects of security includes the relationships between or characteristics of the environment in which security is being applied, such as the tokens being used, which are for integrity or confidentiality protection and which are supporting, the applicable algorithms to use, etc.

 

The security binding assertion is a logical grouping which defines how the general aspects are used to protect the indicated parts.  For example, that an asymmetric token is used with a digital signature to provide integrity protection, and that parts are encrypted with a symmetric key which is then encrypted using the public key of the recipient.  At its simplest form, the security binding restricts what can be placed in the wsse:Security header and the associated processing rules.

 

The intent of representing characteristics as assertions is so that QName matching will be sufficient to find common alternatives and so that many aspects of security can be factored out and re-used.  For example, it may be common that the mechanism is constant for an endpoint, but that the parts protected vary by message action.

2.2  Nested Policy Assertions

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

2.3   Security Binding Abstraction

As previously indicated, individual assertions are designed to be used in multiple combinations. The binding represents common usage patterns for security mechanisms.  These Security Binding assertions are used to determine how the security is performed and what to expect in the wsse:Securityheader.

Bindings are described textually and enforced programmatically.  This specification defines several bindings but others can be defined and agreed to for interoperability if participating parties support it.

 

A binding defines the following security characteristics:

·         The minimum set of tokens that will be used and how they are bound to messages. Note that services might accept messages containing more tokens than those specified in policy.

·         Any necessary key transport mechanisms

·         Any required REQUIRED message elements (e.g. timestamps) in the wsse:Security header.

·         The content and ordering of elements in the wsse:Security header. Elements not specified in the binding are not allowed.

·         Various parameters, including those describing the algorithms to be used for canonicalization, signing and encryption.

 

Together the above pieces of information, along with the assertions describing conditions and scope, provide enough information to secure messages between an initiator and a recipient. A policy consumer has enough information to construct messages that conform to the service's policy and to process messages returned by the service. Note that a service may MAY choose to reject messages despite them conforming to its policy, for example because a client certificate has been revoked. Note also that a service may MAY choose to accept messages that do not conform to its policy.

 

The following list identifies the bindings defined in this specification.  The bindings are identified primarily by the style of encryption used to protect the message exchange. A later section of this document provides details on the assertions for these bindings.

·         TransportBinding (Section 7.3)

·         SymmetricBinding (Section 7.4)

·         AsymmetricBinding (Section 7.5)

The following sections discuss details of WS-Policy and WS-PolicyAttachment relevant to this specification.

3.1   Nested Policy

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

 

3.2 Policy Subjects

WS-PolicyAttachment defines various attachment points for policy. This section defines properties that are referenced later in this document describing the recommended RECOMMENDED or required REQUIRED attachment points for various assertions. In addition, Appendix A groups the various assertions according to policy subject.

Note: This specification does not define any assertions that have a scope of [Service Policy Subject].

[Message Policy Subject]

This property identifies a Message Policy Subject [WS-PolicyAttachment]. WS-PolicyAttachment defines seven WSDL [WSDL 1.1] policy attachment points with Message Policy Subject:

 

wsdl:message

A policy expression containing one or more assertions with Message Policy Subject MUST NOT be attached to a wsdl:message.

wsdl:portType/wsdl:operation/wsdl:input, ./wsdl:output, or ./wsdl:fault

A policy expression containing one or more assertions with Message Policy Subject MUST NOT be attached to a descendant of wsdl:portType.

wsdl:binding/wsdl:operation/wsdl:input, ./wsdl:output, or ./wsdl:fault

A policy expression containing one or more of the assertions with Message Policy Subject MUST be attached to a descendant of wsdl:binding.

[Operation Policy Subject]

A token assertion with Operation Policy Subject indicates usage of the token on a per-operation basis:

wsdl:portType/wsdl:operation

A policy expression containing one or more token assertions MUST NOT be attached to a wsdl:portType/wsdl:operation.

wsdl:binding/wsdl:operation

A policy expression containing one or more token assertions MUST be attached to a wsdl:binding/wsdl:operation.

 

 

[Endpoint Policy Subject]

A token assertion instance with Endpoint Policy Subject indicates usage of the token for the entire set of messages described for the endpoint:

wsdl:portType

A policy expression containing one or more assertions with Endpoint Policy Subject MUST NOT be attached to a wsdl:portType.

wsdl:binding

A policy expression containing one or more of the assertions with Endpoint Policy Subject SHOULD be attached to a wsdl:binding.

wsdl:port

A policy expression containing one or more of the assertions with Endpoint Policy Subject MAY be attached to a wsdl:port

The following assertions are used to identify what is being protected and the level of protection provided. These assertions SHOULD apply to [Message Policy Subject]. These assertions MAY apply to [Endpoint Policy Subject] or [Operation Policy Subject]. Where they apply to [Operation Policy Subject] they apply to all messages of that operation. Where they apply to [Endpoint Policy Subject] they apply to all operations of that endpoint.

Note that when assertions defined in this section are present in a policy, the order of those assertions in that policy has no effect on the order of signature and encryption operations (see Section 6.3).

4.1 Integrity Assertions

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

4.1.1 SignedParts Assertion

The SignedParts assertion is used to specify the parts of the message outside of security headers that require integrity protection. This assertion can be satisfied using WSS: SOAP Message Security mechanisms or by mechanisms out of scope of SOAP message security, for example by sending the message over a secure transport protocol like HTTPS.  The binding specific token properties detail the exact mechanism by which the protection is provided.

 

There MAY be multiple SignedParts assertions present. Multiple SignedParts assertions present within a policy alternative are equivalent to a single SignedParts assertion containing the union of all specified message parts. Note that this assertion does not require that a given part appear in a message, just that if such a part appears, it requires integrity protection.

Syntax

 

The following describes the attributes and elements listed in the schema outlined above:

/sp:SignedParts

This assertion specifies the parts of the message that need integrity protection. If no child elements are specified, all message headers targeted at the UltimateReceiver role [SOAP12] or actor [SOAP11] and the body of the message MUST be integrity protected.

/sp:SignedParts/sp:Body

Presence of this optionalOPTIONAL empty element indicates that the entire body, that is the soap:Body element, it's attributes and content, of the message needs to be integrity protected.

/sp:SignedParts/sp:Header

Presence of this optionalOPTIONAL element indicates a specific SOAP header, its attributes and content (or set of such headers) needs to be protected. There may be multiple sp:Header elements within a single sp:SignedParts element. If multiple SOAP headers with the same local name but different namespace names are to be integrity protected multiple sp:Header elements are needed, either as part of a single sp:SignedParts assertion or as part of separate sp:SignedParts assertions.
This element only applies to SOAP header elements targeted to the same actor/role as the Security header impacted by the policy. If it is necessary to specify a requirement to sign specific SOAP Header elements targeted to a different actor/role, that may be accomplished using the sp:SignedElements assertion.

/sp:SignedParts/sp:Header/@Name

This optionalOPTIONAL attribute indicates the local name of the SOAP header to be integrity protected. If this attribute is not specified, all SOAP headers whose namespace matches the Namespace attribute are to be protected.

/sp:SignedParts/sp:Header/@Namespace

This requiredREQUIRED attribute indicates the namespace of the SOAP header(s) to be integrity protected.

/sp:SignedParts/sp:Attachments

Presence of this optionalOPTIONAL empty element indicates that all SwA (SOAP Messages with Attachments) attachments [SwA] are to be integrity protected. When SOAP Message Security is used to accomplish this, all message parts other than the part containing the primary SOAP envelope are to be integrity protected as outlined in WSS: SOAP Message Security [WSS:SwAProfile1.1].

4.1.2 SignedElements Assertion

The SignedElements assertion is used to specify arbitrary elements in the message that require integrity protection. This assertion can be satisfied using WSS: SOAP Message Security mechanisms or by mechanisms out of scope of SOAP message security, for example by sending the message over a secure transport protocol like HTTPS.  The binding specific token properties detail the exact mechanism by which the protection is provided.

 

There MAY be multiple SignedElements assertions present. Multiple SignedElements assertions present within a policy alternative are equivalent to a single SignedElements assertion containing the union of all specified XPath expressions.

Syntax

The following describes the attributes and elements listed in the schema outlined above:

/sp:SignedElements

This assertion specifies the parts of the message that need integrity protection.

/sp:SignedElements/@XPathVersion

This optionalOPTIONAL attribute contains a URI which indicates the version of XPath to use. If no attribute is provided, then XPath 1.0 is assumed.

/sp:SignedElements/sp:XPath

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

4.2 Confidentiality Assertions

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

4.2.1 EncryptedParts Assertion

The EncryptedParts assertion is used to specify the parts of the message that require confidentiality. This assertion can be satisfied with WSS: SOAP Message Security mechanisms or by mechanisms out of scope of SOAP message security, for example by sending the message over a secure transport protocol like HTTPS.  The binding specific token properties detail the exact mechanism by which the protection is provided.

 

There MAY be multiple EncryptedParts assertions present. Multiple EncryptedParts assertions present within a policy alternative are equivalent to a single EncryptedParts assertion containing the union of all specified message parts. Note that this assertion does not require that a given part appear in a message, just that if such a part appears, it requires confidentiality protection.

Syntax

 

The following describes the attributes and elements listed in the schema outlined above:

/sp:EncryptedParts

This assertion specifies the parts of the message that need confidentiality protection. The single child element of this assertion specifies the set of message parts using an extensible dialect.

If no child elements are specified, the body of the message MUST be confidentiality protected.

/sp:EncryptedParts/sp:Body

Presence of this optionalOPTIONAL empty element indicates that the entire body of the message needs to be confidentiality protected. In the case where mechanisms from WSS: SOAP Message Security are used to satisfy this assertion, then the soap:Body element is encrypted using the #Content encryption type.

/sp:EncryptedParts/sp:Header

Presence of this optionalOPTIONAL element indicates that a specific SOAP header (or set of such headers) needs to be protected. There may be multiple sp:Header elements within a single Parts element. Each header or set of headers MUST be encrypted. Such encryption will encrypt such elements using WSS 1.1 Encrypted Headers. As such, if WSS 1.1 Encrypted Headers are not supported by a service, then this element cannot be used to specify headers that require encryption using message level security. If multiple SOAP headers with the same local name but different namespace names are to be encrypted then multiple sp:Header elements are needed, either as part of a single sp:EncryptedParts assertion or as part of separate sp:EncryptedParts assertions.

/sp:EncryptedParts/sp:Header/@Name

This optionalOPTIONAL attribute indicates the local name of the SOAP header to be confidentiality protected. If this attribute is not specified, all SOAP headers whose namespace matches the Namespace attribute are to be protected.

/sp:EncryptedParts/sp:Header/@Namespace

This requiredREQUIRED attribute indicates the namespace of the SOAP header(s) to be confidentiality protected.

/sp:EncryptedParts/sp:Attachments

Presence of this optionalOPTIONAL empty element indicates that all SwA (SOAP Messages with Attachments) attachments [SwA] are to be confidentiality protected. When SOAP Message Security is used to accomplish this, all message parts other than the part containing the primary SOAP envelope are to be confidentiality protected as outlined in WSS: SOAP Message Security [WSS:SwAProfile1.1].

4.2.2 EncryptedElements Assertion

The EncryptedElements assertion is used to specify arbitrary elements in the message that require confidentiality protection. This assertion can be satisfied using WSS: SOAP Message Security mechanisms or by mechanisms out of scope of SOAP message security, for example by sending the message over a secure transport protocol like HTTPS.  The binding specific token properties detail the exact mechanism by which the protection is provided.

 

There MAY be multiple EncryptedElements assertions present. Multiple EncryptedElements assertions present within a policy alternative are equivalent to a single EncryptedElements assertion containing the union of all specified XPath expressions.

Syntax

The following describes the attributes and elements listed in the schema outlined above:

/sp:EncryptedElements

This assertion specifies the parts of the message that need confidentiality protection. Any such elements are subject to #Element encryption.

/sp:EncryptedElements/@XPathVersion

This optionalOPTIONAL attribute contains a URI which indicates the version of XPath to use. If no attribute is provided, then XPath 1.0 is assumed.

/sp:EncryptedElements/sp:XPath

This element contains a string specifying an XPath expression that identifies the nodes to be confidentiality protected. The XPath expression is evaluated against the S:Envelope element node of the message. Multiple instances of this element may MAY appear within this assertion and should SHOULD be treated as separate references.

4.2.3 ContentEncryptedElements Assertion

The ContentEncryptedElements assertion is used to specify arbitrary elements in the message that require confidentiality protection of their content. This assertion can be satisfied using WSS: SOAP Message Security mechanisms or by mechanisms out of scope of SOAP message security, for example by sending the message over a secure transport protocol like HTTPS.  The binding specific token properties detail the exact mechanism by which the protection is provided.

 

There MAY be multiple ContentEncryptedElements assertions present. Multiple ContentEncryptedElements assertions present within a policy alternative are equivalent to a single ContentEncryptedElements assertion containing the union of all specified XPath expressions.

Syntax

The following describes the attributes and elements listed in the schema outlined above:

/sp:ContentEncryptedElements

This assertion specifies the parts of the message that need confidentiality protection. Any such elements are subject to #Content encryption.

/sp:ContentEncryptedElements/@XPathVersion

This optionalOPTIONAL attribute contains a URI which indicates the version of XPath to use.If no attribute is provided, then XPath 1.0 is assumed.

/sp:ContentEncryptedElements/sp:XPath

This element contains a string specifying an XPath expression that identifies the nodes to be confidentiality protected. The XPath expression is evaluated against the S:Envelope element node of the message. Multiple instances of this element MAY appear within this assertion and should SHOULD be treated as separate references.

4.3 Required Elements Assertion

A mechanism is defined for specifying, using XPath expressions, the set of header elements that a message MUST contain.

 

Note: Specifications are expected to provide domain specific assertions that specify which headers are expected in a message. This assertion is provided for cases where such domain specific assertions have not been defined.

4.3.1 RequiredElements Assertion

The RequiredElements assertion is used to specify header elements that the message MUST contain. This assertion specifies no security requirements.

 

There MAY be multiple RequiredElements assertions present. Multiple RequiredElements assertions present within a policy alternative are equivalent to a single RequiredElements assertion containing the union of all specified XPath expressions.

Syntax

 

The following describes the attributes and elements listed in the schema outlined above:

/sp:RequiredElements

This assertion specifies the headers elements that MUST appear in a message.

/sp:RequiredElements/@XPathVersion

This optionalOPTIONAL attribute contains a URI which indicates the version of XPath to use. If no attribute is provided, then XPath 1.0 is assumed.

/sp:RequiredElements/sp:XPath

This element contains a string specifying an XPath expression that identifies the header elements that a message MUST contain. The XPath expression is evaluated against the S:Envelope/S:Header element node of the message. Multiple instances of this element may MAY appear within this assertion and should SHOULD be treated as a combined XPath expression.

4.3.2 RequiredParts Assertion

RequiredParts is a QName based alternative to the RequiredElements assertion (which is based on XPATH) for specifying header elements that MUST be present in the message. This assertion specifies no security requirements.

 

There MAY be multiple RequiredParts assertions present. Multiple RequiredParts assertions present within a policy alternative are equivalent to a single RequiredParts assertion containing the union of all specified Header elements.

Syntax

 

The following describes the attributes and elements listed in the schema outlined above:

/sp:RequiredParts/sp:Header

This assertion specifies the headers elements that MUST be present in the message.

/sp:RequiredParts/sp:Header/@Name

This requiredREQUIRED attribute indicates the local name of the SOAPHeader that needs to be present in the message.

/sp:RequiredParts/sp:Header/@Namespace

This requiredREQUIRED attribute indicates the namespace of the SOAP header that needs to be present in the message.

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

5.1 Token Inclusion

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

5.1.1 Token Inclusion Values

The following table describes the set of valid token inclusion mechanisms supported by this specification:

http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702/IncludeToken/Never	The token MUST NOT be included in any messages sent between the initiator and the recipient; rather, an external reference to the token should SHOULD be used.
http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702/IncludeToken/Once	The token MUST be included in only one message 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 MAY refer to the token using an external reference mechanism.
http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702/IncludeToken/AlwaysToRecipient	The token MUST be included in all messages sent from initiator to the recipient. The token MUST NOT be included in messages sent from the recipient to the initiator.
http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702/IncludeToken/AlwaysToInitiator	The token MUST be included in all messages sent from the recipient to the initiator. The token MUST NOT be included in messages sent from the initiator to the recipient.
http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702/IncludeToken/Always	The token MUST be included in all messages sent between the initiator and the recipient. This is the default behavior.

 

Note: In examples, the namespace URI is replaced with "..." for brevity. For example, .../IncludeToken/Never is actually http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702/IncludeToken/Never. Other token inclusion URI values MAY be defined but are out-of-scope of this specification.

The default behavior characteristics defined by this specification if this attribute is not specified on a token assertion are .../IncludeToken/Always.

5.1.2 Token Inclusion and Token References

A token assertion may MAY carry a sp:IncludeToken attribute that requires that the token be included in the message. The Web Services Security specifications [WSS10, WSS11] define mechanisms for how tokens are included in a message.

Several Token assertions (see Section 5.3) support mechanisms for referencing tokens in addition to Direct References, for example external URI references or references using a Thumbprint.

Certain combination of sp:IncludeToken value and token reference assertions can result in a token appearing in a message more than once. For example, if a token assertion carries a sp:IncludeToken attribute with a value of '.../Always' and that token assertion also contains a nested sp:RequireEmbeddedTokenReference (see Section 5.3.3) assertion, then the token would be included twice in the message. While such combinations are not in error, they are probably best avoided for efficiency reasons.

If a token assertion contains multiple reference assertions, then references to that token are required REQUIRED to contain all the specified reference types. For example, if a token assertion contains nested sp:RequireIssuerSerialReference and sp:RequireThumbprintReference assertions then references to that token contain both reference forms. Again, while such combinations are not in error, they are probably best avoided for efficiency reasons.

5.2 Token Issuer and Required Claims

5.2.1 Token Issuer

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

5.2.2 Token Issuer Name

Any token assertion may MAY also carry an optional OPTIONAL sp:IssuerName element. The schema type of this element is xs:anyURI. This element indicated the token issuing authority by pointing to the issuer by using its logical name. This element is defined as a global element in the WS-SecurityPolicy namespace and is intended to be used by any specification that defines token assertions.

 

It is out of scope of this specification how the relationship between the issuer’s logical name and the physical manifestation of the issuer in the security token is defined.

While both sp:Issuer and sp:IssuerName elements are optional OPTIONAL they are also mutually exclusive and cannot be specified both at the same time.

5.2.3 Required Claims

Any token assertion may MAY also carry an optional OPTIONAL wst:Claims element. The element content is defined in the WS-Trust namespace. This specification does not further define or limit the content of this element or the wst:Claims/@Dialect attribute as it is out of scope of this document.

 

This element indicates the required REQUIRED claims that the security token must contain in order to satisfy the requirements of the token assertion.

 

Individual token assertions may MAY further limit what claims may MAY be specified for that specific token assertion.

5.2.4 Processing Rules and Token Matching

The sender is free to compose the requirements expressed by token assertions inside the receiver’s policy to as many tokens as it sees fit. As long as the union of all tokens in the received message contains the required REQUIRED set of claims from required REQUIRED token issuers the message is valid according to the receiver’s policy.

For example if the receiver’s policy contains two token assertions, one requires IssuedToken from issuer A with claims C1 and C2 and the second requires IssuedToken from issuer B with claims C3 and C4, the sender can satisfy such requirements with any of the following security token decomposition:

 

1. Two tokens, T1 and T2. T1 is issued by issuer A and contains claims C1 and C2 and T2 is issued by issuer B and contains claims C3 and C4.
2. Three tokens, T1, T2 and T3. T1 is issued by issuer A and contains claim C1, T2 is also issued by issuer A and contains claim C2 and T3 is issued by issuer B and contains claims C3 and C4.
3. Three tokens, T1, T2 and T3. T1 is issued by issuer A and contains claims C1 and C2, T2 is issued by issuer B and contains claim C3 and T3 is also issued by issuer B and contains claim C4.
4. Four tokens, T1, T2, T3 and T4. T1 is issued by issuer A and contains claim C1, T2 is also issued by issuer A and contains claim C2, T3 is issued by issuer B and contains claim C3 and T4 is also issued by issuer B and contains claim C4.

5.3 Token Properties

5.3.1 [Derived Keys] Property

This boolean property specifies whether derived keys should SHOULD be used as defined in WS-SecureConversation. If the value is 'true', derived keys MUST be used. If the value is 'false', derived keys MUST NOT be used. The value of this property applies to a specific token. The value of this property is populated by assertions specific to the token. The default value for this property is 'false'.

See the [Explicit Derived Keys] and [Implied Derived Key] properties below for information on how particular forms of derived keys are specified.

Where the key material associated with a token is asymmetric, this property applies to the use of symmetric keys encrypted with the key material associated with the token.

5.3.2 [Explicit Derived Keys] Property

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

5.3.3 [Implied Derived Keys] Property

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

5.4 Token Assertion Types

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

5.4.1 UsernameToken Assertion

This element represents a requirement to include a username token.

There are cases where encrypting the UsernameToken is reasonable. For example:

1.     When transport security is not used.

2.     When a plaintext password is used.

3.     When a weak password hash is used.

4.     When the username needs to be protected, e.g. for privacy reasons.

When the UsernameToken is to be encrypted it SHOULD be listed as a SignedEncryptedSupportingToken (Section 8.5), EndorsingEncryptedSupportingToken (Section 8.6) or SignedEndorsingEncryptedSupportingToken (Section 8.7).

 

Syntax

 

The following describes the attributes and elements listed in the schema outlined above:

/sp:UsernameToken

This identifies a UsernameToken assertion.

/sp:UsernameToken/@sp:IncludeToken

This optionalOPTIONAL attribute identifies the token inclusion value for this token assertion.

/sp:UsernameToken/sp:Issuer

This optionalOPTIONAL element, of type wsa:EndpointReferenceType, contains reference to the issuer of the sp:UsernameToken.

/sp:UsernameToken/sp:IssuerName

This optionalOPTIONAL element, of type xs:anyURI, contains the logical name of the sp:UsernameToken issuer.

/sp:UsernameToken/wst:Claims

This optionalOPTIONAL element identifies the requiredREQUIRED claims that a security token must contain in order to satisfy the token assertion requirements.

/sp:UsernameToken/wsp:Policy

This requiredREQUIRED element identifies additional requirements for use of the sp:UsernameToken assertion.

/sp:UsernameToken/wsp:Policy/sp:NoPassword

This optionalOPTIONAL element is a policy assertion that indicates that the wsse:Password element MUST NOT be present in the Username token.

/sp:UsernameToken/wsp:Policy/sp:HashPassword

This optionalOPTIONAL element is a policy assertion that indicates that the wsse:Password element MUST be present in the Username token and that the content of the wsse:Password element MUST contain a hash of the timestamp, nonce and password as defined in [WSS: Username Token Profile].

/sp:UsernameToken/wsp:Policy/sp:RequireDerivedKeys

This optionalOPTIONAL element is a policy assertion that sets the [Derived Keys], [Explicit Derived Keys] and [Implied Derived Keys] properties for this token to 'true'.

/sp:UsernameToken/wsp:Policy/sp:RequireExplicitDerivedKeys

This optionalOPTIONAL element is a policy assertion that sets the [Derived Keys] and [Explicit Derived Keys] properties for this token to 'true' and the [Implied Derived Keys] property for this token to 'false'.

/sp:UsernameToken/wsp:Policy/sp:RequireImpliedDerivedKeys

This optionalOPTIONAL element is a policy assertion that sets the [Derived Keys] and [Implied Derived Keys] properties for this token to 'true' and the [Explicit Derived Keys] property for this token to 'false'.

/sp:UsernameToken/wsp:Policy/sp:WssUsernameToken10

This optionalOPTIONAL element is a policy assertion that indicates that a Username token should be used as defined in [WSS:UsernameTokenProfile1.0].

/sp:UsernameToken/wsp:Policy/sp:WssUsernameToken11

This optionalOPTIONAL element is a policy assertion that indicates that a Username token should be used as defined in [WSS:UsernameTokenProfile1.1].

5.4.2 IssuedToken Assertion

This element represents a requirement for an issued token, which is one issued by some token issuer using the mechanisms defined in WS-Trust. This assertion is used in 3^rd party scenarios. For example, the initiator may need to request a SAML token from a given token issuer in order to secure messages sent to the recipient.

Syntax

The following describes the attributes and elements listed in the schema outlined above:

/sp:IssuedToken

This identifies an IssuedToken assertion.

/sp:IssuedToken/@sp:IncludeToken

This optionalOPTIONAL attribute identifies the token inclusion value for this token assertion.

/sp:IssuedToken/sp:Issuer

This optionalOPTIONAL element, of type wsa:EndpointReferenceType, contains a reference to the issuer for the issued token.

/sp:IssuedToken/sp:IssuerName

This optionalOPTIONAL element, of type xs:anyURI, contains the logical name of the sp:IssuedToken issuer.

/sp:IssuedToken/wst:Claims

This optionalOPTIONAL element identifies the requiredREQUIRED claims that a security token must contain in order to satisfy the token assertion requirements.

/sp:IssuedToken/sp:RequestSecurityTokenTemplate

This requiredREQUIRED element contains elements which MUST be copied into the wst:SecondaryParameters of the RST request sent to the specified issuer. Note: the initiator is not NOT requiredREQUIRED to understand the contents of this element.

See Appendix B for details of the content of this element.

/sp:IssuedToken/sp:RequestSecurityTokenTemplate/@TrustVersion

This optionalOPTIONAL attribute contains a WS-Trust specification namespace URI identifying the version of WS-Trust referenced by the contents of this element.

/sp:IssuedToken/wsp:Policy

This requiredREQUIRED element identifies additional requirements for use of the sp:IssuedToken assertion.

/sp:IssuedToken/wsp:Policy/sp:RequireDerivedKeys

This optionalOPTIONAL element is a policy assertion that sets the [Derived Keys], [Explicit Derived Keys] and [Implied Derived Keys]   properties for this token to 'true'.

/sp:IssuedToken/wsp:Policy/sp:RequireExplicitDerivedKeys

This optionalOPTIONAL element is a policy assertion that sets the [Derived Keys] and [Explicit Derived Keys] properties for this token to 'true' and the [Implied Derived Keys] property for this token to 'false'.

/sp:IssuedToken/wsp:Policy/sp:RequireImpliedDerivedKeys

This optionalOPTIONAL element is a policy assertion that sets the [Derived Keys] and [Implied Derived Keys] properties for this token to 'true' and the [Explicit Derived Keys] property for this token to 'false'.

/sp:IssuedToken/wsp:Policy/sp:RequireInternalReference

This optionalOPTIONAL element is a policy assertion that indicates whether an internal reference is requiredREQUIRED when referencing this token.
Note: This reference will be supplied by the issuer of the token.

/sp:IssuedToken/wsp:Policy/sp:RequireExternalReference

This optionalOPTIONAL element is a policy assertion that indicates whether an external reference is requiredREQUIRED when referencing this token.
Note: This reference will be supplied by the issuer of the token.

Note: The IssuedToken may MAY or may notMAY NOT be associated with key material and such key material may be symmetric or asymmetric. The Binding assertion will imply the type of key associated with this token. Services may MAY also include information in the sp:RequestSecurityTokenTemplate element to explicitly define the expected key type. See Appendix Bfor details of the sp:RequestSecurityTokenTemplate element.

5.4.3 X509Token Assertion

This element represents a requirement for a binary security token carrying an X509 token.

Syntax

 

The following describes the attributes and elements listed in the schema outlined above:

/sp:X509Token

This identifies an X509Token assertion.

/sp:X509Token/@sp:IncludeToken

This optionalOPTIONAL attribute identifies the token inclusion value for this token assertion.

/sp:X509Token/sp:Issuer

This optionalOPTIONAL element, of type wsa:EndpointReferenceType, contains reference to the issuer of the sp:X509Token.

/sp:X509Token/sp:IssuerName

This optionalOPTIONAL element, of type xs:anyURI, contains the logical name of the sp:X509Token issuer.

/sp:X509Token/wst:Claims

This optionalOPTIONAL element identifies the requiredREQUIRED claims that a security token must contain in order to satisfy the token assertion requirements.

/sp:X509Token/wsp:Policy

This requiredREQUIRED element identifies additional requirements for use of the sp:X509Token assertion.

/sp:X509Token/wsp:Policy/sp:RequireDerivedKeys

This optionalOPTIONAL element is a policy assertion that sets the [Derived Keys], [Explicit Derived Keys] and [Implied Derived Keys] properties for this token to 'true'.

/sp:X509Token/wsp:Policy/sp:RequireExplicitDerivedKeys

This optionalOPTIONAL element is a policy assertion that sets the [Derived Keys] and [Explicit Derived Keys] properties for this token to 'true' and the [Implied Derived Keys] property for this token to 'false'.

/sp:X509Token/wsp:Policy/sp:RequireImpliedDerivedKeys

This optionalOPTIONAL element is a policy assertion that sets the [Derived Keys] and [Implied Derived Keys] properties for this token to 'true' and the [Explicit Derived Keys] property for this token to 'false'.

/sp:X509Token/wsp:Policy/sp:RequireKeyIdentifierReference

This optionalOPTIONAL element is a policy assertion that indicates that a key identifier reference is requiredREQUIRED when referencing this token.

/sp:X509Token/wsp:Policy/sp:RequireIssuerSerialReference

This optionalOPTIONAL element is a policy assertion that indicates that an issuer serial reference is requiredREQUIRED when referencing this token.

/sp:X509Token/wsp:Policy/sp:RequireEmbeddedTokenReference

This optionalOPTIONAL element is a policy assertion that indicates that an embedded token reference is requiredREQUIRED when referencing this token.

/sp:X509Token/wsp:Policy/sp:RequireThumbprintReference

This optionalOPTIONAL element is a policy assertion that indicates that a thumbprint reference is requiredREQUIRED when referencing this token.

/sp:X509Token/wsp:Policy/sp:WssX509V3Token10

This optionalOPTIONAL element is a policy assertion that indicates that an X509 Version 3 token should be used as defined in [WSS:X509TokenProfile1.0].

/sp:X509Token/wsp:Policy/sp:WssX509Pkcs7Token10

This optionalOPTIONAL element is a policy assertion that indicates that an X509 PKCS7 token should be used as defined in [WSS:X509TokenProfile1.0].

/sp:X509Token/wsp:Policy/sp:WssX509PkiPathV1Token10

This optionalOPTIONAL element is a policy assertion that indicates that an X509 PKI Path Version 1 token should be used as defined in [WSS:X509TokenProfile1.0].

/sp:X509Token/wsp:Policy/sp:WssX509V1Token11

This optionalOPTIONAL element is a policy assertion that indicates that an X509 Version 1 token should be used as defined in [WSS:X509TokenProfile1.1].

/sp:X509Token/wsp:Policy/sp:WssX509V3Token11

This optionalOPTIONAL element is a policy assertion that indicates that an X509 Version 3 token should be used as defined in [WSS:X509TokenProfile1.1].

/sp:X509Token/wsp:Policy/sp:WssX509Pkcs7Token11

This optionalOPTIONAL element is a policy assertion that indicates that an X509 PKCS7 token should be used as defined in [WSS:X509TokenProfile1.1].

/sp:X509Token/wsp:Policy/sp:WssX509PkiPathV1Token11

This optionalOPTIONAL element is a policy assertion that indicates that an X509 PKI Path Version 1 token should be used as defined in [WSS:X509TokenProfile1.1].

5.4.4 KerberosToken Assertion

This element represents a requirement for a Kerberos token [WSS:KerberosToken1.1].

Syntax

 

The following describes the attributes and elements listed in the schema outlined above:

/sp:KerberosToken

This identifies a KerberosV5ApReqToken assertion.

/sp:KerberosToken/@sp:IncludeToken

This optionalOPTIONAL attribute identifies the token inclusion value for this token assertion.

/sp:KerberosToken/sp:Issuer

This optionalOPTIONAL element, of type wsa:EndpointReferenceType, contains reference to the issuer of the sp:KerberosToken.

/sp:KerberosToken/sp:IssuerName

This optionalOPTIONAL element, of type xs:anyURI, contains the logical name of the sp:KerberosToken issuer.

/sp:KerberosToken/wst:Claims

This optionalOPTIONAL element identifies the requiredREQUIRED claims that a security token must contain in order to satisfy the token assertion requirements.

/sp:KerberosToken/wsp:Policy

This requiredREQUIRED element identifies additional requirements for use of the sp:KerberosToken assertion.

/sp:KerberosToken/wsp:Policy/sp:RequireDerivedKeys

This optionalOPTIONAL element is a policy assertion that sets the [Derived Keys], [Explicit Derived Keys] and [Implied Derived Keys] properties for this token to 'true'.

/sp:KerberosToken/wsp:Policy/sp:RequireExplicitDerivedKeys

This optionalOPTIONAL element is a policy assertion that sets the [Derived Keys] and [Explicit Derived Keys] properties for this token to 'true' and the [Implied Derived Keys] property for this token to 'false'.

/sp:KerberosToken/wsp:Policy/sp:RequireImpliedDerivedKeys

This optionalOPTIONAL element is a policy assertion that sets the [Derived Keys] and [Implied Derived Keys] properties for this token to 'true' and the [Explicit Derived Keys] property for this token to 'false'.

/sp:KerberosToken/wsp:Policy/sp:RequireKeyIdentifierReference

This optionalOPTIONAL element is a policy assertion that indicates that a key identifier reference is requiredREQUIRED when referencing this token.

/sp:KerberosToken/wsp:Policy/sp:WssKerberosV5ApReqToken11

This optionalOPTIONAL element is a policy assertion that indicates that a Kerberos Version 5 AP-REQ token should be used as defined in [WSS:KerberosTokenProfile1.1].

/sp:KerberosToken/wsp:Policy/sp:WssGssKerberosV5ApReqToken11

This optionalOPTIONAL element is a policy assertion that indicates that a GSS Kerberos Version 5 AP-REQ token should be used as defined in [WSS:KerberosTokenProfile1.1].

5.4.5 SpnegoContextToken Assertion

This element represents a requirement for a SecurityContextToken obtained by executing an n-leg RST/RSTR SPNEGO binary negotiation protocol with the Web Service, as defined in WS-Trust.

Syntax

 

The following describes the attributes and elements listed in the schema outlined above:

/sp:SpnegoContextToken

This identifies a SpnegoContextToken assertion.

/sp:SpnegoContextToken/@sp:IncludeToken

This optionalOPTIONAL attribute identifies the token inclusion value for this token assertion.

/sp:SpnegoContextToken/sp:Issuer

This optionalOPTIONAL element, of type wsa:EndpointReferenceType, contains a reference to the issuer for the Spnego Context Token.

/sp:SpnegoContextToken/sp:IssuerName

This optionalOPTIONAL element, of type xs:anyURI, contains the logical name of the sp:SpnegoContextToken issuer.

/sp:SpnegoContextToken/wst:Claims

This optionalOPTIONAL element identifies the requiredREQUIRED claims that a security token must contain in order to satisfy the token assertion requirements.

/sp:SpnegoContextToken/wsp:Policy

This requiredREQUIRED element identifies additional requirements for use of the sp:SpnegoContextToken assertion.

/sp:SpnegoContextToken/wsp:Policy/sp:RequireDerivedKeys

This optionalOPTIONAL element is a policy assertion that sets the [Derived Keys], [Explicit Derived Keys] and [Implied Derived Keys] properties for this token to 'true'.

/sp:SpnegoContextToken/wsp:Policy/sp:RequireExplicitDerivedKeys

This optionalOPTIONAL element is a policy assertion that sets the [Derived Keys] and [Explicit Derived Keys] properties for this token to 'true' and the [Implied Derived Keys] property for this token to 'false'.

/sp:SpnegoContextToken/wsp:Policy/sp:RequireImpliedDerivedKeys

This optionalOPTIONAL element is a policy assertion that sets the [Derived Keys] and [Implied Derived Keys] properties for this token to 'true' and the [Explicit Derived Keys] property for this token to 'false'.

sp:SpnegoContextToken/wsp:Policy/sp:MustNotSendCancel

This optionalOPTIONAL element is a policy assertion that indicates that the STS issuing the SP/Nego token does not support SCT/Cancel RST messages. If this assertion is missing it means that SCT/Cancel RST messages are supported by the STS.

/sp:SpnegoContextToken/wsp:Policy/sp:MustNotSendAmend

This optionalOPTIONAL element is a policy assertion that indicates that the STS issuing the SP/Nego token does not support SCT/Amend RST messages. If this assertion is missing it means that SCT/Amend RST messages are supported by the STS.

/sp:SpnegoContextToken/wsp:Policy/sp:MustNotSendRenew

This optionalOPTIONAL element is a policy assertion that indicates that the STS issuing the SP/Nego token does not support SCT/Renew RST messages. If this assertion is missing it means that SCT/Renew RST messages are supported by the STS.

5.4.6 SecurityContextToken Assertion

This element represents a requirement for a SecurityContextToken token.

Syntax

 

The following describes the attributes and elements listed in the schema outlined above:

/sp:SecurityContextToken

This identifies a SecurityContextToken assertion.

/sp:SecurityContextToken/@sp:IncludeToken

This optionalOPTIONAL attribute identifies the token inclusion value for this token assertion.

/sp:SecurityContextToken/sp:Issuer

This optionalOPTIONAL element, of type wsa:EndpointReferenceType, contains reference to the issuer of the sp:SecurityContextToken.

/sp:SecurityContextToken/sp:IssuerName

This optionalOPTIONAL element, of type xs:anyURI, contains the logical name of the sp:SecurityContextToken issuer.

/sp:SecurityContextToken/wst:Claims

This optionalOPTIONAL element identifies the requiredREQUIRED claims that a security token must contain in order to satisfy the token assertion requirements.

/sp:SecurityContextToken/wsp:Policy

This requiredREQUIRED element identifies additional requirements for use of the sp:SecurityContextToken assertion.

/sp:SecurityContextToken/wsp:Policy/sp:RequireDerivedKeys

This optionalOPTIONAL element is a policy assertion that sets the [Derived Keys], [Explicit Derived Keys] and [Implied Derived Keys] properties for this token to 'true'.

/sp:SecurityContextToken/wsp:Policy/sp:RequireExplicitDerivedKeys

This optionalOPTIONAL element is a policy assertion that sets the [Derived Keys] and [Explicit Derived Keys] properties for this token to 'true' and the [Implied Derived Keys] property for this token to 'false'.

/sp:SecurityContextToken/wsp:Policy/sp:RequireImpliedDerivedKeys

This optionalOPTIONAL element is a policy assertion that sets the [Derived Keys] and [Implied Derived Keys] properties for this token to 'true' and the [Explicit Derived Keys] property for this token to 'false'.

/sp:SecurityContextToken/wsp:Policy/sp:RequireExternalUriReference

This optionalOPTIONAL element is a policy assertion that indicates that an external URI reference is requiredREQUIRED when referencing this token.

/sp:SecurityContextToken/wsp:Policy/sp:SC13SecurityContextToken

This optionalOPTIONAL element is a policy assertion that indicates that a Security Context Token should be used as defined in [WS-SecureConversation].

 

Note: This assertion does not describe how to obtain a Security Context Token but rather assumes that both parties have the token already or have agreed separately on a mechanism for obtaining the token. If a definition of the mechanism for obtaining the Security Context Token is desired in policy, then either the sp:SecureConversationToken or the sp:IssuedToken assertion should SHOULD be used instead.

5.4.7 SecureConversationToken Assertion

This element represents a requirement for a Security Context Token retrieved from the indicated issuer address. If the sp:Issuer address is absent, the protocol MUST be executed at the same address as the service endpoint address.

 

Note: This assertion describes the token accepted by the target service.  Because this token is issued by the target service and may notMAY NOT have a separate port (with separate policy), this assertion SHOULD contain a bootstrap policy indicating the security binding and policy that is used when requesting this token from the target service.  That is, the bootstrap policy is used to obtain the token and then the current (outer) policy is used when making requests with the token. This is illustrated in the diagram below.

Syntax

 

The following describes the attributes and elements listed in the schema outlined above:

/sp:SecureConversationToken

This identifies a SecureConversationToken assertion.

/sp:SecureConversationToken/@sp:IncludeToken

This optionalOPTIONAL attribute identifies the token inclusion value for this token assertion.

/sp:SecureConversationToken/sp:Issuer

This optionalOPTIONAL element, of type wsa:EndpointReferenceType, contains a reference to the issuer for the Security Context Token.

/sp:SecureConversationToken/sp:IssuerName

This optionalOPTIONAL element, of type xs:anyURI, contains the logical name of the sp:SecureConversationToken issuer.

/sp:SpnegoContextToken/wst:Claims

This optionalOPTIONAL element identifies the requiredREQUIRED claims that a security token must contain in order to satisfy the token assertion requirements.

/sp:SecureConversationToken/wsp:Policy

This requiredREQUIRED element identifies additional requirements for use of the sp:SecureConversationToken assertion.

/sp:SecureConversationToken/wsp:Policy/sp:RequireDerivedKeys

This optionalOPTIONAL element is a policy assertion that sets the [Derived Keys], [Explicit Derived Keys] and [Implied Derived Keys] properties for this token to 'true'.

/sp:SecureConversationToken/wsp:Policy/sp:RequireExplicitDerivedKeys

This optionalOPTIONAL element is a policy assertion that sets the [Derived Keys] and [Explicit Derived Keys] properties for this token to 'true' and the [Implied Derived Keys] property for this token to 'false'.

/sp:SecureConversationToken/wsp:Policy/sp:RequireImpliedDerivedKeys

This optionalOPTIONAL element is a policy assertion that sets the [Derived Keys] and [Implied Derived Keys] properties for this token to 'true' and the [Explicit Derived Keys] property for this token to 'false'.

/sp:SecureConversationToken/wsp:Policy/sp:RequireExternalUriReference

This optionalOPTIONAL element is a policy assertion that indicates that an external URI reference is requiredREQUIRED when referencing this token.

/sp:SecureConversationToken/wsp:Policy/sp:SC13SecurityContextToken

This optionalOPTIONAL element is a policy assertion that indicates that a Security Context Token should be used as obtained using the protocol defined in [WS-SecureConversation].

/sp:SecureConversationToken/wsp:Policy/sp:MustNotSendCancel

This optionalOPTIONAL element is a policy assertion that indicates that the STS issuing the secure conversation token does not support SCT/Cancel RST messages. If this assertion is missing it means that SCT/Cancel RST messages are supported by the STS.

/sp:SecureConversationToken/wsp:Policy/sp:MustNotSendAmend

This optionalOPTIONAL element is a policy assertion that indicates that the STS issuing the secure conversation token does not support SCT/Amend RST messages. If this assertion is missing it means that SCT/Amend RST messages are supported by the STS.

/sp:SecureConversationToken/wsp:Policy/sp:MustNotSendRenew

This optionalOPTIONAL element is a policy assertion that indicates that the STS issuing the secure conversation token does not support SCT/Renew RST messages. If this assertion is missing it means that SCT/Renew RST messages are supported by the STS.

/sp:SecureConversationToken/wsp:Policy/sp:BootstrapPolicy

This optionalOPTIONAL element is a policy assertion that contains the policy indicating the requirements for obtaining the Security Context Token.

/sp:SecureConversationToken/wsp:Policy/sp:BootstrapPolicy/wsp:Policy

This element contains the security binding requirements for obtaining the Security Context Token. It will typically contain a security binding assertion (e.g. sp:SymmetricBinding) along with protection assertions (e.g. sp:SignedParts) describing the parts of the RST/RSTR messages that are to be protected.

Example

5.4.8 SamlToken Assertion

This element represents a requirement for a SAML token.

Syntax

 

The following describes the attributes and elements listed in the schema outlined above:

/sp:SamlToken

This identifies a SamlToken assertion.

/sp:SamlToken/@sp:IncludeToken

This optionalOPTIONAL attribute identifies the token inclusion value for this token assertion.

/sp:SamlToken/sp:Issuer

This optionalOPTIONAL element, of type wsa:EndpointReferenceType, contains reference to the issuer of the sp:SamlToken.

/sp:SamlToken/sp:IssuerName

This optionalOPTIONAL element, of type xs:anyURI, contains the logical name of the sp:SamlToken issuer.

/sp:SamlToken/wst:Claims

This optionalOPTIONAL element identifies the requiredREQUIRED claims that a security token must contain in order to satisfy the token assertion requirements.

/sp:SamlToken/wsp:Policy

This requiredREQUIRED element identifies additional requirements for use of the sp:SamlToken assertion.

/sp:SamlToken/wsp:Policy/sp:RequireDerivedKeys

This optionalOPTIONAL element is a policy assertion that sets the [Derived Keys], [Explicit Derived Keys] and [Implied Derived Keys] properties for this token to 'true'.

/sp:SamlToken/wsp:Policy/sp:RequireExplicitDerivedKeys

This optionalOPTIONAL element is a policy assertion that sets the [Derived Keys] and [Explicit Derived Keys] properties for this token to 'true' and the [Implied Derived Keys] property for this token to 'false'.

/sp:SamlToken/wsp:Policy/sp:RequireImpliedDerivedKeys

This optionalOPTIONAL element is a policy assertion that sets the [Derived Keys] and [Implied Derived Keys] properties for this token to 'true' and the [Explicit Derived Keys] property for this token to 'false'.

/sp:SamlToken/wsp:Policy/sp:RequireKeyIdentifierReference

This optionalOPTIONAL element is a policy assertion that indicates that a key identifier reference is requiredREQUIRED when referencing this token.

/sp:SamlToken/wsp:Policy/sp:WssSamlV11Token10

This optionalOPTIONAL element is a policy assertion that identifies that a SAML Version 1.1 token should be used as defined in [WSS:SAMLTokenProfile1.0].

/sp:SamlToken/wsp:Policy/sp:WssSamlV11Token11

This optionalOPTIONAL element is a policy assertion that identifies that a SAML Version 1.1 token should be used as defined in [WSS:SAMLTokenProfile1.1].

/sp:SamlToken/wsp:Policy/sp:WssSamlV20Token11

This optionalOPTIONAL element is a policy assertion that identifies that a SAML Version 2.0 token should be used as defined in [WSS:SAMLTokenProfile1.1].

 

Note: This assertion does not describe how to obtain a SAML Token but rather assumes that both parties have the token already or have agreed separately on a mechanism for obtaining the token. If a definition of the mechanism for obtaining the SAML Token is desired in policy, the sp:IssuedToken assertion should SHOULD be used instead.

5.4.9 RelToken Assertion

This element represents a requirement for a REL token.

Syntax

 

The following describes the attributes and elements listed in the schema outlined above:

/sp:RelToken

This identifies a RelToken assertion.

/sp:RelToken/@sp:IncludeToken

This optionalOPTIONAL attribute identifies the token inclusion value for this token assertion.

/sp:RelToken/sp:Issuer

This optionalOPTIONAL element, of type wsa:EndpointReferenceType, contains reference to the issuer of the sp:RelToken.

/sp:RelToken/sp:IssuerName

This optionalOPTIONAL element, of type xs:anyURI, contains the logical name of the sp:RelToken issuer.

/sp:RelToken/wst:Claims

This optionalOPTIONAL element identifies the requiredREQUIRED claims that a security token must contain in order to satisfy the token assertion requirements.

/sp:RelToken/wsp:Policy

This requiredREQUIRED element identifies additional requirements for use of the sp:RelToken assertion.

/sp:RelToken/wsp:Policy/sp:RequireDerivedKeys

This optionalOPTIONAL element is a policy assertion that sets the [Derived Keys], [Explicit Derived Keys] and [Implied Derived Keys] property for this token to 'true'.

/sp:RelToken/wsp:Policy/sp:RequireExplicitDerivedKeys

This optionalOPTIONAL element is a policy assertion that sets the [Derived Keys] and [Explicit Derived Keys] properties for this token to 'true' and the [Implied Derived Keys] property for this token to 'false'.

/sp:RelToken/wsp:Policy/sp:RequireImpliedDerivedKeys

This optionalOPTIONAL element is a policy assertion that sets the [Derived Keys] and [Implied Derived Keys] properties for this token to 'true' and the [Explicit Derived Keys] property for this token to 'false'.

/sp:RelToken/wsp:Policy/sp:RequireKeyIdentifierReference

This optionalOPTIONAL element is a policy assertion that indicates that a key identifier reference is requiredREQUIRED when referencing this token.

/sp:RelToken/wsp:Policy/sp:WssRelV10Token10

This optionalOPTIONAL element is a policy assertion that identifies that a REL Version 1.0 token should be used as defined in [WSS:RELTokenProfile1.0].

/sp:RelToken/wsp:Policy/sp:WssRelV20Token10

This optionalOPTIONAL element is a policy assertion that identifies that a REL Version 2.0 token should be used as defined in [WSS:RELTokenProfile1.0].

/sp:RelToken/wsp:Policy/sp:WssRelV10Token11

This optionalOPTIONAL element is a policy assertion that identifies that a REL Version 1.0 token should be used as defined in [WSS:RELTokenProfile1.1].

/sp:RelToken/wsp:Policy/sp:WssRelV20Token11

This optionalOPTIONAL element is a policy assertion that identifies that a REL Version 2.0 token should be used as defined in [WSS:RELTokenProfile1.1].

 

Note: This assertion does not describe how to obtain a REL Token but rather assumes that both parties have the token already or have agreed separately on a mechanism for obtaining the token. If a definition of the mechanism for obtaining the REL Token is desired in policy, the sp:IssuedToken assertion should SHOULD be used instead.

5.4.10 HttpsToken Assertion

This element represents a requirement for a transport binding to support the use of HTTPS.

Syntax

The following describes the attributes and elements listed in the schema outlined above:

/sp:HttpsToken

This identifies an Https assertion stating that use of the HTTPS protocol specification is supported.

/sp:HttpsToken/sp:Issuer

This optionalOPTIONAL element, of type wsa:EndpointReferenceType, contains reference to the issuer of the sp:HttpsToken.

/sp:HttpsToken/sp:IssuerName

This optionalOPTIONAL element, of type xs:anyURI, contains the logical name of the sp:HttpsToken issuer.

/sp:HttpsToken/wst:Claims

This optionalOPTIONAL element identifies the requiredREQUIRED claims that a security token must contain in order to satisfy the token assertion requirements.

/sp:HttpsToken/wsp:Policy

This requiredREQUIRED element identifies additional requirements for use of the sp:HttpsToken assertion.

/sp:HttpsToken/wsp:Policy/sp:HttpBasicAuthentication

This optionalOPTIONAL element is a policy assertion that indicates that the client MUST use HTTP Basic Authentication [RFC2068] to authenticate to the service.

/sp:HttpsToken/wsp:Policy/sp:HttpDigestAuthentication

This optionalOPTIONAL element is a policy assertion that indicates that the client MUST use HTTP Digest Authentication [RFC2068] to authenticate to the service.

/sp:HttpsToken/wsp:Policy/sp:RequireClientCertificate

This optionalOPTIONAL element is a policy assertion that indicates that the client MUST provide a certificate when negotiating the HTTPS session.

5.4.11 KeyValueToken Assertion

This element represents a requirement for a KeyValue token. The next section defines the KeyValue security token abstraction for purposes of this token assertion.

 

This document defines requirements for KeyValue token when used in combination with RSA cryptographic algorithm. Additional cryptographic algorithms can be introduced in other specifications by introducing new nested assertions besides sp:RsaKeyValue.

Syntax

The following describes the attributes listed in the schema outlined above:

/sp:KeyValueToken

This identifies a RsaToken assertion.

/sp:KeyValueToken/@sp:IncludeToken

This optionalOPTIONAL attribute identifies the token inclusion value for this token assertion.

/sp:KeyValueToken/wsp:Policy

This requiredREQUIRED element identifies additional requirements for use of the sp:KeyValueToken assertion.

/sp:KeyValueToken/wsp:Policy/sp:RsaKeyValue

This optionalOPTIONAL element is a policy assertion that indicates that the ds:RSAKeyValue element must be present in the KeyValue token. This indicates that an RSA key pair must be used.

5.4.11.1 KeyValue Token

XML Signature specification allows reference an arbitrary key pair by using the corresponding public key value. This allows using an arbitrary key pair to sign or encrypt XML elements. The purpose of this section is to define the KeyValue token abstraction that represents such key pair referencing mechanism.

 

Although the ds:KeyValue element as defined in the XML Signature specification is generic enough to be used with any asymmetric cryptographic algorithm this document only profiles the usage of ds:KeyValue element in combination with RSA cryptographic algorithm.

 

The RSA key pair is represented by the ds:KeyInfo element containing the ds:KeyValue element with the RSA public key value in ds:RSAKeyValue as defined in the XML Signature specification:

 

When the KeyValue token is used the corresponding public key value appears directly in the signature or encrypted data ds:KeyInfo element like in the following example. There is no KeyValue token manifestation outside the ds:KeyInfo element.

 

Since there is no representation of the KeyValue token outside the ds:KeyInfo element and thus no identifier can be associated with the token, the KeyValue token cannot be referenced by using wsse:SecurityTokenReference element. However the ds:KeyInfo element representing the KeyValue token can be used whenever a security token can be used as illustrated on the following example:

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

6.1 [Algorithm Suite] Property

This property specifies the algorithm suite required REQUIRED for performing cryptographic operations with symmetric or asymmetric key based security tokens. An algorithm suite specifies actual algorithms and allowed key lengths. A policy alternative will define what algorithms are used and how they are used. This property defines the set of available algorithms. The value of this property is typically referenced by a security binding and is used to specify the algorithms used for all message level cryptographic operations performed under the security binding.

Note: In some cases, this property MAY be referenced under a context other than a security binding and used to control the algorithms used under that context. For example, supporting token assertions define such a context. In such contexts, the specified algorithms still apply to message level cryptographic operations.

An algorithm suite defines values for each of the following operations and properties:

·         [Sym Sig]         Symmetric Key Signature

·         [Asym Sig]        Signature with an asymmetric key

·         [Dig]                 Digest

·         [Enc]                Encryption

·         [Sym KW]         Symmetric Key Wrap

·         [Asym KW]       Asymmetric Key Wrap

·         [Comp Key]      Computed key

·         [Enc KD]           Encryption key derivation

·         [Sig KD]           Signature key derivation

·         [Min SKL]          Minimum symmetric key length

·         [Max SKL]         Maximum symmetric key length

·         [Min AKL]          Minimum asymmetric key length

·         [Max AKL]         Maximum asymmetric key length

 

The 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
Aes192	http://www.w3.org/2001/04/xmlenc#aes192-cbc
Aes256	http://www.w3.org/2001/04/xmlenc#aes256-cbc
TripleDes	http://www.w3.org/2001/04/xmlenc#tripledes-cbc
KwAes128	http://www.w3.org/2001/04/xmlenc#kw-aes128
KwAes192	http://www.w3.org/2001/04/xmlenc#kw-aes192
KwAes256	http://www.w3.org/2001/04/xmlenc#kw-aes256
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
PSha1L192	http://docs.oasis-open.org/ws-sx/ws-secureconversation/200512/dk/p_sha1
PSha1L256	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
STRT10	http://docs.oasis-open.org/wss/2004/xx/oasis-2004xx-wss-soap-message-security-1.0#STR-Transform
AbsXPath	http://docs.oasis-open.org/...TBD.../AbsXPath

 

The tables below show all the base algorithm suites defined by this specification. This table defines values 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

This table defines additional properties whose values can be specified along with the default value for that property.

Property	Algorithm / Value
[C14n Algorithm]	ExC14n
[Soap Norm]	None
[STR Trans]	None
[XPath]	None

This 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
Basic192	Sha1	Aes192	KwAes192	KwRsaOaep	PSha1L192	PSha1L192	192
Basic128	Sha1	Aes128	KwAes128	KwRsaOaep	PSha1L128	PSha1L128	128
TripleDes	Sha1	TripleDes	KwTripleDes	KwRsaOaep	PSha1L192	PSha1L192	192
Basic256Rsa15	Sha1	Aes256	KwAes256	KwRsa15	PSha1L256	PSha1L192	256
Basic192Rsa15	Sha1	Aes192	KwAes192	KwRsa15	PSha1L192	PSha1L192	192
Basic128Rsa15	Sha1	Aes128	KwAes128	KwRsa15	PSha1L128	PSha1L128	128
TripleDesRsa15	Sha1	TripleDes	KwTripleDes	KwRsa15	PSha1L192	PSha1L192	192
Basic256Sha256	Sha256	Aes256	KwAes256	KwRsaOaep	PSha1L256	PSha1L192	256
Basic192Sha256	Sha256	Aes192	KwAes192	KwRsaOaep	PSha1L192	PSha1L192	192
Basic128Sha256	Sha256	Aes128	KwAes128	KwRsaOaep	PSha1L128	PSha1L128	128
TripleDesSha256	Sha256	TripleDes	KwTripleDes	KwRsaOaep	PSha1L192	PSha1L192	192
Basic256Sha256Rsa15	Sha256	Aes256	KwAes256	KwRsa15	PSha1L256	PSha1L192	256
Basic192Sha256Rsa15	Sha256	Aes192	KwAes192	KwRsa15	PSha1L192	PSha1L192	192
Basic128Sha256Rsa15	Sha256	Aes128	KwAes128	KwRsa15	PSha1L128	PSha1L128	128
TripleDesSha256Rsa15	Sha256	TripleDes	KwTripleDes	KwRsa15	PSha1L192	PSha1L192	192

6.2 [Timestamp] Property

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

6.3 [Protection Order] Property

This property indicates the order in which integrity and confidentiality are applied to the message, in cases where both integrity and confidentiality are requiredREQUIRED:

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.

The default value for this property is 'SignBeforeEncrypting'.

6.4 [Signature Protection] Property

This boolean property specifies whether the signature must MUST be encrypted. If the value is 'true', the primary signature MUST be encrypted and any signature confirmation elements MUST also be encrypted. The primary signature element is not requiredNOT REQUIRED to be encrypted if the value is ‘true’ when there is nothing else in the messagethat is covered by this signature that is encrypted. If the value is 'false', the primary signature MUST NOT be encrypted and any signature confirmation elements MUST NOT be encrypted. The default value for this property is 'false'.

6.5 [Token Protection] Property

This boolean property specifies whether signatures must MUST cover the token used to generate that signature. If the value is 'true', then each token used to generate a signature MUST be covered by that signature. If the value is 'false', then the token MUST NOT be covered by the signature. Note that in cases where derived keys are used the 'main' token, and NOT the derived key token, is covered by the signature. It is recommended RECOMMENDED that assertions that define values for this property apply to [Endpoint Policy Subject]. The default value for this property is 'false'.

6.6 [Entire Header and Body Signatures] Property

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

6.7 [Security Header Layout] Property

This property indicates which layout rules to apply when adding items to the security header. The following 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 wsuse: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 wsuse:Timestamp. Note that the [Timestamp] property MUST also be set to 'true' in this case.

 

6.7.1 Strict Layout Rules for WSS 1.0

1. Tokens that are included in the message MUST be declared before use. For example:
2. 1. A local signing token MUST occur before the signature that uses it.
   2. A local token serving as the source token for a derived key token MUST occur before that derived key token.
   3. A local encryption token MUST occur before the reference list that points to xenc:EncryptedData elements that use it.
   4. If the same token is used for both signing and encryption, then it should SHOULD appear before the ds:Signature and xenc:ReferenceList elements in the security header that are generated using the token.
3. Signed elements inside the security header MUST occur before the signature that signs them.  For example:
4. 1. A timestamp MUST occur before the signature that signs it.
   2. A Username token (usually in encrypted form) MUST occur before the signature that signs it.
   3. A primary signature MUST occur before the supporting token signature that signs the primary signature's signature value element.
5. When an element in a security header is encrypted, the resulting xenc:EncryptedData element has the same order requirements as the source plain text element, unless requirement 4 indicates otherwise. For example, an encrypted primary signature MUST occur before any supporting token signature per 2.c above and an encrypted token has the same ordering requirements as the unencrypted token.

If there are any encrypted elements in the message then a top level xenc:ReferenceList element or a top level xenc:EncryptedKey element which contains an xenc:ReferenceList element MUST be present in the security header. The xenc:ReferenceList or xenc:EncryptedKey MUST occur before any xenc:EncryptedData elements in the security header that are referenced from the reference list. Strict Layout Rules for WSS 1.1

1. Tokens that are included in the message MUST be declared before use. For example:
2. 1. A local signing token MUST occur before the signature that uses it.
   2. A local token serving as the source token for a derived key token MUST occur before that derived key token.
   3. A local encryption token MUST occur before the reference list that points to xenc:EncryptedData elements that use it.
   4. If the same token is used for both signing and encryption, then it should SHOULD appear before the ds:Signature and xenc:ReferenceList elements in the security header that are generated using the token.
3. Signed elements inside the security header MUST occur before the signature that signs them.  For example:
4. 1. A timestamp MUST occur before the signature that signs it.
   2. A Username token (usually in encrypted form) MUST occur before the signature that signs it.
   3. A primary signature MUST occur before the supporting token signature that signs the primary signature's signature value element.
   4. A wsse11:SignatureConfirmation element MUST occur before the signature that signs it.
5. When an element in a security header is encrypted, the resulting xenc:EncryptedData element has the same order requirements as the source plain text element, unless requirement 4 indicates otherwise. For example, an encrypted primary signature MUST occur before any supporting token signature per 2.c above and an encrypted token has the same ordering requirements as the unencrypted token.
6. If there are any encrypted elements in the message then a top level xenc:ReferenceList element MUST be present in the security header. The xenc:ReferenceList MUST occur before any xenc:EncryptedData elements in the security header that are referenced from the reference list. However, the xenc:ReferenceList is not requiredNOT REQUIRED to appear before independently encrypted tokens such as the xenc:EncryptedKey token as defined in WSS.
7. An xenc:EncryptedKey element without an internal reference list [WSS: SOAP Message Security 1.1] MUST obey rule 1 above.

The appropriate representation of the different facets of security mechanisms requires distilling the common primitives (to enable reuse) and then combining the primitive elements into patterns. The policy scope of assertions defined in this section is the policy scope of their containing element.

7.1 AlgorithmSuite Assertion

This assertion indicates a requirement for an algorithm suite as defined under the [Algorithm Suite] property described in Section 6.1. The scope of this assertion is defined by its containing assertion.

Syntax

 

The following describes the attributes and elements listed in the schema outlined above:

/sp:AlgorithmSuite

This identifies an AlgorithmSuite assertion.

/sp:AlgorithmSuite/wsp:Policy

This requiredREQUIRED element contains one or more policy assertions that indicate the specific algorithm suite to use.

/sp:AlgorithmSuite/wsp:Policy/sp:Basic256

This optionalOPTIONAL element is a policy assertion that indicates that the [Algorithm Suite] property is set to 'Basic256'.

/sp:AlgorithmSuite/wsp:Policy/sp:Basic192

This optionalOPTIONAL element is a policy assertion that indicates that the [Algorithm Suite] property is set to 'Basic192'.

/sp:AlgorithmSuite/wsp:Policy/sp:Basic128

This optionalOPTIONAL element is a policy assertion that indicates that the [Algorithm Suite] property is set to 'Basic128'.

/sp:AlgorithmSuite/wsp:Policy/sp:TripleDes

This optionalOPTIONAL element is a policy assertion that indicates that the [Algorithm Suite] property is set to 'TripleDes'.

/sp:AlgorithmSuite/wsp:Policy/sp:Basic256Rsa15

This optionalOPTIONAL element is a policy assertion that indicates that the [Algorithm Suite] property is set to 'Basic256Rsa15'.

/sp:AlgorithmSuite/wsp:Policy/sp:Basic192Rsa15

This optionalOPTIONAL element is a policy assertion that indicates that the [Algorithm Suite] property is set to 'Basic192Rsa15'.

/sp:AlgorithmSuite/wsp:Policy/sp:Basic128Rsa15

This optionalOPTIONAL element is a policy assertion that indicates that the [Algorithm Suite] property is set to 'Basic128Rsa15'.

/sp:AlgorithmSuite/wsp:Policy/sp:TripleDesRsa15

This optionalOPTIONAL element is a policy assertion that indicates that the [Algorithm Suite] property is set to 'TripleDesRsa15'.

/sp:AlgorithmSuite/wsp:Policy/sp:Basic256Sha256

This optionalOPTIONAL element is a policy assertion that indicates that the [Algorithm Suite] property is set to 'Basic256Sha256'.

/sp:AlgorithmSuite/wsp:Policy/sp:Basic192Sha256

This optionalOPTIONAL element is a policy assertion that indicates that the [Algorithm Suite] property is set to 'Basic192Sha256'.

/sp:AlgorithmSuite/wsp:Policy/sp:Basic128Sha256

This optionalOPTIONAL element is a policy assertion that indicates that the [Algorithm Suite] property is set to 'Basic128Sha256'.

/sp:AlgorithmSuite/wsp:Policy/sp:TripleDesSha256

This optionalOPTIONAL element is a policy assertion that indicates that the [Algorithm Suite] property is set to 'TripleDesSha256'.

/sp:AlgorithmSuite/wsp:Policy/sp:Basic256Sha256Rsa15

This optionalOPTIONAL element is a policy assertion that indicates that the [Algorithm Suite] property is set to 'Basic256Sha256Rsa15'.

/sp:AlgorithmSuite/wsp:Policy/sp:Basic192Sha256Rsa15

This optionalOPTIONAL element is a policy assertion that indicates that the [Algorithm Suite] property is set to 'Basic192Sha256Rsa15'.

/sp:AlgorithmSuite/wsp:Policy/sp:Basic128Sha256Rsa15

This optionalOPTIONAL element is a policy assertion that indicates that the [Algorithm Suite] property is set to 'Basic128Sha256Rsa15'.

/sp:AlgorithmSuite/wsp:Policy/sp:TripleDesSha256Rsa15

This optionalOPTIONAL element is a policy assertion that indicates that the [Algorithm Suite] property is set to 'TripleDesSha256Rsa15'.

/sp:AlgorithmSuite/wsp:Policy/sp:InclusiveC14N

This optionalOPTIONAL element is a policy assertion that indicates that the [C14N] property of an algorithm suite is set to 'C14N'. Note: as indicated in Section 6.1 the default value of the [C14N] property is 'ExcC14N'.

/sp:AlgorithmSuite/wsp:Policy/sp:SoapNormalization10

This optionalOPTIONAL element is a policy assertion that indicates that the [SOAP Norm] property is set to 'SNT'.

/sp:AlgorithmSuite/wsp:Policy/sp:STRTransform10

This optionalOPTIONAL element is a policy assertion that indicates that the [STR Transform] property is set to 'STRT10'.

/sp:AlgorithmSuite/wsp:Policy/sp:XPath10

This optionalOPTIONAL element is a policy assertion that indicates that the [XPath] property is set to 'XPath'.

/sp:AlgorithmSuite/wsp:Policy/sp:XPathFilter20

This optionalOPTIONAL element is a policy assertion that indicates that the [XPath] property is set to 'XPath20'.

/sp:AlgorithmSuite/wsp:Policy/sp:AbsXPath

This optionalOPTIONAL element is a policy assertion that indicates that the [XPath] property is set to 'AbsXPath' (see AbsoluteLocationPath in [XPATH]).

 

7.2 Layout Assertion

This assertion indicates a requirement for a particular security header layout as defined under the [Security Header Layout] property described in Section 6.7. The scope of this assertion is defined by its containing assertion.

Syntax

 

The following describes the attributes and elements listed in the schema outlined above:

/sp:Layout

This identifies a Layout assertion.

/sp:Layout/wsp:Policy

This requiredREQUIRED element contains one or more policy assertions that indicate the specific security header layout to use.

/sp:Layout/wsp:Policy/sp:Strict

This optionalOPTIONAL element is a policy assertion that indicates that the [Security Header Layout] property is set to 'Strict'.

/sp:Layout/wsp:Policy/sp:Lax

This optionalOPTIONAL element is a policy assertion that indicates that the [Security Header Layout] property is set to 'Lax'.

/sp:Layout/wsp:Policy/sp:LaxTsFirst

This optionalOPTIONAL element is a policy assertion that indicates that the [Security Header Layout] property is set to 'LaxTimestampFirst'. Note that the [Timestamp] property MUST also be set to 'true' by the presence of an sp:IncludeTimestamp assertion.

/sp:Layout/wsp:Policy/sp:LaxTsLast

This optionalOPTIONAL element is a policy assertion that indicates that the [Security Header Layout] property is set to 'LaxTimestampLast'. Note that the [Timestamp] property MUST also be set to 'true' by the presence of an sp:IncludeTimestamp assertion.

7.3 TransportBinding Assertion

The TransportBinding assertion is used in scenarios in which message protection and security correlation is provided by means other than WSS: SOAP Message Security, for example by a secure transport like HTTPS.  Specifically, this assertion indicates that the message is protected using the means provided by the transport. This binding has one binding specific token property; [Transport Token]. This assertion MUST apply to [Endpoint Policy Subject].

Syntax

 

The following describes the attributes and elements listed in the schema outlined above:

/sp:TransportBinding

This identifies a TransportBinding assertion.

/sp:TransportBinding/wsp:Policy

This indicates a nested wsp:Policy element that defines the behavior of the TransportBinding assertion.

/sp:TransportBinding/wsp:Policy/sp:TransportToken

This requiredREQUIRED element is a policy assertion that indicates a requirement for a Transport Token. The specified token populates the [Transport Token] property and indicates how the transport is secured.

/sp:TransportBinding/wsp:Policy/sp:TransportToken/wsp:Policy

This indicates a nested policy that identifies the type of Transport Token to use.

/sp:TransportBinding/wsp:Policy/sp:AlgorithmSuite

This requiredREQUIRED element is a policy assertion that indicates a value that populates the [Algorithm Suite] property. See Section 6.1 for more details.

/sp:TransportBinding/wsp:Policy/sp:Layout

This optionalOPTIONAL element is a policy assertion that indicates a value that populates the [Security Header Layout] property. See Section 6.7 for more details.

/sp:TransportBinding/wsp:Policy/sp:IncludeTimestamp

This optionalOPTIONAL element is a policy assertion that indicates that the [Timestamp] property is set to 'true'.

7.4 SymmetricBinding Assertion

The SymmetricBinding assertion is used in scenarios in which message protection is provided by means defined in WSS: SOAP Message Security. This binding has two binding specific token properties; [Encryption Token] and [Signature Token]. If the message pattern requires multiple messages, this binding defines that the [Encryption Token] used from initiator to recipient is also used from recipient to initiator. Similarly, the [Signature Token] used from initiator to recipient is also use from recipient to initiator.