Artifact profile is our next item on the agenda. Back channel typically involves soap binding (SAML spec).
Hi Anil - thanks for all the answers.
At the moment I'd just like to see if/how SAML can be used in the case I'm looking at and it appears to me that just passing a SAML reference over plain HTTP could work well - and it's ok that SOAP is used internally to validate it...
That said, perhaps one option is to write a SOAP based OAuth-STS integration layer where the OAuth filter simply acts as an STS client and will ask the STS to validate a given reference...
I will brain dump based on my knowledge of oauth.
So basically you can use the STS as an issuer of both the request token and access token needed by OAuth service. For this to happen, Sergey, you need to implement the oauth token providers for the STS. (Sergey, also I suggest you move the resteasy-oauth code into PL federation project asap). Essentially, you have made the STS an oauth provider. Just jargon.
On a side note, we have been discussing about beefing the STS to be an attribute service (to provide the attributes for the tokens) and also an access control service( to make access decisions). We are currently leaning toward keeping the services separate (seperation of responsibilities). Basically, one client API (WSTrustClient or STSClient) should handle all the internal details.