STS Validate Operation and token transformation

Hi-
I am working on an STS implementation. I would like to emphasize token
transformation, as that seems to be the most compelling value proposition in
WS-Trust. The Issue operation defines a token transformation from the
SupportingToken specified in the SecurityPolicy binding, to the
TokenType/KeyType specified in the invocation. I was hoping to use the
Validate operation as a more flexible token transformation invocation,
leveraging the variant where the TokenType is something other than
/RSTR/Status. In such a scheme, the TransportBinding could protect a
Validate invocation which could support multiple transformations, a more
flexible deployment model than protecting the Issue operation with a single
SecurityPolicy binding.

However, I noticed that in both the 2.7.8 and 3.0.3 code base, the
AbstractSTSClient does not write the KeyType in a Validate invocation, and
writes the KeyType only in an Issue operation. Without the KeyType, a robust
set of output token types cannot be defined. I’m wondering if I am
attempting to push WS-Trust beyond its intended uses - i.e. that token
transformation is best modeled by multiple STS instances, each supporting
the Issue operation, and each supporting a single SecurityPolicy binding
corresponding to one of the input token transformation types. In other
words, I’m wondering if the lack of a KeyType specification in the Validate
invocation is not a bug/oversight, but rather a concession to the convention
dictating WS-Trust consumption.

Thoughts?

Thanks

Dirk