RE: [wss] Backcompat

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

I think WSS 1.0 implementation will have the behaviour I note below
anyway. I just think we should probably call it out in the 1.1 spec so
that people implementing 1.1 are aware of what will happen if they send
messages using 1.1 constructs to a 1.0 endpoint.

Gudge 

> -----Original Message-----
> From: Symon Chang [mailto:schang@tibco.com] 
> Sent: 02 June 2005 02:53
> To: Martin Gudgin; WSS
> Cc: Paul Cotton
> Subject: RE: [wss] Backcompat
> 
> I don't understand this. How WSS 1.1 spec can define the behavior of a
> WSS 1.0 Receiver? 
> 
> If the WSS 1.0 Receiver is already out in the field, how can 
> you change
> it with the behavior defined in WSS 1.1 spec? 
> 
> If you can change the behavior, then why not just upgrade the receiver
> to handle 1.1 instead? 
> 
> 
> Symon Chang 
> Sr. Security Architect
> TIBCO Software Inc. 
> 
> -----Original Message-----
> From: Martin Gudgin [mailto:mgudgin@microsoft.com] 
> Sent: Monday, May 30, 2005 6:19 AM
> To: WSS
> Cc: Paul Cotton
> Subject: [wss] Backcompat
> 
> 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-m
essage-sec
> urity-1.1#ThumbprintSHA1,
> http://docs.oasis-open.org/wss/2005/xx/oasis-2005xx-wss-soap-m
essage-sec
> urity-1.1#EncryptedKey,
> http://docs.oasis-open.org/wss/2005/xx/oasis-2005xx-wss-soap-m
essage-103
> 3security-1.1#EncryptedKeySHA1,
> http://docs.oasis-open.org/wss/2005/xx/oasis-2005xx-wss-soap-m
essage-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-m
essage-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-me
ssage-secu
> rity-1.1#ThumbprintSHA1,
> http://docs.oasis-open.org/wss/2005/xx/oasis-2005xx-wss-soap-m
essage-103
> 3security-1.1#EncryptedKeySHA1 or
> http://docs.oasis-open.org/wss/2005/xx/oasis-2005xx-wss-soap-m
essage-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.
> 
> 			 
> 
> ---------------------------------------------------------------------
> To unsubscribe from this mail list, you must leave the OASIS TC that
> generates this mail.  You may a link to this group and all your TCs in
> OASIS
> at:
> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgr
oups.php 
> 
>