RE: [ws-sx] Proposal for Issue 78

["Hal Lockhart" <hlockhar@bea.com>]

Well my choice of MUST was deliberate and I stand by it. I don't think
the argument about breaking existing implementations holds water. We
have already made changes to all three specifications that break
existing implementations. For example, our implementation based on the
submitted version of WS-SP is not broken. 

This is a natural result of a standardization process when production
implementations precede the standards. We must look to the end state,
not the current point in time and educate our customers and partners
that this is a natural consequence of an accelerated standards process.

As far as standards go, the only standard I am aware of which has a
specific proposal to use this functionality is WS-RM, which is not yet
in final form.

My concern with RECOMMENDED is that it will force us to write extra code
to deal with this possibility as a receiver.

Hal 

> -----Original Message-----
> From: Jan Alexander [mailto:janalex@microsoft.com]
> Sent: Wednesday, July 19, 2006 1:58 AM
> To: Hal Lockhart; ws-sx@lists.oasis-open.org
> Subject: RE: [ws-sx] Proposal for Issue 78
> 
> Hal,
> 
> As a friendly amendment to this proposal I suggest to change the
> following:
> 
> When an SCT is referenced from outside the <Security> element, a
message
> independant referencing mechanisms MUST be used, to enable a cleanly
> layered processing model.
> 
> To:
> 
> When an SCT is referenced from outside the <Security> element, it is
> RECOMMENDED to use a message independent referencing mechanisms, to
> enable a cleanly layered processing model.
> 
> 
> The reason for this is that WSS and previous versions of WS-SC do not
> prohibit using message-local referencing style from outside the
security
> header if the SCT is itself present in the message. By making this
> requirement mandatory we can break existing implementations or
dependent
> protocols. I think that RECOMMENDED is more appropriate here for this
> reason.
> 
> Does this make sense?
> 
> Thanks,
> --Jan
> 
> -----Original Message-----
> From: Hal Lockhart [mailto:hlockhar@bea.com]
> Sent: Tuesday, July 18, 2006 8:26 AM
> To: ws-sx@lists.oasis-open.org
> Subject: [ws-sx] Proposal for Issue 78
> 
> I propose replacing section 8 with:
> 
> -----
> For a variety of reasons it may be necessary to reference a Security
> Context Token. These references can be broken into two general
> categories: references from within the <Security> element, generally
> used to indicate the key used in a signature or encryption operation
and
> references from other parts of the SOAP envelope, for example to
specify
> a token to be used in some specified way. References within the
> <Security> element can further be divided into reference to an SCT
found
> within the message and and referenes to a SCT not present in the
> message.
> 
> The Security Context Token does not support references to it using key
> identifiers or key names.  All references MUST either use an ID (to a
> wsu:Id attribute) or a <wsse:Reference> to the <wsc:Identifier>
element.
> 
> 
> 
> {Question: when the <wsc:Identifier> element value is used, is it
> necessary to also specify the <wsc:Instance> element value, if present
> to disambiguate the key?}
> 
> 
> References using an ID are message-specific. References using the
> <wsc:Identifier> element value are message independant.
> 
> When an SCT is referenced from outside the <Security> element, a
message
> independant referencing mechanisms MUST be used, to enable a cleanly
> layered processing model.
> 
> When an SCT is referenced from within the <Security> element, but the
> SCT is not present in the message, (presumably because it was
> transmitted in a previous message) a message independant referencing
> mechanism MUST be used.
> 
> When the SCT is referenced from within the <Security> element and is
> present in the message, a message-specific referencing mechanism MAY
be
> used.
> 
> 
> [examples]
> ----
> 
> Note the second paragraph is copied from lines 144-146. I suggest
> deleting these.
> 
> Hal