RE: [wss] SwA profile Issue 364 action for TC members

["Brian LaMacchia" <bal@exchange.microsoft.com>]

> I don't think WSS should define any MUST's; that's WS-I's job.

Hmm, do you mean WS-Security specifically or anything defined by the WSS
group?  I thought the point of the WSS-SwA profile was to describe how
to apply WS-Security to SwA.  Shouldn't WSS-SwA tell me enough that I
can unambiguously apply WS-Security to SwA to the extent that
WS-Security itself is unambiguous?  

If WSS-SwA is supposed to be implementable without further profile docs
from WS-I, then it has to specify treatment for XML attachments, and the
only thing that makes sense is C14N by default.  If WSS-SwA is not
supposed to be implementable without further profile docs, then the WSS
group can either (a) specify C14N by default, and let specific profile
docs specify something else for the precise conditions where that would
work, or (b) explicitly punt on the issue of XML attachments to the
profile docs (that is, WSS-SwA could explicitly NOT support XML
attachments at all and leave the issue for another day).  Oh, and I
guess there's also an option (c) in which WSS-SwA explicitly prohibits
use of XML attachments as XML (text/xml type) and forces all XML
attachments to be encoded as something else. 

> Why?  It doesn't specify a single interoperable mandatory-to-implement
> signing mechanism or security token.

Signing mechanism is inherited from XMLDSIG (DSA-SHA1 required, RSA-SHA1
recommended).  And since WS-Security allows an embedded <ds:KeyInfo>, it
also inherits use of <ds:KeyValue> from XMLDSIG.

					--bal