- From: Marc Hadley <Marc.Hadley@Sun.COM>
- Date: Wed, 24 Sep 2003 11:27:35 -0400
- To: xml-dist-app@w3.org
In partial fulfillment of my action item from last week's telcon, the following is my initial review of the first part of the Web Services Security committee specification for consideration by the XMLP WG. Reviews of the other two parts will follow as time allows. Regards, Marc. Web Services Security - W3C XMLP WG Review ------------------------------------------ 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 linked from the WSS TC homepage at: http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=wss The comments follow document order, I have indicated 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 -------------------------------------------- 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, should the SOAP Message Security spec also be based on Infoset ? Specifically, is SOAP Message Security applicable to non-XML 1.0 serializations or is it tightly bound to XML 1.0 syntax ? If the former, then reference to elements, attributes etc should be replaced with the Infoset equivalents (element information item etc) and the relationship between the infoset and the octet stream used as input to cryptographic operations shoudl be clarified. If the latter then this restriction must be explicitly noted as its likely that future SOAP 1.2 bindings may choose alternate SOAP message serialization formats. 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. *** 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. -- Marc Hadley <marc.hadley@sun.com> Web Technologies and Standards, Sun Microsystems.
Received on Wednesday, 24 September 2003 11:27:52 UTC