A few more Comments on UsernameToken Profile document (dated December 9,

Lines 129-131:

This paragraph seems to be untrue. The common scenario where the recipient stores usernames and their digested passwords can clearly work with requestors sending clear-text passwords. This is no different then using an HTTP Basic (transport-level equivalent) to pass a username and password. The server-side has to digest the supplied password and compare it with the stored digested password. In this scenario, the requestor has the plaintext password, but the recipient does not. I think the intent of this paragraph is that use of <wsse:PasswordDigest> is limited to cases where

Suggest that:

“Note that passwords of either type ( <wsse:PasswordText> or <wsse:PasswordDigest> ) can only be used if the plain text password (or password equivalent) is available to both the requestor and the recipient.”

Be changed to:

“Note that <wsse:PasswordDigest> can only be used if the plain text password (or password equivalent) is available to both the requestor and the recipient.”

Lines 135-136:

Unintentional paragraph break.

Lines 146, 148, and 150:

These paragraphs should probably be “bulleted”, since they are a list of “sample countermeasures” which go with the previous paragraph.

Line 162 (and following):

The section which describes the elements and attributes of the example in lines 155-160 does not include the <wsse:Username> element. While obvious as to what it would be, for completeness we should list it here. Something like the following:

/wsse:UsernameToken/Username

This required element specifies the "username” of the requestor; that is, the “claimed identity” of the requestor.

- Gene -

wss message