I read the above, or similar text, many times. But I never ”really” got it, till now. To figure it, its easiest to compare with OAUTH flows.
In the world of iphone apps, the vendor continues to own the app on your phone. Thus, the vendor can, in the form of the running app program, make calls to webservices that may insist that only software form “certain vendors” be permitted to connect. Oh, and they also want to know which of their customers the app is acting for (to then deliver data to the customer, presumably, via the app).
The oauth dance supports this scenario. You fire the app, it pops a web browser that tells the login page serving website to authentication you, using credentials you enter on its web pages. But, it also tells the website who it is, to give context. As a result of successful authentication, a code is sent to the *vendors* preferred website, waiting for such codes. Meantime, the web browser closes down and control returns to the app, which contacts its website to collect the code. Using the code, once gain the vendor asserts its own identity to the logon server in a call that asks it convert the code to a token.
in the ws-trust world, we see the same relationship between vendor identity (being the “owner” of the app) and the identity of the user applying the apps software to look at some data hosted at a third party.
Wit the actAs token, the role of the iphone app is played by the web application process on the web server. Said process is the vendor, and presents its “vendor id” to the ws-trust STS to authenticate. It also presents the users credentials represented in assertion form, previously learned from an IDP that did websso login… – required before getting the actAs token is even attempted. Unlike a onbehalf of token, the resulting token bears both identifies: the vendor and the user. For the Onbehalf case, while the vendor must identify itself, its identity is not inserted into the final token (bearing only the users identity information).
Ok. said like that… its just oauth , with different bit patterns, and a different ordering of websso and token issuing.