RE: [ws-sx] Issue 22: XML tags of properties according to the properties

["Martin Gudgin" <mgudgin@microsoft.com>]

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
>