## 3 Literature Review
### Access Control and Cross Communication
[PERSON] _et al._[68] propose a delegation permit model that allows a user to grant a mashup \"delegation permits,\" which specify limited access rights to specific services. This approach to mashup delegation addresses two of the shortcomings of other methodologies. First, the user can restrict the scope of access available to the mashup in the back-end system. It also limits the length of time that the mashup has access to the system. A second alternative for providing access control to mashup applications is Open ID 2.0 [19]. There are four entities in the Open ID 2.0 model: the user, mashup, claimed identification, and identity provider. First, the user visits the mashup and provides a claimed identification which specifies which identity provider they wish to use to access the mashup (e.g. users can log into many online mashups using Twitter, Facebook, Yahoo or Google credentials). The mashup redirects the user to the identity provider where the user can log in. The identity provider then redirects the user back to the mashup with cryptographic proof that the user has been authenticated and also provides the mashup with any profile information the user chooses to release. Similar to the delegation permit model [68], Open ID 2.0 allows users to control the amount of time the mashup is authorized to access the identity provider [19]. As Table 2 illustrates, access control methods can fall into one of three different categories: anonymous, full delegation, and limited delegation. Anonymous access control would be a situation where publicly published data sources are being accessed (e.g. web services, RSS feeds). Situations where the mashup is given the user's credentials, and the backend system cannot differentiate between the user and the mashup, would be categorized as _full delegation_ (e.g. [69, 70]). Finally, approaches that provide the user some control over what access the mashup has to the data sources (e.g. [19, 68] would be considered _limited delegation_ because the amount of access and the length of time that it is granted to the mashup is restricted. A fundamental feature of mashup applications is that they allow users to combine data from a variety of sources. However, when the underlying data resources are available from different providers, security issues can arise. Cross communication between multiple back end systems poses a problem in mashup development because the current generation of web browsers cannot adequately support it. Currently, browsers are designed around a \"same origin\" policy, where data (or code) from one source can only interact with content from its same origin. Consequently, mashup developers must choose between security and functionality, which often results in giving uncontrolled cross domain execution through the use of <script> tags and extending the browser with plug-ins for cross domain interactions [17]. This sort of cross-site scripting introduces a computer security vulnerability which might enable malicious attackers to inject client-side script into web pages viewed by other users. It can also allow one back end system complete control over another [18]. Figure 1 illustrates a warning message from a Google personal page, where a gadget requires \"inlining\" which provides the gadget more control over the full Google page because it is not wrapped in an \"inline\" frame. This allow the gadget to change aspects of the Google page and may also allow the gadget to access the user's Google account [17]. [PERSON] _et al._[18] propose a model designed to address the cross communication issue by abstracting content from differing sources through a component based encapsulation. Instead of being proxied or using a <script> element, disparate components are loaded from their own server and then are isolated from the mashup code.