Re: [wss] SwA Profile draft 15 vote Dec 14

[Ron Monzillo <Ronald.Monzillo@Sun.COM>]

Frederick,

None of my comments need be addressed before the vote.

Frederick.Hirsch@nokia.com wrote:

>Ron
>
>Thanks for your review.
>
>Regarding the question, should we change this to be less ambiguous, for
>example:
>
> "When an attachment is encrypted, an <xenc:ReferenceList> element MAY
>be placed as a direct child of the <wsse:Security> header, but is not
>required."
>  
>
this clarification would address my concern (assuming you would be using 
it to
replace the entire paragraph beginning at line 338). 

Ron

>I assume the typos can be fixed after the vote, and if we agree this
>text can be changed as well.
>
>Thanks
>
>regards, Frederick
>
>Frederick Hirsch
>Nokia 
>
>-----Original Message-----
>From: ext Ron Monzillo [mailto:Ronald.Monzillo@Sun.COM] 
>Sent: Monday, December 13, 2004 4:47 PM
>To: Hirsch Frederick (Nokia-TP/Boston)
>Cc: wss@lists.oasis-open.org
>Subject: [wss] SwA Profile draft 15 vote Dec 14
>
>Frederick,
>
>I support the profile being made a committee draft.
>In that context, I have the following question:
>
>  
>
>>438:When an attachment is encrypted, no <xenc:ReferenceList> element 
>>is placed as a direct child of the <wsse:Security> header, since the 
>><xenc:EncryptedData> element is present in the header, eliminating the
>>    
>>
>
>  
>
>>need for this reference. Although the SOAP Message Security standard 
>>recommends the use of <xenc:ReferenceList>, this is only necessary 
>>when the <xenc:EncryptedData> element is not present in the 
>><wsse:Security> header.
>>    
>>
>
>
>Does the profile effectively prohibit the use of a ReferenceList (in a
>Security header) to reference an encrypted attachment?
>
>It would seem that a RL would be convenient when multiple things
>(including attachments) are being signed, perhaps not with an encrypted
>key.
>
>I noticed the folloiwng trivial typo
>
>  
>
>>148: Some of these attachments may be have
>>    
>>
>
>                                                       (extra word "be")
>
>  
>
>>a content type corresponding to XML, but do not contain the primary 
>>SOAP envelope to be processed.
>>    
>>
>
>
>similarly trivial, it likely would be better to remove the word "still" 
>from the following, as it seems to duplicate the notion of signing
>something that was already signed.
>
>  
>
>>240: it is possible to sign a MIME part that already contains a signed
>>    
>>
>
>  
>
>>object created by an application. It may still be sensible to sign 
>>such an
>>    
>>
>
> 
>
>----
>
>Ron
>
>
>
>To unsubscribe from this mailing list (and be removed from the roster of
>the OASIS TC), go to
>http://www.oasis-open.org/apps/org/workgroup/wss/members/leave_workgroup
>.php.
>
>  
>