Making sure existing WS-Trust STS services can be used to enforce the security of deployed web services is of high importance to customers who have invested into WS-Trust based security solutions. It's just a common sense for them.
CXF provides some very advanced support for securing communications between JAX-WS consumers and providers and delegating to STS for validating the security tokens. CXF JAX-RS endpoints rely on HTTPS. That is as far as it can get at the moment. That is sufficient in many cases but the fundamental issue is that customers who want to use STS can not depend on it for additionally securing JAX-RS endpoints.
Now, I've seen people talking about RESTifying STS services, i.e, making sure plain HTTP consumers can talk to it. That is probably a worthy idea as it is likely will make it easier to communicate with STS. It does not solve the issue of using STS for validating all sort of security tokens (SAML assertions, etc) though.
But the thing is that in CXF we have a very good integration between JAX-WS and JAX-RS frontends.
Reusing JAX-WS and WS-Security runtimes for talking to STS is the fastest and most effective way to ensure JAX-RS endpoints can also be protected with STS.
Right now, we've done a very small step forward, we can get Basic Authentication credentials validated by STS, see this section for more info.
More work will have to be done for supporting SAML assertions passed via HTTPS or as part of XML security protected payloads.
OAuth and OpenId are also there. CAS is there. Other efforts are under way. These are of interest to us. We have a brilliant OAuth contribution from Łukasz Moreń in the CXF sandbox. But at this stage the integration with WS-Trust/STS is of high priority.