Base on the last WS-SX TC Minutes on Oct. 3
2007, http://www.oasis-open.org/apps/org/workgroup/ws-sx/email/archives/200710/msg00007.html
, It is proposed a new syntax for SignedElements Assertion just for XPath Filter
2.0.
The Xpath Filter 2.0 is WS-I BSP 1.0 number R3002. R3002 Any
SIG_REFERENCE to an element that does not have an ID attribute MUST contain a
TRANSFORM with an Algorithm attribute value of
"http://www.w3.org/2002/06/xmldsig-filter2".
The current <sp:SignedElements> assertion is unable to define the
XPath policy for signature, as XPath Flier 2.0 requires additional filter
attribute.
It is proposed to change the SignedElements assertion syntax to have an
additional new Xpath2 element for XPath Filter 2.0. That is the
proposed new SignedElements assertion with the choice of two elements:
1. XPath element, same as before
2. New Xpath2 element that has the filter attribute.
The syntax of Section 4.1.2 SignedElements Assertion
Before:
<sp:SignedElements
XPathVersion="xs:anyURI"?
xmlns:sp="..." ... >
<sp:XPath>xs:string</sp:XPath>+
...
</sp:SignedElements>
|
Proposing to change to:
<sp:SignedElements
XPathVersion="xs:anyURI"?
xmlns:sp="..." ... >
(<sp:XPath>xs:string</sp:XPath>+)
|
(<sp:XPath2
Filter="..." >xs:string</sp:XPath2>+)
...
</sp:SignedElements>
|
The schema will be changed to some thing like this:
<xs:sequence>
<xs:choice>
<xs:element name="XPath"
type="xs:string" minOccurs="1" maxOccurs="unbounded"
/>
<xs:element name="XPath2"
type="tns:XPath2Type" minOccurs="1" maxOccurs="unbounded"
/>
</xs:choice>
<xs:any minOccurs="0" maxOccurs="unbounded"
namespace="##other" processContents="lax"
/>
</xs:sequence>
Symon Chang
BEA Systems Inc.
From: Marc Goodner
[mailto:mgoodner@microsoft.com]
Sent: Wednesday, October 03, 2007
6:54 AM
To: Symon Chang;
ws-sx@lists.oasis-open.org
Subject: RE: [ws-sx] Issue i148:
Syntax of XPath for Signed, Encrypted and Required Elements
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.