First, the corporation might maintain its policies in its own policy store and enforce those policies (such as allowing only books within each employee's field, limits to the dollar value of orders, etc.) before the request is sent to the Books.com Web service. The problem here is, how does the corporation know if a book is within an employee's field? It would have to get this information from somewhere, probably making additional Web service requests to Books.com or some other service that classifies books as part of the policy enforcement process.
In the second scenario, Books.com would store and enforce authorization policies supplied to it by the purchasing organization. Books.com could provide an interface (or a Web service) for the corporation's IT department to login and administrate user rights. This, of course, presumes that Books.com can provide such capabilities and that the purchasing organization is willing to "outsource" policy enforcement to Books.com.
In the third option, the corporation would store the authorization policies and attach them to each purchase request before it is sent to Books.com. Of course, you'd need a way to attach and secure the policies to each XML message, possibly using digital signatures or XML encryption to guarantee that the policies are authentic. You'd also need management software to find the appropriate policy and attach it to the message. The purchasing organization would then depend on Books.com to enforce the access control policies as part of processing the request.
The first option is simple since no coordination between the purchasing organization and Books.com is required. However, enforcing the access control policies requires the purchasing organization to make additional requests to classify each book before it can apply the access control policies. The second option delegates enforcement to Books.com. The issue here is whether this will scale if you try to set this same architecture up with 100's or 1000's of suppliers. The administrative complexity of making sure the right policies got to the right suppliers in the right format might be overwhelming. The third option allows the purchasing organization to outsource policy enforcement to books.com while still being able to dynamically change the access control policies. However, if you are going to try to set this same architecture up with many suppliers, standards will be necessary for representing the policies to be enforced. If you have to send policies in different formats to different suppliers the problem will be far too complex. Unfortunately, the necessary standards are not yet established (see the OASIS effort on XACML for insight into what such a standard might look like).
Which of these three scenarios is best? It's hard to say because each makes presumptions about capabilities and the nature of the relationship between the companies. You'll have to consider, too, if you're willing to delegate your corporate policies to others.
This was first published in November 2002