This is an additional comment/question from Frederik:

Assuming Key Derivation used to acquire the KeyData is the same as used for the SecureChannel:
The specification gives no information on the secret/nonces used for the key derivation. I see two options.

1. The client/server nonces are used like in OpenSecureChannel
   handshake. This would require the handshake to be signed/encrypted
   and there would not be any need to transmit the KeyData in the
   actual EncryptedSecet. In this case
2. The application creating the secret generates the KeyData from
   random data which is only known to the application itself.
   However in this case the signature which is computed over the
   secret proves at best integrity but not authenticity, because
   the receiving application has no prior knowledge about the
   signing key.

Change "The KeyData is encrypted with the PublicKey associated with the Certificate."

"The KeyData is encrypted with the PublicKey associated with the Certificate. The SigningKey, EncryptingKey and Initialization Vectors" are cryptographically generated random numbers with the length required by the SecurityPolicy.

7.41.2.3 EncryptedSecret Format
Changed to
The KeyData provides the keys needed for symmetric encryption.

7.41.2.4 RsaEncryptedSecret DataType
Table 189 – RsaEncryptedSecret structure
KeyData

Added:
The SigningKey, EncryptingKey and InitializationVector are cryptographically generated random numbers of the length required by the SecurityPolicy.

Agreed to changes edited in Dallas F2F.

Received more feedback:

"The KeyData is encrypted with the PublicKey associated with the Certificate. The SigningKey, EncryptingKey and Initialization Vectors are cryptographically generated random numbers with the length required by the SecurityPolicy."

This is probably good and necessary clarification, but only states the rather obvious. It should be clearly defined what party should generate the KeyData.
I assume this is done by the application creating the EncryptedSecret.
In this case the purpose of the signature should be clearly defined.
E.g proofing integrity and not authenticity.

Table 187 – EncryptedSecret layout
KeyData
Updated description to:
The key data used to create the keys needed for decrypting and verifying the payload using the SymmetricEncryptionAlgorithm specified by the SecurityPolicyUri. Each EncryptedSecret DataType describes how the key data is structured for different SecurityPolicies.

Table 189 – RsaEncryptedSecret structure
KeyData
Updated description to:
The KeyData is encrypted with the PublicKey associated with the consumer’s Certificate. The creator of the EncryptedSecret generates the SigningKey, EncryptingKey and InitializationVector using a cryptographic random number generator with the lengths required by the SecurityPolicy.

Signature
Updated description to:
The Signature calculated with the SigningKey using the SymmetricEncryptionAlgorithm from the SecurityPolicy.
The Signature calculated is calculated after encrypting the KeyData and the payload.
The Signature can only be checked after the KeyData is decrypted. It allows the receiver to verify that the message has not beem tampered with. It does not provide any information about who created the EncryptedSecret.

Agreed to changes edited in Virtual F2F.