I've not made it through the complete spec yet, but since we have
the Monday deadline and I may not get back to this for a few days, I thought I'd
send along my issues/comments through section 6.1.1.
Issues with WSS-Core-03-1103:
1.
I have a general issue with the use of the "utility"
namespace for defining elements and attributes used in wsse. It has not been
explicitly stated anywhere that I am aware of that the WS-Security TC is
responsible for defining this namespace and its associated schema. WS-Security
cannot just presume the existence of the utility namespace schema.
a.
If we ARE going to define this namespace and schema
in our TC, this needs to be explicit. HOWEVER, in this case I do not
believe we should use the generic Web Services namespace tag of "wsu".
Since it is the WS-Security TC defining it, it is NOT a general "Web
Services" utility schema. It is a "WS-Security Utility
namespace". The tag should thus be something such as "wssu"
for "WS-Security Utility".
b.
If we ARE defining this namespace, then our specifications
should FULLY define all elements and attributes that are defined in the current
utility schema. Some wsu elements are defined in WSS-Core-03-1103 (e.g. in section
10.3 on Timestamps), but most others are not.
c.
If there is an expectation that "utility"
is to be a truly general Web Services Utility namespace, then it may need to be
defined by another TC with input from other Web Services-oriented bodies. But
then, again, WSS won't be able to presume its existence at this time.
2.
[Section 4.2 and elsewhere] I do not see any value
in using "wsu:Id" when the base XML schema ID Type is available. This
is especially true since "wsu:Id" is simply defined in utility as
just being of type "xsd:ID". I believe it can only lead to
confusion (and minor additional processing overhead). I recommend removing the
use of wsu:Id in vavor of the base xsd:ID.
Editorial comments on WSS-Core-03-1103:
1.
General: All references in the text to external
documents and standards (e.g. XML DSig, our Bindings documents) should include cross-references
to the corresponding reference item in section 16.
2.
Line 109: [nit] need a space between SOAP and
extensions
3.
Lines 112-113: [nit] the spec isn't a basis
for constructing security models such as PKI and Kerberos. It is a basis securing
Web services within such security models.
4.
Line 115: add a sentence stating something like "The
token formats and semantics for using them with WS-Security are defined in the associated
"Bindings" (profiles?) documents" and then include cross
references. Also include the bindings cross references in section 16.
5.
Line 148: [nit] "der ivation" extra
space.
6.
Line 150: Another non-goal is the negation or
exchange of security policy information.
7.
Line 166: [nit] "note that different elements...
are from different namespaces" - suggest wording such as "note
that elements used in this specification are from a variety of namespaces"
8.
Lines 167-168: Need to use OASIS-based URL's
(this is already on the issues list)
9.
Line 195-197: Recommend generalizing the statement
since we have to deal with more than 2 threats - Perhaps "When
securing SOAP messages, various security threats need to be considered.
This includes, but is not limited to: 1) the message could be..."
(discussed on 11/5 con-call)
10.Line
218: [nit] "verifiable by, appropriate roles" - remove the
comma.
11.Line
222: [nit] "although in this specification does not" - delete
"in"
12.Line
241: [nit] need space between "SHOULD" and "reject"
13.Line
241: [nit] "reject a message with signature determined to" -
add "a" between "with" and "signature"
14.Line
294: "Lines (006) to (009)" should be "Lines (005) to (009)".
15.Line
295: [nit] "Note that here that the" - delete 2nd "that"
16.Line
299: [nit] I think the parenthetical comment is unnecessary.
17.Line
299: "The signature uses the XML Signature specification" - append
"identified by the ds namespace declaration in Line (002)"
18.Line
302: "Lines (011) to (018) describe the digital signature" -
actually, these lines describe what information is being signed and how -
it doesn't describe the actual signature. Also [nit] there shouldn't
be a line break between Line 303 and 304 since 304-307 are part of the Lines
(011) to (018) description.
19.Line
316: [nit] "elements such a signature references" should either be "elements
such as signature references" or "elements such as a signature
reference"
20.Line
330: [nit] "messag e" - delete the space.
21.Line
354: "arrtibute" - should be "attribute"
22.Line
405: [nit] "/ wsse:" should be "/wsse:" - delete the
space.
23.Line
407: [nit] "may omit an role" - should be "may omit a
role"
24.Line
426: change "can" to "MAY"
25.Line
433: "two additional optional elements" - delete "additional"
26.Line
434: "<wsse:UsernameToken>:" change to "<wsse:UsernameToken>
element:"
27.Line
435: Change "they are included" to "they MUST be included"
Rob Philpott
RSA Security Inc.
The Most Trusted Name in e-Security
Tel: 781-515-7115
Mobile: 617-510-0893
Fax: 781-515-7020
mailto:
-----Original Message-----
From: Anthony Nadalin [mailto:]
Sent: Tuesday, November 05, 2002 12:17 AM
To: Web Services Security
Subject: [wss] WSS-Core-03-1103
Here is an updated draft of WSS-Core with the following changes:
Proposed text to close item #20
Proposed text to close item #25
Proposed text to close item #26
Proposed text to close item #27
Clarified lines 733-735 with Ron's proposed text
(See attached file: WSS-Core-03-1103.pdf)
Anthony Nadalin | work 512.436.9568 | cell 512.289.4122
