Hi Martin,
Responses to your note are delimited by XML style delimiters with my
<initials>
>
>Regarding Security Binding Property, I note that the title of Section 6
>(line 1242) is 'Security Binding Properties'.
>
>
<PM> Agreed, this section does describe properties of security
bindings. </PM>
>Regarding Security Binding Property Assertion, I note that several
>assertions in section 7 indicate that they set property values, e.g
>lines 1514, 1517, 1584, 1587, 1590, 1592, 1594, 1596, 1598 et.al.
>
>
>
<PM> My comment is that the term "Security Binding Property Assertion"
does not occur in anywhere
in the text. So I am not really sure it helps when reading the document.
It is interesting to note that all of the usages
you cite take the form "Such-and-such assertion populates the following
property" or "this assertion sets the following
property to true". I would leave it up to the TC if they feel this term
should be retained as it does not receive any use.
</PM>
>Regarding the proposed change at line 228, I think this change is OK,
>although I'm not certain quite how it differs materially from the
>existing text. Please could you clarify what it is you think is allowed
>and/or precluded by your proposed text vs the existing text?
>
>
<PM> I could not follow what was meant by "minimum set of tokens that
will be used"; is there also a
"maximum set of tokens"? If so, how/where is this set described?
This point is mostly editorial so I will leave it at that.</PM>
>Regarding the proposed change at line 229, I believe an encrypted key
>token from WSS 1.1 would be such a mechanism. For example, Symmetric
>binding with an X509TOken as the [Protection Token].
>
>
<PM> The standard term for this is "Key Transport" and not "Key
transfer". I would prefer we use the former.
</PM>
>Regarding the proposed change at line 230, did you mean add 'in the
>wsse:Security header'? If not, I don't think I understand the proposed
>change.
>
>
<PM> Yes, your reading is what I meant. </PM>
>Regarding the proposed change at line 233, I'm inclined to agree as the
>signature confirmation aspect of an exchange is covered by the WSS11
>assertion.
>
>
<PM> My concern was that "correlation of messages" could be interpreted
much more broadly to topics covered
under reliable messaging or other messaging protocols</PM>
>Regarding the proposed additional text, would 'canonicalization' be
>better than 'normalization'?
>
>
>
<PM> Yes, that would improve the proposed text </PM>
>Cheers
>
>Gudge
>
>
>
>
>>-----Original Message-----
>>From: Prateek Mishra [mailto:]
>>Sent: 27 January 2006 18:46
>>To:
>>Subject: [ws-sx] issue 003: use of the term binding in SecurityPolicy
>>
>>At the F2F, I had asked a question about the use of term security
>>binding in Security Policy
>>and as to what was intended by use of this term. My comments here are
>>limited to this issue.
>>
>>The policy document does include a definition for this term
>>in Section
>>1.4, 2.3 (definition
>>at an abstract level) and a more precise definition for
>>security binding
>>assertion in Section 7.
>>
>>(1) The terms Security Binding Property and Security Binding Property
>>Assertion are defined in lines 76 and 79-80
>>but not otherwise used elsewhere. I would suggest these terms
>>be removed.
>>
>>(2) proposed changes to Security Binding defiinition (Section 2.3)
>>
>>lines 227 - 234 provide a detailed definition of binding. I would
>>propose the following changes:
>>
>>line 228: replace by "The set of acceptable tokens and the means of
>>their binding to messages"
>>
>>line 229: I dont see any "key transfer" mechanisms described
>>in any of
>>the bindings. In any case, I dont
>>understand what "key transfer" means and it isn't listed in
>>my copy of
>>the handbook of applied crypto.
>>
>>line 230: Add "in the SOAP header"
>>
>>line 233: Delete. I dont believe any of the bindings
>>described in this
>>document provide this facility.
>>
>>Add new line: Various parameters, including those describing the
>>algorithms to be used for normalization, signing and encryption.
>>
>>--------------------------------------------------------------
>>-----------------
>>prateek
>>
>>
>>
>>
>
>
>
