RE: [ws-rx] Proposed resolution for i007 WSS 1.0/1.1 token support

["Marc Goodner" <mgoodner@microsoft.com>]

I firmly disagree with Anish's suggestion that we should remove the STR.
The purpose of the STR in the CS is already established and in use. I
see no justification given for removing this already documented
composition with WSS. Furthermore our charter explicitly calls out that
we need to account for composition with WSS, "Efficient preservation of
the integrity of reliable contexts by composition with WS-Security or
other SOAP security mechanisms." 

Given this explicit citation that we ensure composition with WSS and the
importance of some of the new tokens in WSS 1.1 I do believe it is
important that we explicitly cite WSS 1.1 in the spec. This is
particularly true when you look forward to the potential of future work
at organizations like WS-I that might further constrain composition
scenarios. Calling out WSS 1.1 now will point out that they, and we,
should consider the impact of using WSS 1.1 token types such as SAML v2.

Regards,
Marc g

-----Original Message-----
From: Winkler, Steve [mailto:steve.winkler@sap.com] 
Sent: Friday, August 12, 2005 3:28 PM
To: Anish Karmarkar; Marc Goodner
Cc: ws-rx@lists.oasis-open.org
Subject: RE: [ws-rx] Proposed resolution for i007 WSS 1.0/1.1 token
support


+1 to Anish.  

Whereas I understand that security is an important consideration, I fail
to see the necessity of a hard dependency on it (regardless of version)
in the ReliableMessaging spec.  

Cheers,
Steve

----------------
Steve Winkler
SAP AG

> -----Original Message-----
> From: Anish Karmarkar [mailto:Anish.Karmarkar@oracle.com] 
> Sent: Thursday, Aug 11, 2005 1:45 PM
> To: Marc Goodner
> Cc: ws-rx@lists.oasis-open.org
> Subject: Re: [ws-rx] Proposed resolution for i007 WSS 1.0/1.1 
> token support
> 
> Marc Goodner wrote:
> > I believe we do not want to exclude WSS 1.1 tokens from 
> being used with 
> > the specification. I have examined the spec for what references are 
> > needed and whether or not we need any other changes such as new 
> > elements. We do not need to add anything in addition to the 
> existing 
> > /wsrm:CreateSequence/wsse:SecurityTokenReference as the new 
> 1.1 token 
> > all are referenceable from wsse:SecurityTokenReference. In addition 
> > there is an extensibility point defined in wsrm:CreateSequence that 
> > should accommodate other token types.
> > 
> 
> I'm beginning to wonder as to why have this element in the 
> spec at all, 
> since there is an extensibility point anyway. In terms of 
> composibility 
> of specs, it makes sense to stay silent on any security 
> tokens and let 
> extensibility be used for all kinds of composition (not just 
> security).
> 
> -Anish
> --
> 
> >  
> > 
> > To make it explicit that WSS 1.1 is supported I propose the 
> following 
> > changes to the specifications to allow referencing of WSS 1.1. The 
> > namespaces and references will need to be updated with the 
> final dates 
> > after public review closes.
> > 
> >  
> > 
> > WS-ReliableMessaging
> > 
> > Add prefix and namespace for WSS 1.1 to table at line 142:
> > 
> > wsse11  
> > 
> http://docs.oasis-open.org/wss/2005/xx/oasis-2005xx-wss-wssecu
> rity-secext-1.1.xsd 
> > 
> > 
> >  
> > 
> > Add reference to WSS 1.1 after [WSSecurity] (lines 844-847):
> > 
> > [WSSecurity11]
> > 
> > Web Services Security: SOAP Message Security 1.1 (WS-Security 2005)
> > 
> > 
> http://www.oasis-open.org/committees/download.php/13396/wss-v1
> .1-spec-pr-SOAPMessageSecurity-01.htm 
> > 
> > 
> > Anthony Nadalin, Chris Kaler, Ronald Monzillo, Phillip 
> Hallam-Baker, 
> > eds, OASIS Standard xxxxxx, final date
> > 
> >  
> > 
> > WS-ReliableMessagingPolicy
> > 
> > Add reference to WSS 1.1 after [WSS] (lines 306-308):
> > 
> > [WSSecurity11]
> > 
> > Web Services Security: SOAP Message Security 1.1 (WS-Security 2005)
> > 
> > 
> http://www.oasis-open.org/committees/download.php/13396/wss-v1
> .1-spec-pr-SOAPMessageSecurity-01.htm 
> > 
> > 
> > Anthony Nadalin, Chris Kaler, Ronald Monzillo, Phillip 
> Hallam-Baker, 
> > eds, OASIS Standard xxxxxx, final date
> > 
> >  
> > 
>