[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [ws-sx] Issue 22: XML tags of properties according to the properties
Comments inline. Cheers Gudge > -----Original Message----- > From: Marc Goodner [mailto:mgoodner@microsoft.com] > Sent: 09 February 2006 20:21 > To: Dittmann, Werner; ws-sx@lists.oasis-open.org > Subject: [ws-sx] Issue 22: XML tags of properties according > to the properties > > > This is now logged as issue 22. > > Marc Goodner > Technical Diplomat > Microsoft Corporation > Tel: (425) 703-1903 > Blog: http://spaces.msn.com/mrgoodner/ > > > -----Original Message----- > From: Dittmann, Werner [mailto:werner.dittmann@siemens.com] > Sent: Thursday, February 09, 2006 12:02 AM > To: ws-sx@lists.oasis-open.org > Cc: Marc Goodner > Subject: NEW Issue: XML tags of properties according to the properties > > 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 > ws-securitypolicy-1.2-spec-ed-01-r03-diff.pdf > > Artifact: spec > > Type: design / editorial > > Title: XML tags of properties according to the properties > > Description: > > In chapter 6 the spec introduces several properties to control some > behaviour. The actual XML tags to set the properties is given in > chapter 7. It is somehow difficult to link the properties defined in > chapter 6 to the actual XML tags defined in chapter 7. For example: > the [Protection Order] property can have several values. [MJG] Does two really count as 'several'? > Chapter 7 > then defines the real XML tags as e.g. <sp:EncryptBeforeSigning /> to > set this property. Because this property can have several values there > are several such XML tags to set this property. [MJG] No, there is only one XML element that sets this property, sp:EncryptBeforeSigning. Admittedly this element can appear in both the AsymmetricBinding and the SymmetricBinding, but it's the same element, yes? > However, these XML > names bear no direct link to the property. > > Related issues: > none > > Proposed Resolution: > > Use the following notation to set a multi value property: > > <sp:ProtectionOrder value="EncryptBeforeSigning" /> > > Such a notation would also simplify parsing because a parser has to > look for one tag name only and can use the attribute to set the > property's value. [MJG] Although I'm unconvinced that having a single tag name is actually a requirement, the parser only has to look for one tag name with the current design. > > Other properties are defined as boolean (true/false) > properties. However, the actual XML tag names to set the property > differ from the specified property name - this is somehow > confusing. Take the Signature Protection property as an example: to > set it you have to use the XML tag <sp:EncryptSignature />. Why no use > something like: > > <sp:SignatureProtection value="on" /> or > <sp:SignatureProtection value="Encrypt" /> or > just <sp:SignatureProtection /> > > or something similar to make clear which property is set or defined. [MJG] I note that the way that WS-Policy does assertion matching is based on QNames. Attributes are not considered when it comes to determining whether two assertions match. Child elements, apart from those nested inside wsp:Policy elements are not considered either. So a generic WS-Policy engine would consider; <wsp:Policy> <sp:SignatureProtection value="on" /> </wsp:Policy> and <wsp:Policy> <sp:SignatureProtection value="off" /> </wsp:Policy> as matching. For this reason, the assertions in WS-SecurityPolicy are designed to carry as much 'meaning' as is sensible in the QName ( or in nested policy ). In cases where having an accurate Qname would result in some form of combinatorial explosion, the design will tend towards an attribute or child element ( e.g. Realm for UsernameToken assertions ). > > > Werner Dittmann > Siemens COM MN CC BD TO > mailto:Werner.Dittmann@siemens.com > Tel: +49(0)89 636 50265 > Mobil: +49(0)172 85 85 245 >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]