2.6 Enforcement Process

This section partially addresses Req. D1.2-6.12-Sec.

When a Web Services call is made, there are several control points in the flow, as shown in Fig-11.

Fig-11: Arrangement of enforcement points in web service call flow (numbered callouts, per Fig-2.2 of D7.1).

1. Request is first controlled by a Requester, i.e. on Client side, for being an acceptable request. For example, if the request is about to submit data to the Service Provider, there may be several policies about what can be submitted.

2. The controls can have multiple facets, i.e. the application programmer may have programmed in some implicit policies, the organization that operates the application may have some policies of its own, the Trust Network is certain to have policies, and finally the User himself may have set up some policies (which may involve attaching sticky policies to the data). Conceptually these are addressed by a PEP contacting Master PDP which may contact stake holder specific PDPs. If different stake holder policies result in a conflict, the Master PDP implements a Conflict Resolution Policy to arrive at a decision. An alternative approach is to use Identity Governance Framework [IGF] CARML declaration to set up the PEP, or some part of it.

3. After request has been authorized to send, the Service Provider will examine if the request is acceptable using a similar stack of PEPs. Examination on Service Provider side is the "traditional" enforcement point that most people think about. It filters out inappropriate data requests as well as illicit writes.

4. When preparing to ship response, the Service Provider uses a PEP and Master PDP to further filter the response. Although the request side PEP should have made sure that only legitimate requests can ever get processed at the Service level, the returned results may still need some scrutiny, or this facility can be used to attach obligations and sticky policies to the returned data.

5. When Client receives the response, it examines it with a PEP and Master PDP. Such examination may be necessary to understand if there were sticky policies attached, or to perform obligations. Given the rules under which the Service Provider released the data, it may be that Client finds that it can not use the data for the intended purpose and therefore has to reject the request.

6. Not depicted, but logically part of the Client Request sending side are also

   1. discovery

   2. trust negotiation and establishment

   3. signing of request

7. Not depicted, but logically part of the Service Provider Request processing are also

   1. trust negotiation and establishment

   2. validation of message structure

   3. signature validation

8. Not depicted, but logically part of the Service Provider Response sending side are also

   1. signing of response

9. Not depicted, but logically part of the Client Response reception side are also

   1. validation of message structure

   2. validation of correlation

   3. signature validation

   4. processing obligations