Symon,
Thanks for getting this going again. I understand your aim in
getting support for XPath Filter in SP and have no objections to that. I want
to make sure we approach this from the right way.
So first off I know that we (the SX TC) can’t use the
Filter attribute from XPath Filter spec as it stands today. That spec needs to
be reved so that the filter attribute is made global and not local as it is
now. My understanding is that’s underway. I do not understand how the
Filter attribute could be used here without a namespace as you suggest below. I
don’t know of any other use cases to add extensibility to the XPath
assertion parameters than this XPath Filter example. Adding extensibility here
could be a namespace breaking change. I don’t think any of us want that.
The other thing is that the XPath element is an assertion
parameter, not an assertion. So wsp:Optional isn’t valid there. As worded
today multiple XPath assertion parameters in a SignedElements /
EncryptedElements assertion are treated as a union. Asking to add an optional
flag to this tells me you have something else in mind.
The above tell me this might be better approached as a new
assertion rather than updating the current ones. I have a feeling the use of
the XPath Filter spec with SP may be a little different than what people had in
mind for the current SignedElements / EncryptedElements assertions.
I understand what you are trying to support, just not convinced
that changing the existing assertion parameters is the best way to go about it.
I’m sure we can figure out a way to add support for XPath Filter to SP.
From: Symon Chang
[mailto:sychang@bea.com]
Sent: Wednesday, October 03, 2007 2:19 AM
To: ws-sx@lists.oasis-open.org
Subject: RE: [ws-sx] Issue i148: Syntax of XPath for Signed, Encrypted
and Required Elements
The issue of i148 is the <sp:XPath> element without the
attribute extensibility is very limited. XPath Filter 2.0 is just one example
of the limitation. For example, the following SignedElements assertion for
XPath Filter 2.0 is unable to do without the XPath attribute extensibility:
<sp:SignedElements XPathVersion="http://www.w3.org/2002/06/xmldsig-filter2"
xmlns:env="http://schemas.xmlsoap.org/soap/envelope/">
<sp:XPath xmlns:m="http://sample.org"
Filter="intersect">
/env:Envelope/env:Body/m:getProductsAndPricingResponse/result/ProductGradePricingResponse
</sp:XPath>
<sp:XPath xmlns: m="http://sample.org"
Filter="union">
/env:Envelope/env:Body/m:getProductsAndPricingResponse/result/ProductGradePricingResponse
</sp:XPath>
</sp:SignedElements>
Note that the Filter attribute in this example does not have
namespace. It is intentionally not to use namespace in other spec. We
don’t want to define the above example like this:
<sp:SignedElements XPathVersion="http://www.w3.org/2002/06/xmldsig-filter2"
xmlns:disg-xpath="http://www.w3.org/2002/06/xmldsig-filter2"
xmlns:env="http://schemas.xmlsoap.org/soap/envelope/">
<sp:XPath xmlns:m="http://sample.org"
disg-xpath:Filter="intersect">
/env:Envelope/env:Body/m:getProductsAndPricingResponse/result/ProductGradePricingResponse
</sp:XPath>
<sp:XPath xmlns: m="http://sample.org"
disg-xpath:Filter="union">
/env:Envelope/env:Body/m:getProductsAndPricingResponse/result/ProductGradePricingResponse
</sp:XPath>
</sp:SignedElements>
This is due to the Filter attribute defined in the XML-Signature
XPath Filter 2.0 schema is not a global attribute, and cannot be used be used
in the security policy. However, from the Security policy point of view, we
don’t have to re-use attributes from somebody else's schema. But we have
to provide a way to define the XPath element for signature. This is due to
XPath Filter 2.0 is required by WS-I BSP for Element Sgnature. In the case of
inserting the wsu:id for signature to reference the element is prohibited,
XPath Filter 2.0 is the only solution to go. Without XPath attribute
extensibility, we just unable to use XPath Filter 2.0 for digital signature.
The attribute extensibility is not only required for XPath Filter 2.0.
The XPath element for either signature or encryption assertions should be
flexible enough for the usage of any existing or future XPath tools. Another
example of needing the attribute extensibility for Xpath element is the wsp:optional=”true”
attribute on the XPath element. In the case of to sign or to encrypt a given
XPath element is optional, but other XPath elements are required. Say in the
SOAP message body, there are credit card information and social security number
elements that must be encrypted, while the encryption of the address element is
optional. Using wsp:optional=”true” attribute will make the
policy easier to read and process.
The current schema does not allow XPath element to have for
attribute extensibility. It is proposed to fix this limitation so that it can
meet the needs of any existing or future XPath tools. All we need is to add <xs:anyAttribute
namespace="##any"
processContents="lax"/> into the XPath element.
Best regards,
Symon Chang
BEA
Systems Inc.
From: Symon Chang
[mailto:sychang@bea.com]
Sent: Tuesday, August 21, 2007 4:49 PM
To: Martin Gudgin; Anthony Nadalin
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
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.
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.