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.