Hi Duane ,

Here are some additional comments on the express profile specs dated June 28, 2007.  Overall I think these are considerably improved over the initial drafts.

Secure-Addressing:

- Line 69: “Extend the requirements of the WS-I …” doesn’t sound right. Perhaps “Address additional grid interoperability requirements not covered in WS-i…”

- Line 86 “client to engage in secure communication.” How about “client to engage in secure communication and effectively use an OGSA web service”. This at least acknowledges concerns raised by David Chadwick about providing the tokens needed to authZ actions at the service.

- Line 173: It should be WS-SecurityPolicy 1.2, not 1.5.

- Line282: Add to end of the paragraph – “The INITIATOR may need the RECIPIENT’s token to supply a verifiable key used for message-level encryption of an initial request message.  

- Section 4.3: If we’re specifying a ‘secure endpoint reference’ then we should say something about how these EPR documents are distributed. There are several possible attacks from modifying these documents in transit (man-in-the-middle attacks, failing to sign and/or encrypt the message correctly). One option is to provide for signing of these documents by the service, in which case we should spec how they are signed. This is the most scalable approach. One could also assume distribution via trusted server over TLS/SSL, but that’s likely unacceptable  in a lot of environments.

Secure-Transport

- Line 248, 252: You reference the ciphersuites in WS-SecurityPolicy. This is a fine list of strong suites, but unfortunately doesn’t include a cross-reference to the TLS/SSL standard ciphersuite identifiers.  You provide an example translation on Line 384.  A simple mapping table would likely help out people reading this spec who are familiar with the TSL/SSL suite names.

- Line 312: Providing to EPR document signing would help address the issue you raise regarding EPRs coming from untrusted sources.

Secure-Soap

- Line 285: It says “.. this Profile requires encrypted communication”.  Based on prior discussions, I had thought it was agreed integrity protection was a MUST but confidentiality was optional?

- Section 7: I still have a problem with the wording here. Stating in C0701 that “UsernameToken credentials SHOULD NOT be used for message authentication..”, and then having Section 7.2 explain how to indicate they should be used for message level client authentication, seems  contradictory. C0701 also says username tokens “are not cryptographically verifiable.”. Of course, if one uses password digest (with nonce & timestamp) one can get cryptographically strong verification the sender knew the password and the token wasn’t pasted in from some other message. Was your intent in C0701 to warn people that username tokens should be used with caution since they: 1)  don’t provide a basis for ensuring overall message integrity; 2) the binding between the token and message is weak? Perhaps just remove C0701 since it’s the only numbered security consideration in the document and the requirements in Section 4.2 already ensure it can’t be used unless you’re using secure transport.

Regards,

Blair Dillaway