Hi Tony,
Below are responses to the issues you raised. There appear to be 3 categories
of issue, so I numbered them 1-21 to refer to them up front here.
a. there are 2 issues about IPR policy: 15,20, that I think need to be
brought up to the TC to find out the answer, basically whether we
can ref the WCF Plugfest document. So, if anyone has info on this
please advise.
b. there are several issues that relate to the reference diagram on
line 176 and the introductory text that refs the diagram: 1,2,3,4,6,7.
I have included somewhat verbose responses to these issues to
try to explain what was intended and especially to clarify the
usage of the 6 logical actors defined on lines 229-250.
Of these issues 1,2,6,7 appear primarily to focus on the logical
vs physical distinction between the "Requestor" and "Initiator" actors.
Without this logical distinction it is extremely difficult to discuss the
examples in the text of each example in a consistent manner. Please
see if my responses help any with these.
Issue 3, I believe, has to do with the logical distinction between
the "Recipient" and "RelyingParty" actors. While less prominent
in the examples, than the requestor/initiator distinction, it is
included to provide the logical balance for discussion on the 2 sides
of the message exchanges. Again, please let me know if the response
helps.
Issue 4 has to do with authority actors on both sides of the
exchange, which are generally closely related to STS functionality,
which while possibly not explicitly included in the STS will be
at the very least be needed by the STS to perform its functions.
Again the purpose is to provide a consistent logical basis for
discussion within the examples. Please advise if response helps.
Generally, the actor terms in Fig 1 are intended to provide a logical
basis for discussion in the text of each example in a consistent
manner. In the individual examples the physical instantiation
of the actors can vary tremendously, but logically they should all
be present in each example in some form or other and the purpose
of the diagram is to provide a common reference when it is useful
in the example discussions.
c there are several primarily typo type issues that are not in the
the categories above.
Thanks,
Rich
-------- Original Message --------
| Subject: | Re: [ws-sx] Groups - ws-sp-usecases-examples-draft-17-07.doc (ws-sp-usecases-examples-draft-17-07.doc) uploaded |
|---|---|
| Date: | Tue, 11 Dec 2007 23:27:53 -0600 |
| From: | Anthony Nadalin <drsecure@us.ibm.com> |
| To: | rich.levinson@oracle.com |
| CC: | ws-sx@lists.oasis-open.org |
| References: | <20071121080741.13596.qmail@eos.oasis-open.org> |
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.
1. 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".
Ok, will clean up. Point is
that the person actually making the request is the
"Requestor", however, there
are 2 common use cases: 1. the Requestor is
at a browser and the request
is intercepted by a web service that can do
WS-Security and this web
service is the "Initiator" who actually handles
the message protection. 2.
the Requestor is at a web-service client
enabled workstation, where
the Requestor person making the request
is also in charge of the web
service client that is initiating the request,
in which case we have a
"Requestor/Initator".
A username/password requestor
is likely to be a separate requestor and initiator,
whereas an x509 requestor is likely to be a
combined requestor/initiator.
While these distinctions do
not impact the message formats, from an
examples point of view it
presents a trust model that a reader can
consider as to where the
trust lies in the types of WS-SecurityPolicy
structure is most appropriate
for their situation.
As I indicated above, I will
go thru and clean up accordingly, but wanted
to make sure the main point
wasn't lost as it relates to this review.
2. 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
Ok, will try to reword so it
is easier to understand.
3. 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.
I'm not sure I understand the
question here. In this diagram the WS-PolicyAttachment model
as best I can tell is embodied by the
"Recipient", which is reponsible for processing the
incoming message from a WS-Security
perspective. However, that Recipient may not
have the self-contained capability to
actually authenticate the Requestor/Initiator or to
authorize. Generally the authentication
would be done by the "Validating Authority"
and the authorization would be done by
the "Relying Party" both of which I would think
are generally backend services that are
outside the processing scope of the Recipient.
These backend services are
not generally brought into play in these scenarios except
possibly in the 4-step
2.3.2.5 where the STS can probably be considered to be
playing or at least
front-ending for both authorities in the diagram. Even in that case
I expect the Relying Party is still in
the backend to perform authorization before the
final service is delivered to the
Requestor.
The purpose of the diagram is
to provide a general trust model context, where I think
the 6 actors are logically
present in virtually every scenario, however, the physical
instantiation of each actor
in each scenario can vary a lot. I have tried to identify
clearly in each scenario
where the dividing lines are by use of the 6 actor terms
in lines 229-250.
However, as far as I can
tell, there is nothing inconsistent with WS-PolicyAttachment
unless I am missing something
in this issue.
4. 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
I think in use case 2.3.2.5,
where it is possible that the Relying Party will accept the
transaction based on the
protection given by the STS, that in this case the STS
can be considered the
Validating Authority.
But again, the purpose of the
diagram is to provide context for identifying
the actors in the overall
trust model and depending on who relies on whom
for what the physical
entities can be in almost any configuration as long as
each actor is invoked to
provide the trust.
5. 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
Ok, sounds like just drop out the "WSDL" from the text here.
6. 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.
This is
where I was making a logical distinction: the "Requestor" logically is
just the
user at a browser or other editor putting together the raw data for the
request,
providing a username/pwd, text for filling out form fields, etc. The
"Initiator"
logically is taking this raw data and "protecting" it cryptographically.
In the
browser calling a web service client over http this is generally where
the
Requestor and Initiator are both logically and physically divided.
Therefore
how about if I say: Finally, after assembling the necessary tokens, the
"initiator" or "requestor/initiator" MAY sign and/or encrypt the
message as required by the WS-SP policy and send it to the Recipient.
7. 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)
I think we
agree here, except that where you use the term "requestor" I would
substitute
"initiator" because of the logical definition I have been trying to
make
clear.
One point
is that the reason I chose the term "initiator" to be the one doing
all the
crypto work is that in WS-SP the terms "initiator" and "recipient" are
well
established as being the two ends of the message exchange. Plus there
are explicit terms
like InitiatorToken and RecipientToken that clearly have
to do with the
message protection aspects of things.
As far as
I can tell, WS-SP does not separately distinguish a "Requestor"
in the
sense I have applied it, which can create considerable ambiguity
when
trying to explain a trust model since the basis of end to end trust may
not be
part of the crypto-graphic message protection.
The
purpose of the logical model is to provide a basis for disambiguating
the
actors to help relate the technical details to real world use cases.
The
ambiguity arises because the crypto-graphic message protection
in many
cases can be used as the basis for end to end trust, but if
we take
that to be the general case then we lose the common user
at a
browser as a distinguishable actor.
8. On line 313 it reads
>1.3 Normative References
But none of the specifications are listed
OK, will
fix. These are all at the back (p118 section 3.1 normative, sec 3.2
non-normative)
9. 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
OK, will
fix.
10. Line 458 reads
>(M001) <wsse:Nonce>WScqanjCEAC4mQoBE07sAQ==</wsse:None>
should read
>(M001) <wsse:Nonce>WScqanjCEAC4mQoBE07sAQ==</wsse:Nonce>
OK, will fix.
11. Line 508 reads
>Additional credentials can be included as supporting tokens
should read
>Additional tokens can be included as supporting tokens
OK, will
fix.
12. Delete line 579
OK
13. 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.
Ok, will
add
14. 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
OK, will
fix. Also, appears elsewhere, will try to catch all.
15. 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
Good
point, let's bring it up at TC mtg to get a reading on what
can and
cannot be included, probably should be a separate issue.
16. 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
OK, will
fix.
17. 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
This was
generally explained in lines 588-591, which are in use case 2.3.1.
Probably
should put that expl in an up front section, maybe right after
line 317
in the main "Section 2" along with any other scenario-specific
conventions
that are used in multiple use cases. So, if 588-591 would
address
the issue then I can do that.
18. 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
Ok, will
fix.
19. 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
Ok, will
fix.
20. 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
OK, will
discuss at mtg as above.
21. 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
Ok, will
fix.
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