Note sure what needs to be done - there is one ConformanceUnit for Username Password Security Policy and it describes that the password is to be encrypted by the algorithm provided by UserNameIdenty Token if the message is not encrypted.

This is the complete text in Part 4:

This token shall be encrypted if required by the SecurityPolicy.
The Server should specify a SecurityPolicy for the UserTokenPolicy if the SecureChannel has a SecurityPolicy of None.
If the token is encrypted the password shall be converted to a UTF8 ByteString and then serialized as shown in Table 169.
The Server shall decrypt the password and verify the ServerNonce.
If the SecurityPolicy is None then the password only contains the UTF-8 encoded password.

To me this is inconsistent since it says to provide a securitypolicy for the usertoken if the securitypolicy is none then later it say if security policy is none to not encrypt it.

I think this text needs to be fixed first to be very clear.

In my opinion, username/password and unencrypted password - should not be allowed (note encryption can be over VPN or something else).

So part 4 text should include something like:

This token shall be encrypted if required by the SecurityPolicy.
The Server should specify a SecurityPolicy for the UserTokenPolicy if the SecureChannel has a SecurityPolicy of None. If None is specified for the UserTokenPolicy and Security Policy is None then the password only contains the UTF-8 encoded password. This configuration should not be used unless the network is encrypted in some other manner such as a VPN. The use of this configuration without network encryption would result in a serious security fault, in that it would cause the appearance of a secure user access, but in actuality it would be completely insecure.

If the token is encrypted the password shall be converted to a UTF8 ByteString and then serialized as shown in Table 169.
The Server shall decrypt the password and verify the ServerNonce.

The conformance unit in any case does not need to be changed since it say to encrypt the password with the algorthim provided - the algorithm can be NONE- thus no encryption.

I think that another (I think we have mentioned on a CMP call previously) is in the case of embedded devices where they simply don't have the capacity to do encryption. I understand your viewpoint, but I really think that we need the flexibility to allow the vendors to use clear-text passwords so that there's more choice. I think that there's a general understanding that clear-text passwords are allowed when there's no security so it might be difficult to reverse that now?

I do agree that part 4 definitely needs some clarifications about clear-text passwords.

DEtermined in UA meeting that Part 4 need clarification , but no work is required for this conformance unit

agreed to in UA F2F.