In the Xpath Fliter 2.0 case, additional attributes
is needed for each sp:XPath element, such as Filter="intersect" or Filter="union". These
are not the namespace attributes. Without these attributes, the sp:SignedElements
will not be able to define XPath fliter 2.0 elements.
The XpathVersion attribute allows user to
define any Xpath evaluation tool to get the elements for signature, encryption,
and/or required elements. However, if the sp:XPath element does not allow any
attribute, it will be a big limitation on how sp:XPath can be used.
If this limitation is due to the fact of
the sp:XPath is not an assertion in current spec, can we change it into
assertion instead?
Best regards,
Symon
Chang
From: Martin Gudgin
[mailto:mgudgin@microsoft.com]
Sent: Thursday, August 16, 2007
3:18 PM
To: Anthony Nadalin; Symon Chang
Cc: Greg Carpenter; Marc Goodner;
Will Hopkins; ws-sx@lists.oasis-open.org
Subject: RE: [ws-sx] Issue i148:
Syntax of XPath for Signed, Encrypted and Required Elements
Also, namespace
attributes are always allowed, on any element in XML. There is no way to
prohibit their appearance. Therefore there is no need to state that they are
allowed…
Gudge
From: Anthony Nadalin
[mailto:drsecure@us.ibm.com]
Sent: Thursday, August 16, 2007
8:09 AM
To: Symon
Chang
Cc: Greg Carpenter; Marc Goodner;
Will Hopkins; ws-sx@lists.oasis-open.org
Subject: RE: [ws-sx] Issue i148: Syntax
of XPath for Signed, Encrypted and Required Elements
Your missing the point, sp:XPath is not an assertion
Anthony Nadalin | Work 512.838.0085 | Cell 512.289.4122
"Symon
Chang" ---08/14/2007 02:05:40 PM---
From:
|
"Symon Chang" <sychang@bea.com>
|
To:
|
"Marc
Goodner" <mgoodner@microsoft.com>, "Greg Carpenter"
<gregcarp@microsoft.com>, <ws-sx@lists.oasis-open.org>
|
Cc:
|
"Will Hopkins"
<whopkins@bea.com>
|
Date:
|
08/14/2007 02:05 PM
|
Subject:
|
RE: [ws-sx] Issue
i148: Syntax of XPath for Signed, Encrypted and Required Elements
|
Attribute extensibility is required, not only for defining
namespaces, but also for additional attribute required for that sp:XPath
assertion. For example, given the following XPath Filter 2.0
<Sp:SignedEelements> assertion for the signature transformation:
<sp:SignedElements
XPathVersion="http://www.w3.org/2002/06/xmldsig-filter2"
xmlns:sp="..." >
<sp:XPath Filter="intersect"
xmlns:m="http://example">
//m:credit/num[@len>11]
</sp:XPath>
</sp:SignedElements>
The
attribute of Filter=”intersect” is just that <sp:XPath>
assertion, and it cannot be moved onto its parent, i.e. the
<sp:SignedElements> assertion.
The
namespace attributes also required for some SOAP messages. For example, in a
large SOAP document, there may have some elements with different namespace but
use the same namespace prefix. For example, in the following SOAP message, the
namespace prefix m and n1 in <m:getProductsAndPricingResponse> and <m:CreditInfo> elements have
different definitions:
<env:Envelope xmlns:env=". . ." …>
<env:Header>
. . .
</env:Header>
<env:Body . . .>
<m:getProductsAndPricingResponse xmlns:m="http://NCEN-WS3222:7001/ede/EDEService">
<result xmlns:n1="java:com.newcentury.response" soapenc:arrayType="n1:ProductGradePricingResponse[1]">
<ProductGradePricingResponse xsi:type="n1:ProductGradePricingResponse">
...
</ProductGradePricingResponse>
</result>
</m:getProductsAndPricingResponse>
<m:CreditInfo xmlns:m="http://myBank.com/creditInfo" n1="com.mybank.response">
<candidateProductProgramGrades soapenc:arrayType="n1:CandidateProductProgramGrade">
. . .
</m:CreditInfo>
</env:Body>
</env:Envelope>
If we
want to specify policy for signature and/or encryption for both <m:getProductsAndPricingResponse> and <m:CreditInfo> elements,
putting namespace attributes in the <sp:SignedElements> or
<sp:EncryptedElements> assertions will not work. It has to define
namespace attribute of m and n1 separately for each <sp:Xpath> assertion.
Therefore,
the syntax changes for <sp:XPath> assertion from <sp:XPath> to <sp:XPath ...>
is required for more flexible of policy specifying.
Best
regards,
Symon Chang
BEA
Systems Inc.
From: Marc Goodner [mailto:mgoodner@microsoft.com]
Sent: Tuesday, August 07, 2007 7:30 AM
To: Greg Carpenter; Symon Chang;
ws-sx@lists.oasis-open.org
Subject: RE: [ws-sx] Issue i148: Syntax of XPath for Signed,
Encrypted and Required Elements
Attribute
extensibility is not required in order to define a namespace. Also, sp:XPath is
not an assertion, it is a parameter that qualifies the policy assertion in
which it appears. This means that wsp:Optional is not valid for use on
sp:XPath. The use of wsp:Optional is permitted for each of the policy
assertions that has an sp:XPath parameter, i.e. the sp:EncryptedElements
assertion.
From: Greg Carpenter
Sent: Friday, August 03, 2007 4:21 AM
To: Symon Chang;
ws-sx@lists.oasis-open.org
Cc: Marc Goodner
Subject: [ws-sx] Issue i148: Syntax of XPath for Signed, Encrypted
and Required Elements
Issue
i148
From: Symon
Chang [mailto:sychang@bea.com]
Sent: Thursday, August 02, 2007 8:38 PM
To: ws-sx@lists.oasis-open.org
Cc: Marc Goodner
Subject: [ws-sx] NEW Issue: Syntax of XPath for Signed, Encrypted
and Required Elements
PLEASE DO NOT
REPLY TO THIS EMAIL OR START A DISCUSSISON THREAD UNTIL THE ISSUE IS ASSIGNED A
NUMBER.
The issues
coordinators will notify the list when that has occurred.
Protocol: ws-sp
http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702/ws-securitypolicy-1.2-spec-os.pdf
Artifact: spec
Type: design
Title: Syntax of XPath for Signed, Encrypted and Required Elements
Description:
The syntax of
XPath Assertion should be changed from <sp:XPath> to <sp:XPath ...>
This is
related to the following four assertions:
· SignedElements Assertion – Section
4.1.2
· EncryptedElements Assertion – Section
4.2.2
· ContentEncryptedElements Assertion –
Section 4.2.3
· RequiredElements Assertion – Section
4.3.1
Syntax
from the current spec like this for the EncryptedElement:
<sp:EncryptedElements
XPathVersion="xs:anyURI"?
xmlns:sp="..." ... >
<sp:XPath>xs:string</sp:XPath>+
...
</sp:EncryptedElements>
|
However,
the policy for specify an Xpath element to be encrypted will not work. For
example, if we use this for encryption of the ProductGradePricingResponse
element, the following policy is broken. This is due to the namespace of env
and m is not defined.
<wsp:Policy
xmlns:wsp="http://schemas.xmlsoap.org/ws/2004/09/policy"
xmlns:sp="http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200512" >
<sp:EncryptedElements XPathVersion="http://www.w3.org/TR/1999/REC-xpath-19991116">
<sp:XPath>/env:Envelope/env:Body/m:getProductsAndPricingResponse/result/ProductGradePricingResponse
</sp:XPath>
</sp:EncryptedElements>
</wsp:Policy>
The following
policy will be better:
<wsp:Policy
xmlns:wsp="http://schemas.xmlsoap.org/ws/2004/09/policy"
xmlns:sp="http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702" >
<sp:EncryptedElements XPathVersion="http://www.w3.org/TR/1999/REC-xpath-19991116"
xmlns:env="http://schemas.xmlsoap.org/soap/envelope/">
<sp:XPath xmlns:m="http://www.soapbuyer.org/soapexample/message">
/env:Envelope/env:Body/m:getProductsAndPricingResponse/result/ProductGradePricingResponse</sp:XPath>
</sp:EncryptedElements>
</wsp:Policy>
The namespace
of the xpath string should be placed as attributes in either the element of
<sp:EncryptedElements>, or <sp:XPath > elements.
In addition,
if we want this encrypted element to be optional, then the policy example will
look like this:
<wsp:Policy
xmlns:wsp="http://schemas.xmlsoap.org/ws/2004/09/policy"
xmlns:sp="http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702" >
<sp:EncryptedElements XPathVersion="http://www.w3.org/TR/1999/REC-xpath-19991116"
xmlns:env="http://schemas.xmlsoap.org/soap/envelope/">
<sp:XPath xmlns:m=”http://www.soapbuyer.org/soapexample/message" wsp:Optional="true">
/env:Envelope/env:Body/m:getProductsAndPricingResponse/result/ProductGradePricingResponse</sp:XPath>
</sp:EncryptedElements>
</wsp:Policy>
Base on above
policy examples, the syntax of the XPath assertion should be <sp:XPath
...> instead of <sp:XPath>.
Related
issues:
None.
Proposed
Resolution:
The syntax on
the following sessions should be changed:
Section 4.1.2
SignedElements Assertion
Before:
<sp:SignedElements XPathVersion="xs:anyURI"?
xmlns:sp="..." ... >
<sp:XPath>xs:string</sp:XPath>+
...
</sp:SignedElements>
|
Change
to:
<sp:SignedElements XPathVersion="xs:anyURI"?
xmlns:sp="..." ... >
<sp:XPath ...>xs:string</sp:XPath>+
...
</sp:SignedElements>
|
Section
4.2.2 EncryptedElements Assertion
Before:
<sp:EncryptedElements
XPathVersion="xs:anyURI"?
xmlns:sp="..." ... >
<sp:XPath>xs:string</sp:XPath>+
...
</sp:EncryptedElements>
|
Change
to:
<sp:EncryptedElements
XPathVersion="xs:anyURI"?
xmlns:sp="..." ... >
<sp:XPath ...>xs:string</sp:XPath>+
...
</sp:EncryptedElements>
|
Section
4.2.3 ContentEncryptedElementsAssertion
Before:
<sp:ContentEncryptedElements
XPathVersion="xs:anyURI"?
xmlns:sp="..." ... >
<sp:XPath>xs:string</sp:XPath>+
...
</sp:ContentEncryptedElements>
|
Change
to:
<sp:ContentEncryptedElements
XPathVersion="xs:anyURI"?
xmlns:sp="..." ... >
<sp:XPath ...>xs:string</sp:XPath>+
...
</sp:ContentEncryptedElements>
|
Section
4.3.1 RequiredElementsAssertion
Before:
<sp: RequiredElements
XPathVersion="xs:anyURI"?
xmlns:sp="..." ... >
<sp:XPath>xs:string</sp:XPath>+
...
</sp: RequiredElements>
|
Change
to:
<sp:RequiredElements XPathVersion="xs:anyURI"?
xmlns:sp="..." ... >
<sp:XPath ...>xs:string</sp:XPath>+
...
</sp:RequiredElements>
|
Symon Chang
BEA Systems
Notice: This email message, together with any attachments, may contain information
of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be
confidential, proprietary, copyrighted and/or legally privileged, and is
intended solely for the use of the individual or entity named in this message.
If you are not the intended recipient, and have received this message in error,
please immediately return this by email and then delete it.
Notice: This email message, together with any attachments, may contain
information of BEA Systems, Inc., its subsidiaries and affiliated entities,
that may be confidential, proprietary, copyrighted and/or legally privileged,
and is intended solely for the use of the individual or entity named in this
message. If you are not the intended recipient, and have received this message
in error, please immediately return this by email and then delete it.