W3C home > Mailing lists > Public > xml-dist-app@w3.org > October 2003

Re: Complete WSS Review

From: <noah_mendelsohn@us.ibm.com>
Date: Mon, 13 Oct 2003 18:04:04 -0400
To: Marc.Hadley@Sun.COM
Cc: xml-dist-app@w3.org
Message-ID: <OFC1F87679.BA9BB98B-ON85256DBE.0078528F@lotus.com>

Marc Hadley writes:

>>  I believe Noah has an action to provide alternate text for my 2.3 
Terminology comments.

Well, I'm supposed to, but I confess I'm forgetting the context a bit. 
Here's a start on an overall Meta comment.

=======================
SOAP 1.2 is the "Recommendation"-level version of SOAP, and we believe 
that WSS should be clear in its support for SOAP 1.2 as well as SOAP 1.1. 
Furthermore, among the changes that we believe to be improvements in SOAP 
1.2 was the more careful use of terminology and the more careful 
presentation of a rigorous processing model.  While we clearly understand 
the need for WSS to support SOAP 1.1 as well as SOAP 1.2, we strongly urge 
you to use SOAP 1.2 terminology wherever possible for abstractions such as 
nodes, intermediaries, roles, etc.  We furthermore encourage you to refer 
wherever appropriate to the SOAP 1.2 processing model, faults, etc.  In 
many cases we believe that this will aid not just in the use of WSS with 
SOAP 1.2, but in the precise presentation of the use of WSS with SOAP 1.1 
as well (since in many cases SOAP 1.1 has no precise explanation of terms 
that are carefully introduced in SOAP 1.2.)  Where SOAP 1.1 differs in its 
useage or terminology from SOAP 1.2, we suggest that you clearly explain 
the use of WSS in both environments.
=======================

New suggested version of 185 comment:

=======================
*** 185 "End-To-End Message Level Security - End-to-end message level 
security is established when a message that traverses multiple 
applications within...": We have suggested above the careful use of
SOAP 1.2 terminology, and we believe that this paragraph is 
an example.  SOAP 1.2 defines the SOAP message path as "The set of SOAP 
nodes 
through which a single SOAP message passes. This includes the initial 
SOAP sender, zero or more SOAP intermediaries, and an ultimate SOAP 
receiver." A single SOAP message doesn't traverse multiple applications 
unless they are SOAP intermediaries, if they are not then each 
application-application interaction is effectively a separate SOAP 
message exchange.
=======================

Is this close?  Thanks.

------------------------------------------------------------------
Noah Mendelsohn                              Voice: 1-617-693-4036
IBM Corporation                                Fax: 1-617-693-8676
One Rogers Street
Cambridge, MA 02142
------------------------------------------------------------------







Marc Hadley <Marc.Hadley@Sun.COM>
Sent by: xml-dist-app-request@w3.org
10/10/2003 05:44 PM

 
        To:     xml-dist-app@w3.org
        cc: 
        Subject:        Complete WSS Review



In fulfillment of my action item, here's the full WSS review in one 
mail. I reworded my comments against section 3.2 as agreed.

I believe Noah has an action to provide alternate text for my 2.3 
Terminology comments.

Regards,
Marc.

Web Services Security - W3C XMLP WG Review
------------------------------------------

This review refers to the Web Services Security committee 
specifications linked from the WSS TC homepage at:

http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=wss

The comments follow document order and indicate the sections of the 
document and line numbers where appropriate. Significant/serious issues 
are called out with ***, other issues are mainly editorial in nature.


Meta
----

"Comments are welcome from all interested parties and may be submitted 
to the WSS TC comment list at wss-comment@lists.oasis-open.org . If you 
are not yet subscribed to this list you will have to subscribe in order 
to post a comment; send a message to 
wss-comment-subscribe@lists.oasis-open.org Any comments made can be 
viewed at http://lists.oasis-open.org/archives/wss-comment/"

It is counter productive to force commentators to join a mailing list 
in order to post comments on a public draft - this will put off many 
casual reviewers. If the TC is serious about gathering public input on 
the documents then the list should be open to non-subscribers.


Web Services Security: SOAP Message Security
--------------------------------------------

This review refers to Web Services Security: SOAP Message Security 
located at
http://www.oasis-open.org/committees/download.php/3281/WSS-SOAPMessageSecurity-17-082703-merged.pdf

General
Needs a good proof reading session. There are numerous grammatical and 
punctuation errors, some of which are noted below. A pass needs to be 
made through the spec to ensure all the text uses consistent 
terminology, e.g. SOAP header and SOAP header block are used 
interchangeably thoughout the document. Suggest adopting the SOAP 1.2 
Recommendation terminology for clarity and consistency. Despite 
referring to SOAP 1.2, most, if not all, of the examples and namespace 
URIs are taken from previous versions of SOAP or early drafts of the 
SOAP 1.2 Recommendation - a pass through the document to ensure 
alignment with the SOAP 1.2 Recommendation is required.

Status
The TC home page describes documents that have achieved committee spec 
status. However the link points to a document whose status section 
indicates it is an 'interim draft'. Shouldn't the status section 
reflect the committee spec status ?

Abstract
"No specific type of security token is required the specification is 
designed to be extensible (e.g. support multiple security token 
formats).": insert a comma after 'required', change 'e.g.' to 'i.e. to'.

1. Introduction

*** The introduction talks about SOAP extensions. For consistency with 
SOAP 1.2, it should instead use the SOAP 1.2 terminology of features 
and modules. See section 3 of SOAP 1.2 Part 1.

110 "This specification provides three main mechanisms: ability to send 
security token as part...": 'a security token' or 'security tokens'.

1.1.1 Requirements

139, looks like this should be part of the bulletted list rather than a 
standalone paragraph.

2. Notational Conventions
Throughout the document certain words and phrases are highlighted in 
blue or red. E.g. the word SOAP is often highlighted in blue. There is 
no mention of any notational convention applicable to this coloring so 
its not clear if it has any particular meaning or intent. When printed 
in black and white its unlikely that such color information will be 
visible so it would be better to use some other typographic convention, 
e.g. italics or bold. On further reading it seems that blue coloring is 
intended to convey a bibiographic citation - a better means of 
indicating this is required.

Lines 150-155 seem to be in a different font though the reason for this 
is unclear.

2.2 Namespaces

*** 170, 171: Its surprising to see the WSS namespace URIs using the 
xmlsoap.org domain. This domain is the property of Microsoft Corp and 
they maintain control over what such namespace URI resolve to. For an 
OASIS standard one would expect namespace URIs to use the 
oasis-open.org domain instead.

175: Update the soap namespace to use the one from the SOAP 1.2 
Recommendation.

2.3 Terminology

*** 185 "End-To-End Message Level Security - End-to-end message level 
security is established when a message that traverses multiple 
applications within...": Should 'applications' be 'SOAP intermediaries' 
? SOAP 1.2 defines the SOAP message path as "The set of SOAP nodes 
through which a single SOAP message passes. This includes the initial 
SOAP sender, zero or more SOAP intermediaries, and an ultimate SOAP 
receiver." A single SOAP message doesn't traverse multiple applications 
unless they are SOAP intermediaries, if they are not then each 
application-application interaction is effectively a separate SOAP 
message exchange.

*** For clarity, adoption of the SOAP 1.2 terminology (Part 1, section 
1.3 Terminology) is recommended.

3.2 Message Protection

252 "This document defines syntax and semantics of signatures within 
<wsse:Security> element.": 'a ... element' or 'the ... element'.
253 "This document does not specify any signature appearing outside of 
<wsse:Security> element.": 'a ... element' or 'the ... element'.

*** SOAP 1.2 is XML Infoset based, SOAP bindings are required to 
preserve SOAP message infosets when transferring messages. In order to 
properly integrate with SOAP, the SOAP Message Security specifications 
need to be recast in Infoset terms. This will require the specification 
to normatively state the mapping from XML Infoset to the data object 
(typically an XPath nodeset) used as input to the constituent 
cryptographic operations (e.g. C14N).

3.3 Invalid or Missing Claims

255 "The message recipient SHOULD reject a message with an invalid 
signature, a message that is missing necessary claims and a message 
whose claims have unacceptable values as such messages are unauthorized 
(or malformed) message..": Bad grammar, replace with something like "A 
message recipient SHOULD reject messages containing invalid signatures, 
messages missing necessary claims or messages whose claims have 
unacceptable values. Such messages are unauthorized (or malformed)."

3.4 Example

Example uses a SOAP 1.1 envelope, change to use SOAP 1.2.

5 Security Header

400 "The <wsse:Security> header block provides a mechanism for 
attaching security-related information targeted at a specific recipient 
in a form of a SOAP role.": change 'in a form of a' to 'in the form of 
a'.

*** 406 "a message MAY have multiple <wsse:Security> header blocks if 
they are targeted for separate recipients." why can't a message contain 
multiple wsse:Security header blocks targetted at the same recipient, 
this seems like an uneccessary/arbitrary restriction. In addition it 
requires intermediaries to modify header blocks not targetted at them 
if they wish to insert security information targetted at a role for 
which there already exists a wsse:Security header block. An alternative 
design leveraging the role, relay capabilities of SOAP 1.2 is 
recommended.

*** 410 "The <wsse:Security> header block without a specified S:role 
MAY be consumed by anyone, but MUST NOT be removed prior to the final 
destination or endpoint." What does 'consumed' mean. SOAP 1.2 makes it 
clear that SOAP headers without a role attribute are equivalent to 
those with a role of 
"http://www.w3.org/2003/05/soap-envelope/role/ultimateReceiver". In 
both cases the ultimate receiver of the message is the target of the 
header block.

*** 450 "All compliant implementations MUST declare which profiles they 
support": how must they declare this ? This seems like an untestable 
assertion and should probably be dropped.

*** 455 "The optional mustUnderstand SOAP attribute on Security header 
simply means you are aware of the Web Services Security: SOAP Message 
Security specification, and there are no implied semantics.": No ! The 
mustUnderstand attribute has the semantics as defined by the SOAP 1.2 
specification. All SOAP nodes MUST abide by the SOAP processing model 
including generation of mustUnderstand faults if the header block is 
not understood. SOAP modules and features cannot override these 
semantics.

6.2 Username Token

495 "This is an extensibility mechanism to allow additional attributes, 
based on schemas, to be the <wsse:Username> element.": change 'to be 
the' to 'to be added to the'.

*** 503 "All compliant implementations MUST be able to process a 
<wsse:UsernameToken> element." The element is extensible, what should 
compliant implementations do with extensions they don't understand - 
ignore them, fault, ... Such extensibility semantics must be defined 
for all extensible elements, just making things extensible isn't 
sufficient.

506 Change example to use SOAP 1.2 envelope instead of SOAP 1.1.

6.3 Binary Security Tokens

545 "This attribute is extensible using XML namespaces.": Confusing, 
the attribute isn't extensible in itself, but its value could be said 
to be extensible though really just saying the attributes type is a XML 
qualified name is probably sufficient.

*** 548 /wsse:BinarySecurityToken/@EncodingType: this seems to be 
reinventing XML schema to a certain extent. Wouldn't it be better to 
allow child elements of BinarySecurityToken, one per type of encoding, 
that way a schema processor can verify the contents on behalf of the 
wsse processor.

*** Also, why use qualified names instead of URIs for identifying 
encoding types. URIs don't have the problem of maintaining namespace 
prefixes that demands the ns declaration location requirements outlined 
in this section. Use of qualified names in element and attribute values 
complicates things...

*** 558 "All compliant implementations MUST be able to process a 
<wsse:BinarySecurityToken> element.": same comment as for 
UsernameToken, what should an implementation do with a token of unknown 
type or one containing an extension that is not understood.

6.4 XML Tokens

*** 578 "This section presents the basic principles and framework for 
using XML-based security tokens." Is this section complete ? There's no 
trace of any principles or a framework.

7.1 SecurityTokenReference Element

*** Same comment as for BinarySecurityToken re extensibility semantics 
and requiring all implementations to be able to process the element.

8.1 Algorithms

*** Surprised that there is no mention of SOAP Message Normalization 
(sop12-n11n) here: 
http://www.w3.org/TR/2003/NOTE-soap12-n11n-20030328/. How does SOAP 
Message Security cope with the variations that soap12-n11n aims to 
removes from messages ?

*** 832 "Finally, if a sender wishes to sign a message before 
encryption, they should alter the order of the signature and encryption 
elements inside of the <wsse:Security> header.": alter in what way, 
this needs to be more specific.

839 "care MUST be taken in creating a signing policy that requires
signing of parts of the message that might legitimately be altered in 
transit.": shouldn't this say "care MUST be taken not to create a 
signing policy that requires signing of parts of the message that might 
legitimately be altered in transit." ?

841 "SOAP applications MUST satisfy the following conditions: The 
application MUST be capable of processing the required elements defined 
in the XML Signature specification.": SOAP applications or WSS 
implementation ? The latter is used elsewhere in the specification.

*** 855 "If overall message processing is to remain robust, 
intermediaries must exercise care that their transformations do not 
affect of a digitally signed component.": again a reference to 
soap12-n11n would seem to be in order here. Intermediaries are allowed 
to perform certain transformations, rather than implying the need for 
additional restrictions on intermediaires it seems more realistic to 
require normalization of the effects of such legal transformations.

9 Encryption

1026 "The combined process of encrypting portion(s) of a message and 
adding one of these a sub-elements is called an encryption step 
hereafter.": remove the 'a' between 'these' and 'sub-elements'.

9.3.1 Encryption

*** The suggested process for performing encryption would only include 
the data from the original message that was encrypted. All other data 
would be ommitted, suggest adding an additional step to copy in all the 
non-encrypted data.

*** 1166 "Parts of a SOAP message may be encrypted in such a way that 
they can be decrypted by an intermediary that is targeted by one of the 
SOAP headers. Consequently, the exact behavior of intermediaries with 
respect to encrypted data is undefined and requires an out-of-band 
agreement.": more detail required, why is the behaviour undefined ? 
Surely the intermediary would decrypt the parts as instructed by the 
corresponding header block ?

12 Error Handling

*** The specification should define the values of the 
Fault/Reason/Text, Fault/Code/Value and Fault/Code/Subcode/Value EIIs. 
Presumably the defined codes are the allowable values of the 
Fault/Code/Subcode/Value EIIs ? What values should be used for each 
code in the corresponding Fault/Reason/Text, Fault/Code/Value EIIs ?

16 References

1545 [SOAP12] W3C Working Draft, 26 June 2002: This should be updated 
to point to the SOAP 1.2 Recomendation.



Web Services Security: UsernamToken Profile
-------------------------------------------

This review refers to Web Services Security: UsernameToken Profile 
located at
http://www.oasis-open.org/committees/download.php/3154/WSS-Username-04- 
081103-merged.pdf

General

Needs a thorough proof reading session. Throughout the document certain 
words and phrases are highlighted in blue. E.g. the word SOAP is often 
highlighted in blue. There is no mention of any notational convention 
applicable to this coloring so its not clear if it has any particular 
meaning or intent. On further reading it seems that blue coloring is 
intended to convey a bibiographic citation - a better means of 
indicating this is required. In some places the common [nn] format is 
used for citations, the document should adopt a single consistent style 
throughout. Note that none of the [nn] citations are actually listed in 
the references section of the document !

Status
The TC home page describes documents that have achieved committee spec 
status. However the link points to a document whose status section 
indicates it is an 'interim draft'. Shouldn't the status section 
reflect the committee spec status ?

2. Notations and Terminology

2,1 Notational Conventions (should this be 2.1 - ie '.' instead of ',') 
?

Lines 54-59 seem to be in a different font though the reason for this 
is unclear.

67 "The current SOAP 1.2 namespace URI is used herein...": an old URI 
is used, needs updating to refelct the ns URI of the SOAP 1.2 
Recommendation.

3. Terminology

Repeats much of the text from section 2 ! It looks to me like section 3 
should be a subsection of section 2. The repeated text needs to be 
removed.

3 UsernameToken Extensions

87 Section number seems to be 'compromised'. There are two section 3s 
and two section 4s ! Renumbering required. None of the subsections of 
the second section 3 are numbered - is this deliberate ?

93 "providing": the letters 'd' and 'i' are colored purple for some 
reason.

99 "For example, if a server does not have access to the clear text of 
a password but does have the hash, then the hash is considered a 
password equivalent and can be used anywhere where a "password" is 
indicated in this specification.": its not clear from this description 
whether such a hash should be contained in a wsse:PasswordText or 
wsse:PasswordDigest typed Password element ?

Also note that the formatting of element names and types is not 
consistent. In some places a fixed width font is applied, in others no 
formatting is used. Is there any significance to such formatting 
chnages or does the document just need a consistency check ?

106 "..": there are quite a few instances of double full stops 
throughout the document, a simple search and replace of ".." for "." is 
required.

126 "1. First, it is recommended that web service providers reject any 
UsernameToken not using both nonce and creation timestamps.": 
recommended or RECOMMENDED as per RFC 2119 ? Same comment for next two 
points in the list and elsewhere in the document. Its not clear whether 
'recommended' is being used in the RFC 2119 sense or not. Suggest 
adopting the notations as described in section 2 (and again in the 
first section 3).

186, 204 Both examples use out of date SOAP 1.2 namespace URIs.

References

A number of out of date references are listed including SOAP 1.2 and 
XML Encryption. These should be updated to reflect the latest versions.



Web Services Security: X.509 Token Profile
------------------------------------------

This review refers to Web Services Security: X.509 Token Profile 
located at
http://www.oasis-open.org/committees/download.php/3214/WSS- 
X509%20draft%2010.pdf

General
Despite referring to SOAP 1.2, most, if not all, of the examples and 
namespace URIs are taken from previous versions of SOAP or early drafts 
of the SOAP 1.2 Recommendation - a pass through the document to ensure 
alignment with the SOAP 1.2 Recommendation is required.

Status
The TC home page describes documents that have achieved committee spec 
status. However the link points to a document whose status section 
indicates it is an 'interim draft'. Shouldn't the status section 
reflect the committee spec status ?

2.1 Notational Conventions

142 "This document uses the notational conventions defined in SOAP 
Message Security [WS-Security].": SOAP Message Security is colored 
blue, the reason for this isn't clear. I suspect its something related 
to the following citation, but that is already captured in the 
[WS-Security].

148 "The XML namespace URIs": XML namespace is colored blue, perhaps 
this should be followed by [XML-ns] ? Further occurances of this are 
not noted, the editors need to settle on a single citation format.

151, 152 Its surprising to see the WSS namespace URIs using the 
xmlsoap.org domain. This domain is the property of Microsoft Corp and 
they maintain control over what such namespace URI resolve to. For an 
OASIS standard one would expect namespace URIs to use the 
oasis-open.org domain instead.

153 The SOAP namespace is out of date, needs updating to the SOAP 1.2 
Recommendation namespace.

238, 285, 362 Update envelope namespace to SOAP 1.2 Recommendation 
namespace

3.3.1 Key Identifier

233 "Consequently implementations that use this form of reference 
within a signature SHOULD employ the wsse:SecurityTokenReference 
deferencing transform within a core barename XPointer reference to the 
signature key information in order to ensure that the referenced 
certificate is signed, and not just the ambiguous reference.": 
Editorial s/deferencing/dereferencing/. This could do with some 
rewording to make the intent clear, spelling out exactly what is being 
recommended (signing the ds:KeyInfo via an Xpointer reference along 
with the actual data to be signed ??). Also a reference to the 
definition of the wsse:SecurityTokenReference dereferencing transform 
would be useful here.

4 References

It would be useful to give URLs to those referenced specifications that 
are available online.

417 SOAP reference is to SOAP 1.1, should be to SOAP 1.2 Recommendation.

426, 427 references need to be filled in.

--
Marc Hadley <marc.hadley@sun.com>
Web Technologies and Standards, Sun Microsystems.
Received on Monday, 13 October 2003 18:05:21 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 7 December 2009 10:59:15 GMT