Backcompat

["Martin Gudgin" <mgudgin@microsoft.com>]

Dear TC,

Paul and I took an action at the last meeting to draft something on
backward compatibility. Here it is...

Gudge


OASIS WSS 1.1 defines several new XML elements; SignatureConfirmation,
EncryptedHeader, Salt, Iteration. It also defines several new URIs;
http://docs.oasis-open.org/wss/2005/xx/oasis-2005xx-wss-soap-message-sec
urity-1.1#ThumbprintSHA1,
http://docs.oasis-open.org/wss/2005/xx/oasis-2005xx-wss-soap-message-sec
urity-1.1#EncryptedKey,
http://docs.oasis-open.org/wss/2005/xx/oasis-2005xx-wss-soap-message-103
3security-1.1#EncryptedKeySHA1,
http://docs.oasis-open.org/wss/2005/xx/oasis-2005xx-wss-soap-message-sec
urity-1.1#X509ThumbprintSHA1

All elements and URIs that already existed in OASIS WSS 1.0 are
unchanged.

Proposed behaviour;

WSS 1.0 receivers:

1.	Generate a soap:mustUnderstand fault if any xenc:EncryptedHeader
has soap:mustUnderstand='1'. This will happen per normal SOAP processing
rules.

2.	Generate a fault (wsse:InvalidSecurity) if
wsse11:SignatureConfirmation is found inside wsse:Security.

3.	Generate a fault (wsse:UnsupportedSecurityToken) if
http://docs.oasis-open.org/wss/2005/xx/oasis-2005xx-wss-soap-message-sec
urity-1.1#EncryptedKey is specified for
wsse:SecurityTokenReference/wsse:Reference/@ValueType.

4.	Generate a fault (wsse:UnsupportedSecurityToken) if
wsse:SecurityTokenReference/wsse:KeyIdentifier/@ValueType is
ttp://docs.oasis-open.org/wss/2005/xx/oasis-2005xx-wss-soap-message-secu
rity-1.1#ThumbprintSHA1,
http://docs.oasis-open.org/wss/2005/xx/oasis-2005xx-wss-soap-message-103
3security-1.1#EncryptedKeySHA1 or
http://docs.oasis-open.org/wss/2005/xx/oasis-2005xx-wss-soap-message-sec
urity-1.1#X509ThumbprintSHA1

5.	Generate a fault (wsse:UnsupportedSecurityToken) if wsse11:Salt
or wsse11:Iteration are found in wsse:UsernameToken.

I don't believe we need to say anything about 1.1 receivers.