The tasks to be accomplished on the Service Responder, in the direct line of call, include
Listen for HTTP requests (typically done by platform)
Parse and validate a web services request, e.g. call tas3_wsp_validate(). This involves checking for valid signature from trusted authority.
Authorize the request, extracting from the request the pledges (in
Apply other filters and post processing steps ("etc")
Authorize each data item separately using input interceptor. For queries this is usually a no-op, but for creates or updates this is meaningful. When data is accepted for the repository, the authorization step can result in obligations or sticky-policies being written into the database along side the data itself.
The authorization is configurable according to Application Independent PEP configuration, described elsewhere, or Application Dependent PEP approach can be taken, calling the PDP directly ("PEP").
Authorize each returned data item separately using input interceptor. Usually applicable to query results. The per item authorization will apply systemwide and item specific policies (sticky policies) and obligations and produce a deny or permit-with-obligations response.
The authorization is configurable according to Application Independent PEP configuration, described elsewhere, or Application Dependent PEP approach can be taken, calling the PDP directly ("PEP").
Authorize the response in aggregate ("PEP-Rs-Out"). At this stage one of the most important verifications is to compare the pledges collected in step C ("PEP-Rs-In") and filter out any data whose obligations are stricter.
Optimization. It is possible to combine the pledges to obligations matching (in G) to the per result item authorization (F) by simply feeding the pledges as inputs to the PDP in (F). Such optimization can not, however, achieve all functionality of the G ("PEP-Rs-Out") as it is unable to see the bigger picture, i.e. consider all data together as a set. A typical example would be a rule against leaking simultaneously day and month of birth and year of birth.
Decorate the response with TAS3 specific SOAP headers. This is typically done by calling tas3_wsp_decorate().
Send the response. This is typically done by platform dependent means.