[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Use of Section 8 from WS-SC forces applications to be WSS schemaaware
*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/
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]