I've reviewed the federated cloud concept embodied in Figure 11. While the general scenario laid out is reasonable, there is no indication of how collaboration between Security Environments A and B is to be managed. There is also no indication of how the Security Mediation Server in Sec Env A is supposed to interact with the OAuth Server in Sec Env B, if at all. There clearly needs to be some type of federation manager / broker / agent that enables and manages any federated collaboration between Sec Envs A and B. With regards to the federation material cited in the CFP, Kurze et al., 2011, is a fine paper, but like many federation papers I've read, it focuses only on the possible functional benefits of federation. It does not discuss at all the machinery necessary to make federations work in a virtual Security Environment, e.g., federated identity, authentication, policy, authorization, resource discovery, etc. For this task to be successful within the TB14 time scale, the simplest possible available federation tooling needs to be identified. How this federation tooling enables the desired interactions between the WPS and WFS3.0 servers in another Sec Env needs to be clearly defined.
Answer: We agree that some sort of Federation manager/broker/agent is required. D147, the Secure Mediation Server, shall play this role with details documented in D023, the Federated Cloud ER. The goal of the CFP is to define the requirements and to give some direction to responders, but not to pre-define any solution. We would appreciate if you would submit a proposal in response to the CFP and help us defining all details and possible solutions during the Testbed. Testbed-14 addresses cloud federations for the first time. We therefore don't expect a fully functional service as a result, but solid ground work with clear guidance for future initiatives. updated: 2017-12-22 03:01:56