OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

ws-sx message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [ws-sx] Issue i148: Syntax of XPath for Signed, Encrypted andRequired Elements


Symon:
You need to define the type of the Filter attribute and include it in 
the Schema.

All the best, Ashok

Symon Chang wrote:

> 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
>
> Inactive hide details for "Symon Chang" ---08/14/2007 02:05:40 
> PM---"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.
>
>
> 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. 



-- 
All the best, Ashok


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]