First I must say that I disagree with Tony
about the source of the complexity here. While WS-Security (and friends) is
complex, IMO most of the complexity comes from the semantics of actually
insuring the intended security properties of a given message or message exchange.
Actually creating messages with well formed signatures and so forth is
relatively straightforward, especially if one is familiar with other security
protocols, such as Kerberos and TLS.
However, I believe that WS-SecurityPolicy
adds an order of magnitude of complexity in understanding all the various
assertion types, how they interact, where they can be attached and what
messages correspond to given policy combinations. That is evening ignoring
additional issues such as matching. I think that if we expect WS-SP to be
widely used, we need examples – lots of them. I believe the examples in the
current document are something like a bare minimum for people to really
understand how WS-SP works.
That said, I agree with Tony that we need
direct testing of the examples in the document. As Rich says, the key thing is
not can we process each other’s messages, but do the messages produced
correspond to the policies. That is what we should be testing. But unlike Rich,
I don’t think this is a completely manual process. In fact if we specify
enough, it may be possible to get the messages to exactly match a specified
pattern. In any event I think we should try.
So in the interest of being specific, I
propose we do the following.
1. Continue to report and fix problems in
the examples doc based on inspection or individual testing
2. When there are no open issues, vote the
document to CD
3. Conduct a Public Review
4. At the same time or afterwards, test
each of the examples in some kind of virtual interop
5. Drop any examples we cannot get sufficient
6. Vote the document to Committee Spec.
I guess I have to concede that this
requires a charter change, but I believe it is worth doing if we really want
people to be able to use WS-SP.
I would be interested to hear specific
proposals from other people.
From: Rich Levinson [mailto:firstname.lastname@example.org]
Sent: Wednesday, June 13, 2007
To: Anthony Nadalin
Cc: Raepple, Martin; Prateek
Subject: Re: [ws-sx] Further
discussion on WS-SX Examples document
I have thought about the "testing" of the
examples in the WS-SX Examples
document, especially since actually re-running the old WS-Security Interop
and other Interop scenarios is likely to be prohibitively expensive in terms
of required resources.
The way I see it is that the messages in the WS-SX Examples document
have already been tested since by and large they are simply copies of
the messages from the old Interop documents.
What is new here is the matching of the WS-SP policies against those
messages, which to a large degree is an exercise in manually examining
the WS-SP Policy vs the message contents, which is what is done in
the text portions of each example.
Therefore, imo, "testing" of these examples really is reviewing the
themselves for accuracy and then reviewing the text describing the relation
between the Policies and the covered message.
Of course, the accuracy of the xml for the Policies is important as well,
and this is where the current test results appear to be focused. However,
I think having the total focus on the XML parsing of the Policies, while
important, is not really addressing the real intent of the document.
The value of the document, imo, is showing people how to "do WS-SP"
for use cases that are likely to already to exist and need to be incorporated
to these emerging standards for advertising those services.
Anthony Nadalin wrote:
What I see is a document that has not been tested or
validated for correctness, I would rather have correctness then more
explanation on something that is potentially wrong.Members have also invested
time in trying to test this document. I can't imagine writing this document w/o
the ability to test it.
Anthony Nadalin | Work 512.838.0085 | Cell 512.289.4122
"Raepple, Martin" <email@example.com>
Most of the examples are actually based on interop documents (e.g.
from WS-I, WSS TC, WCF Plugfests). If not already implicitly or explicitly
included, I don't see any reason why we should not also add certain scenarios
from the interop document.
issue I see with taking forward the interop document is that there is only very
limited explanation given on the scenarios and most of them don't include the
corresponding policy at all. The TC asked for adding these detailled
explanations to the SP examples document, along with message samples, in a call
earlier this year. Members invested their time in updating the document
accordingly and reviewing it. Therefore, I think the example document should be
considered as the base document for taking forward, not the interop documents.
From: Anthony Nadalin [mailto:firstname.lastname@example.org]
Sent: Mittwoch, 13. Juni 2007 05:00
To: Prateek Mishra
Subject: Re: [ws-sx] Further discussion on WS-SX Examples document
1) I would not call WS-SecurityPolicy complex, I would call WS-Security,
WS-Trust and other specifications that actually define protocols complex.
WS-SecurityPolicy merely defines URIs that expresses specific wire format for
WS-Trust, WS-Security and WS-SecureConversation. We actually have examples
already, these are in the interop document, these are real examples that work
and have been validated. We have major concern over what is in the examples document
as to not being validated and examples that can actually achieve interop.
I don't see any mention of a examples document in the charter as an output
document, It seems it was important to change the charter to include the
WS-Policy 1.5, I would think that it would also be as important to make sure
the charter actually reflects the TC work.
So I don't think that the question on in scope is ill-posed at all. As we have
published WS-Security, WS-Trust and WS-SecureConversation w/o a examples
document, seems lost of TC do this, ones that actually produce examples
documents actually test the samples.
I don't believe that the document has been reviewed extensively or we would not
have found the issues we have found so far, once again this document has not
been validated or tested for actual correctness or interop. As people that read
a formal document produced by at TC expect the document to be correct and
Disagree, I think that this document needs to be validated and that we can
actually use and interop on the examples.
find the request to take this document to CD status as we don't even take our
interop documents to CD status and these are documents that have been validated
for correctness and interoperability, seems like these are the documents that
we should be taking forward.
Anthony Nadalin | Work 512.838.0085 | Cell 512.289.4122
Prateek Mishra <email@example.com>
This message responds to the following questions
from the May 30
conference call minutes:
1. Is an examples document in scope of the
2. What specific examples are or are not in
scope in an examples
3. What additional work or steps are
required before the examples
doc can progress to CD?
1. The starting point of the examples document
goes back to May 2006 when
this work was proposed by Ashok Malhotra. The
points made then were
SecurityPolicy specification is quite complext
(111 pages in its final
and that most people would have a difficult time
figuring out even
simple example policies.
The idea was to collect examples with
explanations, this would provide
starting point for many scenarios of interest.
I think the question of whether such a document is
"in scope" is
A more appropriate question would be: is it
appropriate to publish a
complex standard like
SecurityPolicy without an examples document?
The examples are needed as a kind of sanity-test
so that we can see how
features may be used to secure message exchanges
in a few cases of
interest to the TC.
Aside from the educational and labor-saving
aspects, it is also a
indication of openness in that
readers need not purchase proprietary products in
order to understand
the use of
the SecurityPolicy specification.
Finally, if we look at comparable specifications
W3C XML Schema we find them accompanied by a systematic
2. The examples document has been quite
extensively reviewed by many TC
and many suggestions for change have been made and
If any vendor has a specific concern with a
particular example, they
should explain what this is
and I am sure the Editors would update the
3. I believe that as soon as any remaining open
issues are resolved, we
should conduct a
CD vote for the document.