OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

wss message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: Comments on oasis-0005-wss-username-token-profile-1[1].0.pdf



Here are my comments on the latest revision of the UsernameToken Profile. All of the line numbers correspond to oasis-0005-wss-username-token-profile-1[1].0.pdf


  1. Line 107: Should ‘must’ be MUST?
  2. Line 117: The term ‘providers’ is used to describe a web service provider, yet in line 119, they are called ‘producers.’ Should we use consistent terminology here?
  3. Lines 199 and 200: Why are double quotes used around the username and password? This makes it look like there is some sort of special syntax needed for a string literal when used in the token element content.
  4. It would be nice to see an example of the intermediate values for the Password_Digest computation. I tried the values given in the example starting with line 211, but the computation didn’t come out as expected. Can we include an example that has intermediate values? I think this will aid in the interoperability to know exactly how the computation works out (this is similar to what was done in XMLEnc for the symmetric key wrap examples).


I’ve taken a stab here to try and produce the nonce value shown in the example, but it didn’t come out correctly. Can someone point to my mistake or can we add this sort of example to the document?


Password_Digest => Base64 ( SHA-1 ( nonce + created + password ) )

Let s => nonce+created+password

s => WScqanjCEAC4mQoBE07sAQ==+ || 2003-07-16T01:24:32Z

s => C1 E6 08 DE 75 DD F0 B8 CC 35 59 2C 08 A1 55 F2 DD EB 80 78 77 47 ||

        32 30 30 33 2D 30 37 2D 31 36 54 30 31 3A 32 34 3A 33 32 5A

SHA1(s) => E3 71 E3 FE 26 45 99 E9 13 A7 31 C7 DC D1 ED D8 A1 3B 9F D5

Base 64(SHA1(s)) => 43Hj/iZFmekTpzHH3NHt2KE7n9U=


  1. The ‘password hash’ vs ‘password equivalent’ issue has already been beat to death, but at first read it is still confusing as to why the wsse:PasswordText and wsse:PasswordDigest elements can *both* contain a hash of a password. It seems like hashes of passwords should belong in the wsse:PasswordDigest element and unhashed passwords should belong in the wsse:PasswordText element, but in reality this is not the case.

    If I have a legacy system that just uses MD5 hashes of passwords, I need to use wsse:PasswordText, and not wsse:PasswordDigest. This is confusing. Can I propose some explanatory text as follows: (or can someone beat me on the head and say I’m wrong about this?)


“The wsse:PasswordText element should be used when hashed password equivalents that do not rely on a nonce or creation time are used, or when a digest algorithm other than SHA1 is used.”


  1. Corollary to #5, SHA-1 is hardwired as the hash algorithm. Do we want an extensibility point here?





Blake Dournaee

Senior Security Architect

Sarvega, Inc.





[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]