[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]