In the CU "Security User Name Password Client" the current description (see additional notes) implies that the encryption of the password is something which depends on the security policy in the User Token Policy and by this wording also implies that a client needs to support either case. This would result in the requirement for products to support sending an unencrypted password over the wire. Though this is relevant for interoperability we have met the first vendors whose security department are not allowing such insecure behavior. As a result such products would currently not be considered compliant.

Proposal:
Split the CUs in 2 CUs were one describes the encrypted mechanism and the other one describes the unencrypted. Probably this results in having another "One of the CUs in this facet needs to be supported" CU as probably either case is valid.