[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Feedback on SWA Profile-1.0-draft-06
Here is some feedback I got from our engineers on SWA Profile 1.0 Draft 6: 1) The Content-Transfer-Encoding stuff is not clear - Section 3.1.6 item 3 "If the Content-Transfer-Encoding for the attachment has changed from the value recorded, change the encoding of the type to match the original encoding. Update the Content-Transfer-Encoding header if MIME headers were included in the signature calculation." Not sure if this item should even be in there. How do you know if the Content-Transfer-Encoding had changed? Unless there is some attribute somewhere in the signature that tells you what the encoding was previously. There is an encoding attribute for encryption, but not for signatures 2) There appears to be no consideration for the case where you want to encrypt both the body and the attachments, which I think is likely to be the common case. 3) The spec references putting an EncryptedData element in the Security header, where WSS normally puts an EncryptedKey element with a ReferenceList. It is probably ok but you'll have one EncryptedData for the SOAP Body in the ReferenceList, but the EncryptedData for the attachment won't be in the ReferenceList. You'll end up with duplicate EncryptionKeys, which isn't as pretty as it could be. You'll have the EncryptedKey for the body in the Security header. You'll have the same EncryptedKey in the EncryptedData in the Security header for the attachment. Using the standard WSS approach of ReferenceList would eliminate this duplication, and also be more consistent with WSS. Dana S. Kaufman VP of Product Management Forum Systems, Inc. Tel: (781) 788-4232 E-Mail: dkaufman@forumsys.com Visit http://www.forumsys.com
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]