Re: [ws-sx] Groups - ws-sp-usecases-examples-draft-17-07.doc (ws-sp-usecases-examples-draft-17-07.doc) uploaded

[Anthony Nadalin <drsecure@us.ibm.com>]

So a few issues after spending some time doing a final reading of this update, I have made it about a quarter way through this document so far and will continue the review.

There seems to be some issues with the definition of actors in this paper as it has requestor and initiator, we should have 1 entity or state that these don't have to be 2 separate entities (in the definitions on lines 230 and 237), As the document is in consistent sometimes uses requestor and sometimes initiator and sometimes Requestor/Initiator. Also sometimes use the term "sender".

Line 260 reads
>The Requestor should generally be thought of as a separate physical entity from the Initiator
This should be deleted or re structured to indicate that these can be 1 logical entity or 2 separate physical entites

I don't think that the Figure 1 is correct and that a RP should not depicted here as we should support the attachment model that has been described in WS-PolicyAttachment.

Line 176 has the figure 1
The Validating Authority does not have to be an STS, we have not done any interops with the STS being a Validating Authority

On line 197 it reads

>Upon receipt of the WS-SP WSDL policy assertions, the Initiator then interacts with the Requestor and the Issuing Authority, as needed in order to meet the requirements specified by the WS-SP

It should read as the follow as there are different attachment models

>Upon receipt of the WS-SP policy assertions, the Initiator then interacts with the Requestor and the Issuing Authority, as needed in order to meet the requirements specified by the WS-SP

On line 211 it reads
>Finally, after assembling the necessary tokens, the Initiator will sign and encrypt the message as required by the WS-SP policy and send it to the Recipient.
and it should read
>Finally, after assembling the necessary tokens, the requestor or initiator MAY sign and/or encrypt the message as required by the WS-SP policy and send it to the Recipient.

On line 260 it reads
>The focus of WS-SP is the general policy and detailed policy assertions that are sent from the Recipient to the Initiator, however, the concepts in those policies generally require understanding specifically the relation of the Requestor and IssuingAuthority to the Initiator
and it should read
>The focus of WS-SP is the notion that policy assertions are attached to either the requestor or recipient however, the concepts in those policies generally require understanding specifically the relation of the parties involved (i.e requestor and recipient)

On line 313 it reads
>1.3 Normative References
But none of the specifications are listed

On line 379 it reads
>[WSS10-USERNAME]. All WS-Security compliant service implementations should support the
should read
>[WSS10-USERNAME]. All WS-Security compliant implementations should support the

Line 458 reads
>(M001) <wsse:Nonce>WScqanjCEAC4mQoBE07sAQ==</wsse:None>
should read
>(M001) <wsse:Nonce>WScqanjCEAC4mQoBE07sAQ==</wsse:Nonce>

Line 508 reads
>Additional credentials can be included as supporting tokens
should read
>Additional tokens can be included as supporting tokens

Delete line 579

Line 594 reads
>level policy and so appear as separate policies and are attached at Message Policy Subject.
should read
>level policy and so appear as separate policies and are attached at WSDL Message Policy Subject.

Line 827 reads
>(P001) <sp:X509Token sp:IncludeToken="http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200512/IncludeToken/Never">
should use current namespace as this conflicts with lines 160-162
Line 857 reads
><sp:UsernameToken sp:IncludeToken="http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200512/IncludeToken/AlwaysToRecipient">
should use current namespace as this conflicts with lines 160-162

Line 986 reads
>This scenario is based on WCF (Indigo) Interoperability Lab: Web Services Security September 1st, 2005 [WCF-PLUGFEST-INTEROP]
Not sure if the IPR allows us to reuse or reference this document

Line 1276 reads
>Lines (P004) – (P037) contain the AsymmetricBindingAssertion which indicates that the initiator’s token
should read
>Lines (P004) – (P037) contain the AsymmetricBinding assertion which indicates that the initiator’s token

Line 1291 reads
>Lines (P058) – (P069) contain a policy that is attached to the output message. Lines (P061) – (P063) require that the body of the output message must be signed. Lines (P064) – (P066) require the body of the output message must be encrypted.

Not sure how one know that this is attached to WSDL or that it has to be attached

Line 1544 reads
>required by the AsymmetricBindingAssertion. Because the RecipientTokenAssertion disallowed the token
should read
>required by the AsymmetricBinding assertion. Because the RecipientToken assertion disallowed the token

Line 1550 reads
>the message to contain the key used for verifying as dictated by the AsymmetricBindingAssertion
should read
>the message to contain the key used for verifying as dictated by the AsymmetricBinding assertion

Line 1554 reads
>This scenario is based on [WCF-PLUGFEST-INTEROP] (see also sec 2.1.4)
Not sure that the IPR allows this to be used

Line 1631 reads
>Lines (P004) – (P030) contain the SymmetricBindingAssertion which indicates that the derived key token
should read
>Lines (P004) – (P030) contain the SymmetricBinding assertion which indicates that the derived key token



Anthony Nadalin

rich.levinson---11/21/2007 02:09:29 AM---Completed the descriptive text portions of Sections 2.3.2.4 and 2.3.2.5

From:	rich.levinson@oracle.com
To:	ws-sx@lists.oasis-open.org
Date:	11/21/2007 02:09 AM
Subject:	[ws-sx] Groups - ws-sp-usecases-examples-draft-17-07.doc (ws-sp-usecases-examples-draft-17-07.doc) uploaded

---

Completed the descriptive text portions of Sections 2.3.2.4 and 2.3.2.5
(ws-sx Interop scenario).

This document should now be considered complete except for any issues that
may be raised against it. Note: section 2.3.2.5 is fairly extensive
including both the Service and STS policies, as well as requests and
responses with both the Service and STS. It is recommended that it be
reviewed carefully to ensure the accuracy of this complex yet becoming
fairly common scenario.

 -- Rich Levinson

The document revision named ws-sp-usecases-examples-draft-17-07.doc
(ws-sp-usecases-examples-draft-17-07.doc) has been submitted by Rich
Levinson to the OASIS Web Services Secure Exchange (WS-SX) TC document
repository.  This document is revision #11 of
ws-sp-usecases-examples-draft-10-09.doc.

Document Description:
Examples of usage of WS-SecurityPolicy to show how it can be applied to
several well known WS-Security scenarios that have been publicly conducted
in Interops as well as other scenarios of an illustrative nature.

View Document Details:
http://www.oasis-open.org/apps/org/workgroup/ws-sx/document.php?document_id=26176

Download Document:  
http://www.oasis-open.org/apps/org/workgroup/ws-sx/download.php/26176/ws-sp-usecases-examples-draft-17-07.doc

Revision:
This document is revision #11 of ws-sp-usecases-examples-draft-10-09.doc. 
The document details page referenced above will show the complete revision
history.


PLEASE NOTE:  If the above links do not work for you, your email application
may be breaking the link into two pieces.  You may be able to copy and paste
the entire link address into the address field of your web browser.

-OASIS Open Administration