RE: [ws-sx] Issue 77: Use of Section 8 from WS-SC forces applications to be WSS schema aware

["Jan Alexander" <janalex@microsoft.com>]

Prateek,

While I agree that sometimes you don't want to "polute" the application
data with elements from WSS namespace, I don't think this TC is the
right place to define a new mechanism to correlate security tokens with
the elements inside the message body because you can have the same
argument with WS-Addressing, WS-Policy or other "infrastructure"
elements appearing in the message body. In other words this is not
specific to the secure conversation or to the WS security.

For example, you will have the same issue if you want to use
EndpointReference from WS-Addressing specification to point to a WS
service endpoint from you message body. You could argue that this forces
the application to be WS-A schema aware too.

If this is an issue that you want to solve, you should provide a
solution that captures broader scope than WS-SX or WS security. The
solution needs to provide a way to correlate message body elements with
any infrastructure information that's being passed along with the
message body in the message. This shouldn't be specific to only SCTs or
security tokens but should be generic enough to allow such correlation
with any piece of infrastructure information, like for example endpoint
address or policy assertion.

Besides this there are bunch of technical issues with your proposal
below but I think we shouldn't spend much of the TC time discussing
those here as I believe this issue is way beyond the scope of WS-SX TC
work.

One additional observation: Section 8 describes one of the many possible
ways to reference SCT from the message body. It uses STR from the WSS
specification to do so since this fits with the vocabulary and
mechanisms defined in the underlying specifications. Please note that
section 8 does not mandate the application to use this mechanism if it
does not want to. Therefore I don't think section 8 "forces"
applications to be WSS schema aware; application can always choose to
use different referencing style.

Does this make sense?

Thanks,
--Jan

-----Original Message-----
From: Marc Goodner [mailto:mgoodner@microsoft.com] 
Sent: Tuesday, June 27, 2006 4:44 PM
To: Prateek Mishra; ws-sx@lists.oasis-open.org
Cc: Anish Karmarkar; ramana Turlapati
Subject: [ws-sx] Issue 77: Use of Section 8 from WS-SC forces
applications to be WSS schema aware

Issue 77...

-----Original Message-----
From: Prateek Mishra [mailto:prateek.mishra@oracle.com] 
Sent: Tuesday, June 27, 2006 12:31 PM
To: ws-sx@lists.oasis-open.org
Cc: Marc Goodner; Anish Karmarkar; ramana Turlapati
Subject: Use of Section 8 from WS-SC forces applications to be WSS
schema aware

*PLEASE DO NOT REPLY TO THIS EMAIL OR START A DISCUSSISON THREAD UNTIL
THE ISSUE IS ASSIGNED A NUMBER. *

*The issues coordinators will notify the list when that has occurred.*

* *

Protocol: ws-sc

ws-secureconversation-1.3-spec-ed-06

Artifact: spec

<>Type: design

Title:

Use of Section 8 in WS-SC forces applications to be WSS schema aware

Description:

In many application processing protocols, there is a need to correlate
security tokens with certain application messages.
For example, there may be an expectation that a specific key is
available when a certain message is processed.
To deal with this requirement, we need some means of "connecting" one or
more security tokens with an application message.

Section 8 of WS-SC describes one solution to this problem. It suggests
that application message itself can include a STR referring to a secuity
token. While this solves the problem it does so at the cost of
propagating knowledge of WSS schema (and version) to every application
protocol that uses this technique. This is a very intrusive solution
with a high cost in complexity.

Related issues:


Proposed Resolution:

We propose the replacement of Section 8 with the use of a technique
wherein the security token of interest is wrapped in a additional STR in
the security header. The STR usage attribute can carry an XPath
expression referencing the message body.

If necessary, the application processing layer can profile the usage
attribute in greater detail (it can carry a list of URIs).

For example:

<><SOAP>
<Header>
<wsse:Security>
<SecurityToken wsu:Id="ref1>...</SecurityToken> <SecurityTokenReference
usage="SOAP/Body/ApplicationMessage">
<wsse:Reference URI="#ref1"/>
</SecurityTokenReference>
</Header>
<Body>
<ApplicationMessage>
...
</ApplicationMessage>
</Body>

/------------------------------------/

I will pick the issue up and give it a number (in sequence), assigning
the individual who submitted the email as owner of the issue. I will
send an email to the list with the issue number once it is assigned. 
Subsequent mail threads should use the Issue xxx: format in the subject
line, where 'xxx' is the issue number.

Please include only one issue per email and do not engage in discussing
the issue until it is assigned a number so we don't have multiple
impossible to distinguish 'NEW Issue' threads on the list.

*/------------------------------------------/*

*/Issues tracking mechanism/*

*/------------------------------------------/*

I propose a tracking mechanism using XML/XSL, based on the WS-RX TC list
which was derived from the W3C WS-Addressing WG:

http://docs.oasis-open.org/ws-rx/issues/ReliableMessagingIssues.xml

We'll request this location from OASIS for WS-SX:

http://docs.oasis-open.org/ws-sx/issues/Issues.xml

At the issue level, the following will be tracked:

* Number

* Status

* Protocol

* Artifact

* Type

* Title

* Description

* Related Issues

* Origin (originator and link to originating email)

* Owner

* Proposal "x" (one for each proposal)

* Resolution (e.g., Proposal "x" accepted on [link to conf call / f2f
meeting notes detailing the acceptance]

I will update the issue list so that it is current prior to every TC
call or F2F.

Marc Goodner

Technical Diplomat

Microsoft Corporation

Tel: (425) 703-1903

Blog: http://spaces.msn.com/members/mrgoodner/