Re: Complete WSS Review

Looks good to me.

Marc.

On Monday, Oct 13, 2003, at 18:04 US/Eastern, Noah Mendelsohn wrote:

> 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 <[email protected]>
> Sent by: [email protected]
> 10/10/2003 05:44 PM
>
>
>         To:     [email protected]
>         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 [email protected] . If you
> are not yet subscribed to this list you will have to subscribe in order
> to post a comment; send a message to
> [email protected] 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 <[email protected]>
> Web Technologies and Standards, Sun Microsystems.
>
>
>
>
>
--
Marc Hadley <[email protected]>
Web Technologies and Standards, Sun Microsystems.