Hi Colm- Wow - thanks for the quick action. What about OnBehalfOf/ActAs handling in the non-status validate invocation? The idea is to treat the non-status validate as semantically equivalent to an issue operation, where the input token passed to the validate invocation is equivalent to the SupportingToken required by the SecurityPolicy bindings protecting the issue operation(s).
I'm not necessarily asking for this functionality, I'm more asking your opinion on whether this notion is viable and contributes end-user value. I tend to think it does, if only because a single sts instance supporting a validate operation with a rich set of input and output token types, protected by the transport binding, may be simpler to deploy than a set of sts instances, each supporting the issue operation, and each with a SecurityPolicy binding specifying a SupportingToken corresponding one of the input token types supported by the non-status validate operation. But this reasoning may be completely specious. The fact that the cxf-sts has not implemented these concerns may indicate that I'm not understanding something. What do you think? I need to chew on this a bit, but if it turns out to make sense, I'd be happy to contribute a patch (if you think it's appropriate given the possible scope of the changes). Thanks Dirk -- View this message in context: http://cxf.547215.n5.nabble.com/STS-Validate-Operation-and-token-transformation-tp5753327p5753423.html Sent from the cxf-user mailing list archive at Nabble.com.
