This section addresses Req. D1.2-3.8-Separate, D1.2-2.24-NoPanopt, D1.2-6.80-Separate.
When implementing practical systems, it often turns out that many of the architecturally designed boxes are in fact implementable by one software module. For example, with reference to Fig-2.3 of [TAS3ARCH], it is clear that a software module called "Service Requester" may exist, realizing Rq-PEP-Out, Rq-PEP-In, and Stack components all together without them being necessarily separable. Such composition does not harm interoperability as those submodules of Service Requester were always meant to be part of the same process and to communicate via function call interfaces. Indeed, the official TAS3 API, see section 3, lumps all these in one function call: tas3_call(). However all external interfaces from tas3_call(), such as authorization, discovery, and web service call, do speak standard protocols as profiled in this document.
It is ok for an implementation to compose, as an optimization, components that were meant to be wire protocol interfaces (see section 1.1), e.g. reach authorization by function call interface instead of XACML, as long as the implementation makes the same interface available over-the-wire by a mere configuration change (no recompile required/allowed).
From protocol perspective co-location of services (having two distinct service processes running on the same server hardware, or even running as separate processes under the same web server) does not present any problem, save for the complications of using nonstandard TCP/IP ports or requirement of configuring multiple IP addresses to same host.
From risk management and excessive visibility, or fat target, perspective, see T161-Panopticon threat in [TAS3COMPLIANCE], some services clearly should not be co-located. Division of responsibilities becomes important here and any two roles played by one system entity where they are co-located must not have a conflict of interest. In particular, the following are incompatible for co-location
anything vs. Audit
SP vs. IdP (some exceptions apply)
SP vs. ID Mapping and Discovery
SP vs. Delegation
IdP vs. Authorization (some exceptions apply)
Some services can be safely co-located, and often are:
IdP often includes Attribute Authority, ID Mapping, Discovery, and fat client Authentication Service. Although an IdP should not pretend to be a Policy Enforcement Point, it is clear that an IdP can exert such control by refusing to issue tokens that are necessary for functioning of the rest of the architecture.
SP and PEP are natural partners, indeed different facets of the same process