In general the spec is pretty good.  I have a couple of nits and several places where I feel much stronger security 
considerations/warnings need to be incorporated.

Nits:
-	Need to update OGF copyright to 2007, 2008
-	I find it generally good practice to include references on first referral to external standards. The intro mentions a 
whole list of standards you rely on by short identifier only (WS-Addressing, WS-SecurityPolicy, SSL/TSL, WS-Security, …
.). It important to make sure all the normative specs are included in Section 13.1.  At least WS-Addressing is missing.

Introduction:
-	You define Authentication and state – “having each party cryptographically prove a ‘fact’ about themselves”. You 
should add – “ or prove knowledge of a shared secret such as a password”, since username/password is a supported 
mechanism.

Section 5.1
-	You state – “Authentication of the RECIPIENT to the SENDER for one-way communication generally requires encryption.
” If it is really one-way, you can’t do mutual authN.  You can secure the message so only the intended recipient can 
decrypt it, but that’s not really recipient authentication.

Section 6.2
-	R0502 notes that for one to claim FIPS compliance one must use FIPS approved algs. This is true. But, FIPS conformance
 is not defined in this spec so why is it a numbered requirement which means it is defining a conformance requirements 
of this specification?
-	
Section 6.3, 6.5
-	A note should be added stating the criticality of the INITIATOR properly validating the Server authentication. In 
particular, the certificate must chain to a properly configured set of trusted root CAs and the contained identifying 
information must map to the RESOURCE the INITIATOR intends to communicate with. If this is not done, the INITIATOR may 
inadvertently disclose information to an attacker or be vulnerable to undetected man-in-the-middle (MITM) attacks (see 
Section 7.2, 7.3 discussion).

Section 6.4, 6.6
-	The included security considerations discussion should be stronger.  It should be noted that the INITIATOR must verify
 the integrity of the EPR+RESOURCE_SECURITY_POLICY and ensure it was obtained from a trustworthy source. If this is not 
done, there is a very real possibility they could be mis-directed to an EPR belonging to an attacker whose certificate 
will validate against the one contained in the RESOURCE_SECURITY_POLICY. This can lead to inadvertent disclosure of 
information to an attacker or create an  undetected man-in-the-middle (MITM) attack (see Section 7.2, 7.3 discussion).
-	
Section 7.2, 7.3
-	I probably should have mentioned this before. I just wasn’t thinking about it when I looked at earlier drafts.

There are well known man-in-the-middle (MITM) attacks that can occur when combining two disjoint protocol security 
mechanisms operating at different layers. In particular, combining TLS/SSL X.509 server authentication with username/
password INITIATOR message authentication creates such a vulnerability. The basic problem is that the username/password 
message authentication isn’t bound to the transport channel security context. This can be exploited if a MITM service 
can induce the INITIATOR to create the initial TLS/SSL channel to it. Within the context of this spec, that could occur 
if the attacker can induce the INITIATOR to accept an incorrect EPR and then fail to properly confirm the server 
authentication matches the BES service they really intend to communicate with as discussed above. In a large, multi-
domain, environment with transient relationships this can be a challenge. Once the MITM has a transport channel to the 
INITIATOR, then they can create a TLS/SSL channel to the intended RESOURCE. The INITIATOR then sends the request message
 and the MITM receives it. At that point they can inspect the message or change it to anything they want and paste in 
the username/password authN from the original message. They can then send it along to the RESOURCE service who sees a...