[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Summary of issue 3 changes ( was RE: [ws-sx] issue 003: use of the term binding in SecurityPolicy )
On the Feb 8th call, I got an action to summarize the agreed changes related to issue 3. Here is that summary; Line 228 - Add "Note that services might accept messages containing more tokens than those specified in policy" as a second sentence. Line 229 - Change to read "Any necessary key transport mechanisms" Line 230 - Change to read "Any required message elements (e.g. timestamps) in the wsse:Security header." Line 233 - Remove this bullet. Add a new bullet ( after line 232 ) that reads; "Various parameters, including those describing the algorithms to be used for canonicalization, signing and encryption." Cheers Gudge > -----Original Message----- > From: Martin Gudgin > Sent: 08 February 2006 06:40 > To: 'Prateek Mishra' > Cc: ws-sx@lists.oasis-open.org > Subject: RE: [ws-sx] issue 003: use of the term binding in > SecurityPolicy > > Prateek, > > Thanks for the response. My comments are inline prefixed with [MJG]. > > Regards > > Gudge > > > -----Original Message----- > > From: Prateek Mishra [mailto:prateek.mishra@oracle.com] > > Sent: 06 February 2006 22:29 > > To: Martin Gudgin > > Cc: ws-sx@lists.oasis-open.org > > Subject: Re: [ws-sx] issue 003: use of the term binding in > > SecurityPolicy > > > > 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> > > [MJG] > OK. Sounds like we are in agreement here. > > > > > >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> > > [MJG] > I guess my reasoning was that given we had a section called > Security Binding Properties, assertions that set those > properties would naturally be known as Security Binding > Property Assertions. However, if the TC wants to remove the > term, I'm not too concerned. > > > > > >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> > > [MJG] > Ah, I think I see the difference. My understanding is that > WS-SecurityPolicy defines the minimum (security) requirements > for communicating with the service. Clients may choose to do > more than the minimum. Some services might accept messages > that do more than the minimum. Some might not. For example, > with respect to tokens, the service might state a requirement > for, say, a Kerberos Protection Token, the client may choose > to also provide some form of supporting token. > > > > > >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> > > [MJG] > OK. So the bullet at line 229 should read; > > "Any necessary key transport mechanisms" > > > > > >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> > > [MJG] > Great. So the new text (at line 230) should read; > > "Any required message elements (e.g. timestamps) in the > wsse:Security header." > > > > > > >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> > > [MJG] > OK. Sounds like we should remove this bullet (line 233) then. > > > > > >Regarding the proposed additional text, would 'canonicalization' be > > >better than 'normalization'? > > > > > > > > > > > <PM> Yes, that would improve the proposed text </PM> > > [MJG] > Great. So we should add a new bullet after line 232 that reads; > > "Various parameters, including those describing the > algorithms to be used for canonicalization, signing and > encryption." > > > > > >Cheers > > > > > >Gudge > > > > > > > > > > > > > > >>-----Original Message----- > > >>From: Prateek Mishra [mailto:prateek.mishra@oracle.com] > > >>Sent: 27 January 2006 18:46 > > >>To: ws-sx@lists.oasis-open.org > > >>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 > > >> > > >> > > >> > > >> > > > > > > > > > > > > > > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]