The following issues related to WS-SecurityPolicy 1.2 as recorded
in the [WS-SX Issues] have been addressed in this document.
|
Issue
|
Description
|
|
ER001
|
Inconsistent IncludeToken URI between spec and schema xsd
file
|
|
ER002
|
Editorial comments on SP
|
|
ER004
|
Wrong Security Context Token assertion in example
|
|
ER007
|
Minor editorial addition to
<ContentEncryptedElements> Assertion
|
|
ER009
|
Policy Assertion Parameters and alternatives
|
|
ER010
|
Typo in the Security Header Layout section
|
|
ER011
|
Modification request for issue PR014
|
|
ER006
|
Presence of wsu:Timestamp when [Timestamp] is false
|
|
ER014
|
Review normative RFC 2119 language in WS-SecurityPolicy
|
|
i165
|
SP errata
|
|
i170
|
Update XML Signature references to refer to XML
Signature, Second Edition, update c14n reference in ws-trust
|
|
i171
|
Incorrect URI provided for Canonical XML 1.0 when
defining C14n abbreviation
|
The following changes do not affect the normative meaning of
the text, they are only to properly capitalize 2119 terms. The changes listed
below document the changes as they appear in the text. There were many
instances of the terms OPTIONAL and REQUIRED in the schema exemplar
descriptions that appeared un-capitalized that are not captured below but that
have also been addressed. All other 2119 terms that remain un-capitalized are
used in their English sense.
Line 121
Extensibility points in the exemplar MAY NOT be described in
the corresponding text
Line 130
WS-SecurityPolicy SHOULD be applicable to any version of
SOAP
Line 321
Assertions MAY be used to further qualify a specific aspect
of another assertion. For example, an assertion describing the set of
algorithms to use MAY qualify the specific behavior of a security binding
Line 338
Any REQUIRED message elements (e.g. timestamps) in the
wsse:Security header
Line 347
Note that a service 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 choose to accept messages that do not
conform to its policy.
Line 365
This section defines properties that are referenced later in
this document describing the RECOMMEDED or REQUIRED attachment points for
various assertions.
Line 489
Multiple instances of this element MAY appear within this
assertion and SHOULD be treated as separate references in a signature when
message security is used
Line 571
Multiple instances of this element MAY appear within this
assertion and SHOULD be treated as separate references
Line 597
Multiple instances of this element MAY appear within this
assertion and SHOULD be treated as separate references
Line 628
Multiple instances of this element MAY appear within this
assertion and SHOULD be treated as a combined XPath expression
Line 658
Any token assertion MAY also carry an OPTIONAL
sp:IncludeToken attribute
Line 659
This attribute indicates whether the token SHOULD be
included
Line 664 (in table)
an external reference to the token SHOULD be used.
Subsequent related messages sent between the recipient and
the initiator MAY refer to
Line 673
A token assertion MAY carry a sp:IncludeToken attribute that
requires that the token be included in the message
Line 684
then references to that token are REQUIRED to contain all
the specified reference types.
Line 691
Any token assertion MAY also carry an OPTIONAL sp:Issuer
element
Line 696
Any token assertion MAY also carry an OPTIONAL sp:IssuerName
element.
Line 703
While both sp:Issuer and sp:IssuerName elements are OPTIONAL
they are also mutually exclusive
Line 706
Any token assertion MAY also carry an OPTIONAL wst:Claims
element
Line 710
This element indicates the REQUIRED claims that the security
token MUST contain in order to satisfy the requirements of the token assertion.
Line 713
Individual token assertions MAY further limit what claims
MAY be specified for that specific token assertion.
Line 716
As long as the union of all tokens in the received message
contains the REQUIRED set of claims from REQUIRED token issuers the message is
valid according to the receiver’s policy.
Line 736
This boolean property specifies whether derived keys SHOULD
be used as defined in WS-SecureConversation
Line 900
Note: The IssuedToken MAY or MAY NOT be associated with key
material and such key material MAY be symmetric or asymmetric.
Line 902
Services MAY also include information in the
sp:RequestSecurityTokenTemplate element
Line 1180
then either the sp:SecureConversationToken or the
sp:IssuedToken assertion SHOULD be used instead
Line 1187
Because this token is issued by the target service and MAY
NOT have a separate port
Line 1379
the sp:IssuedToken assertion SHOULD be used instead
Line 1451
the sp:IssuedToken assertion SHOULD be used instead
Line 1597
This property specifies the algorithm suite REQUIRED for
performing cryptographic operations with symmetric or asymmetric key based
security tokens.
Line 1635
This property indicates the order in which integrity and
confidentiality are applied to the message, in cases where both integrity and
confidentiality are REQUIRED
Line 1639
This boolean property specifies whether the signature MUST
be encrypted.
Line 1641
The primary signature element is NOT REQUIRED to be
encrypted if the value is ‘true’
Line 1646
This boolean property specifies whether signatures MUST
cover the token used to generate that signature.
Line 1650
It is RECOMMENDED that assertions that define values for
this property apply to [Endpoint Policy Subject].
Line 1653
This boolean property specifies whether signature digests
over the SOAP body and SOAP headers MUST only cover the entire body and entire
header elements.
Line 1661
It is RECOMMENDED that assertions that define values for
this property apply to [Endpoint Policy Subject].
Line 1674
then it SHOULD appear before the ds:Signature and
xenc:ReferenceList elements
Line 1700
then it SHOULD appear before the ds:Signature and
xenc:ReferenceList elements
Line 1719
However, the xenc:ReferenceList is NOT REQUIRED to appear
before independently encrypted tokens such as the xenc:EncryptedKey token as
defined in WSS
Line 2133
Additional tokens MAY be specified to augment the claims
Line 2134
This section defines seven properties related to supporting
token requirements which MAY be referenced by a Security Binding
Line 2145
Supporting tokens MAY be specified at a different scope than
the binding assertion
Line 2148
the sender SHOULD merge the requirements by including all
tokens
Line 2152
all the tokens SHOULD sign and encrypt the various message
parts
Line 2161
To illustrate the different ways that supporting tokens MAY
be bound to the message
Line 2165
Even before any supporting tokens are added, each binding
requires that the message is signed using a token satisfying the REQUIRED usage
for that binding
Line 2171
Note: if REQUIRED, the initiator MAY also include in the
Security header the token used as the basis for the message signature (Sig1),
not shown in the diagram
Line 2178
Supporting tokens are included in the security header and
MAY OPTIONALLY include additional message parts to sign and/or encrypt
Line 2229
Signed tokens are included in the “message signature” as
defined above and MAY OPTIONALLY include additional message parts to sign
and/or encrypt
Line 2283
produced from the message signature and MAY OPTIONALLY
include
Line 2339
This assertion MAY OPTIONALLY include additional message
parts to sign and/or encrypt
Line 2345
If transport security is used, the token (Tok2) is included
in the Security header and the signature (Sig2) SHOULD cover the message
timestamp as illustrated below
Line 2485
There are several OPTIONAL aspects to the WSS: SOAP Message
Security specification
Line 2496
a token MAY be referenced using different mechanisms
Line 2551
This boolean property specifies whether
wsse11:SignatureConfirmation elements SHOULD be used
Line 2634
These assertions relate to interactions with a Security
Token Service and MAY augment the behaviors defined by
Line 2649
A challenge issued by the server MAY increase the number of
messages exchanged by the client and service
Line 2656
This boolean property indicates whether client entropy is
REQUIRED to be used as key material for a requested proof token. A value of
'true' indicates that client entropy is REQUIRED. A value of 'false' indicates
that client entropy is NOT REQUIRED
Line 2661
This boolean property indicates whether server entropy is
REQUIRED to be used as key material for a requested proof token. A value of
'true' indicates that server entropy is REQUIRED. A value of 'false' indicates
that server entropy is NOT REQUIRED
Line 2881
Policy MAY be embedded inside an Issued Token assertion, or
acquired out-of-band. There MAY be an explicit trust relationship between the
Server and the STS. There MUST be a trust relationship between the Client and
the STS.
Line 2885
client-specific parameters that MUST be understood
Line 2898
The Client MAY augment or replace the contents of the RST
Line 2902
The Issued Token Policy Assertion contains elements which
MUST be understood by the Client. The assertion contains one element which
contains a list of arbitrary elements which SHOULD be sent along to the STS
Line 2908
All items are OPTIONAL , since the Server and STS MAY
already have a pre-arranged relationship
Line 3808
A wsse:UsernameToken MAY be encrypted when a transport
binding is not being used
Line 254 changed
http://www.w3.org/TR/2002/REC-xmlenc-core-20021210/
to
http://www.w3.org/TR/2002/REC-xmldsig-core-20020212/
Inserted after line 254
[W3C Recommendation, D. Eastlake et al. XML Signature Syntax and Processing (Second Edition). 10 June 2008.
http://www.w3.org/TR/2008/REC-xmldsig-core-20080610/
Added after line 288
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 may choose to accept messages that
do not match its policy.
Added after line 593
If no attribute is provided, then XPath 1.0 is assumed.
The schema had token inclusion values defined that did not
match the values defined in the specification. The following schema fragment
was corrected.
Original, incorrect, schema fragment
<xs:simpleType name="IncludeTokenType">
<xs:restriction base="xs:anyURI" >
<xs:enumeration
value="http://docs.oasis-open.org/ws-sx/ws-trust/200702/ws-securitypolicy/IncludeToken/Never"
/>
<xs:enumeration value="http://docs.oasis-open.org/ws-sx/ws-trust/200702/ws-securitypolicy/IncludeToken/Once"
/>
<xs:enumeration
value="http://docs.oasis-open.org/ws-sx/ws-trust/200702/ws-securitypolicy/IncludeToken/AlwaysToRecipient"
/>
<xs:enumeration
value="http://docs.oasis-open.org/ws-sx/ws-trust/200702/ws-securitypolicy/IncludeToken/AlwaysToInitiator"
/>
<xs:enumeration
value="http://docs.oasis-open.org/ws-sx/ws-trust/200702/ws-securitypolicy/IncludeToken/Always"
/>
</xs:restriction>
</xs:simpleType>
Updated, correct, schema fragment
<xs:simpleType name="IncludeTokenType">
<xs:restriction base="xs:anyURI" >
<xs:enumeration
value="http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702/IncludeToken/Never"
/>
<xs:enumeration
value="http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702/IncludeToken/Once"
/>
<xs:enumeration
value="http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702/IncludeToken/AlwaysToRecipient"
/>
<xs:enumeration
value="http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702/IncludeToken/AlwaysToInitiator"
/>
<xs:enumeration
value="http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702/IncludeToken/Always"
/>
</xs:restriction>
</xs:simpleType>
Line 1282 changed
<sp:SC10SecurityContextToken />
to
<sp:SC13SecurityContextToken />
Line 1622 Table entry changed
|
C14n
|
http://www.w3.org/2001/xml-c14n#
|
to
|
C14N
|
http://www.w3.org/TR/2001/REC-xml-c14n-20010315
|
Line 1622 Table entry inserted
Line 1622 Table entry changed
|
ExC14n
|
http://www.w3.org/2001/10/xml-exc-c14n#
|
to
|
ExC14N
|
http://www.w3.org/2001/10/xml-exc-c14n#
|
Line 1627 Table entry changed
to
Lines 1640-1642 changed
The primary signature element is not required to be
encrypted if the value is ‘true’ when there is nothing else in the message that
is encrypted.
to
The primary signature element is not required to be
encrypted if the value is ‘true’ when there is nothing in the message that is
covered by this signature that is encrypted.
Line 1665 table contents changed
wsse:Timestamp
to
wsu:Timestamp
Inserted after line 1750
<sp:InclusiveC14N11 ... /> ?
Line 1819 changed
ExcC14N
To
ExC14N
Line 2097 changed
The specified token populates the [Recipient Signature
Token] property and is used for the message signature from Recipient to
recipient.
to
The specified token populates the [Recipient Signature
Token] property and is used for the message signature from recipient to the
initiator.
Lines 2103 changed
The specified token populates the [Recipient Encryption
Token] property and is used for the message encryption from recipient to
Recipient.
to
The specified token populates the [Recipient Encryption
Token] property and is used for the message encryption from initiator to
recipient.
Line 2720 changed
sp:Trust10
to
sp:Trust13
Inserted after line 1819
/sp:AlgorithmSuite/wsp:Policy/sp:InclusiveC14N11
This OPTIONAL element is a policy
assertion that indicates that the [C14N] property of an algorithm suite is set
to 'C14N11'. Note: as indicated in Section 6.1 the default value of the [C14N]
property is 'ExC14N'.
[WS-SX Issues] WS-SX TC Issues List
http://docs.oasis-open.org/ws-sx/issues/Issues.xml
[WS-SecurityPolicy] OASIS Standard, “WS-SecurityPolicy
1.2", July 2007
http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702
The following individuals have participated in the creation
of this specification and are gratefully acknowledged.
TC Members during the development of this specification:
Don Adams, Tibco Software Inc.
Jan Alexander, Microsoft Corporation
Steve Anderson, BMC Software
Donal Arundel, IONA Technologies
Howard Bae, Oracle Corporation
Abbie Barbir, Nortel Networks Limited
Charlton Barreto, Adobe Systems
Mighael Botha, Software AG, Inc.
Toufic Boubez, Layer 7 Technologies Inc.
Norman Brickman, Mitre Corporation
Melissa Brumfield, Booz Allen Hamilton
Lloyd Burch, Novell
Scott Cantor, Internet2
Greg Carpenter, Microsoft Corporation
Steve Carter, Novell
Symon Chang, BEA Systems, Inc.
Ching-Yun (C.Y.) Chao, IBM
Martin Chapman, Oracle Corporation
Kate Cherry, Lockheed Martin
Henry (Hyenvui) Chung, IBM
Luc Clement, Systinet Corp.
Paul Cotton, Microsoft Corporation
Glen Daniels, Sonic Software Corp.
Peter Davis, Neustar, Inc.
Martijn de Boer, SAP AG
Werner Dittmann, Siemens AG
Abdeslem DJAOUI, CCLRC-Rutherford Appleton Laboratory
Fred Dushin, IONA Technologies
Petr Dvorak, Systinet Corp.
Colleen Evans, Microsoft Corporation
Ruchith Fernando, WSO2
Mark Fussell, Microsoft Corporation
Vijay Gajjala, Microsoft Corporation
Marc Goodner, Microsoft Corporation
Hans Granqvist, VeriSign
Martin Gudgin, Microsoft Corporation
Tony Gullotta, SOA Software Inc.
Jiandong Guo, Sun Microsystems
Phillip Hallam-Baker, VeriSign
Patrick Harding, Ping Identity Corporation
Heather Hinton, IBM
Frederick Hirsch, Nokia Corporation
Jeff Hodges, Neustar, Inc.
Will Hopkins, BEA Systems, Inc.
Alex Hristov, Otecia Incorporated
John Hughes, PA Consulting
Diane Jordan, IBM
Venugopal K, Sun Microsystems
Chris Kaler, Microsoft Corporation
Dana Kaufman, Forum Systems, Inc.
Paul Knight, Nortel Networks Limited
Ramanathan Krishnamurthy, IONA Technologies
Christopher Kurt, Microsoft Corporation
Kelvin Lawrence, IBM
Hubert Le Van Gong, Sun Microsystems
Jong Lee, BEA Systems, Inc.
Rich Levinson, Oracle Corporation
Tommy Lindberg, Dajeil Ltd.
Mark Little, JBoss Inc.
Hal Lockhart, BEA Systems, Inc.
Mike Lyons, Layer 7 Technologies Inc.
Eve Maler, Sun Microsystems
Ashok Malhotra, Oracle Corporation
Anand Mani, CrimsonLogic Pte Ltd
Jonathan Marsh, Microsoft Corporation
Robin Martherus, Oracle Corporation
Miko Matsumura, Infravio, Inc.
Gary McAfee, IBM
Michael McIntosh, IBM
John Merrells, Sxip Networks SRL
Jeff Mischkinsky, Oracle Corporation
Prateek Mishra, Oracle Corporation
Bob Morgan, Internet2
Vamsi Motukuru, Oracle Corporation
Raajmohan Na, EDS
Anthony Nadalin, IBM
Andrew Nash, Reactivity, Inc.
Eric Newcomer, IONA Technologies
Duane Nickull, Adobe Systems
Toshihiro Nishimura, Fujitsu Limited
Rob Philpott, RSA Security
Denis Pilipchuk, BEA Systems, Inc.
Darren Platt, Ping Identity Corporation
Martin Raepple, SAP AG
Nick Ragouzis, Enosis Group LLC
Prakash Reddy, CA
Alain Regnier, Ricoh Company, Ltd.
Irving Reid, Hewlett-Packard
Bruce Rich, IBM
Tom Rutt, Fujitsu Limited
Maneesh Sahu, Actional Corporation
Frank Siebenlist, Argonne National Laboratory
Joe Smith, Apani Networks
Davanum Srinivas, WSO2
Yakov Sverdlov, CA
Gene Thurston, AmberPoint
Victor Valle, IBM
Asir Vedamuthu, Microsoft Corporation
Greg Whitehead, Hewlett-Packard
Ron Williams, IBM
Corinna Witt, BEA Systems, Inc.
Kyle
Young, Microsoft Corporation
