You will have to look at the feasibility of putting everything in the body as well as achieving SOAP intermediary functionality. WS-Security is an elegant and generalized solution. The concept of security tokens pertains to username , X.509, or SAML tokens. For encryption, having EncryptedKey separate from EncryptedData is also an elegant and required feature. For Signature also, having signature separate from content makes sense. And think of what you can do once you have separated out tokens, EncryptedKey, and Signature - you can perform operations on them without damaging the original content - for example, you can sign the tokens, or encrypt them - tokens can be referred to in encryption or signatures - all these offer the advantages of brevity that you claim can be achieved by putting things directly in the body!
And, of course, you still have to address SOAP intermediary functionality even if you have achieved elegance and generalization. -rams > *question 1) * Is there other reasons why > WS-Security defines > especially security elments in header part of SOAP > message. > > As I mentioned in an original e-mail, I believe that > security element > defined with XML-Signature and XML-Encryption could > be located in > either header part or body part in SOAP messages. > > If it is possible, the former approach(using > WS-Security) could contain > more information in header and the latter would be > reverse. > > In web services applications, the flow of message > transactions could be > passed to an intended recipient by way of several > intemediaries. > In this case, which approach would be better from > the viewpoints of > message processing and decryption ? > > *question 2)* trade-off between two approaches(from > the viewpoints of > implementation or performance) ? > > Il-Gon Kim > __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
