## 3 Conceptual Design
### Security and Privacy  
Information is passed around between information providers and information consumers through the IIP, and thus, communications between the three entities should be secured. Since REST interfaces are used in IIP, the communications security relies heavily on the application layer protocol used by these REST interfaces. In contrast to traditional web services technology that has a solid standardized security stack, such as WS-Security [50], RESTful web services do not have predefined and/or standardized security methods. Although RESTful web services were initially designed to be technology-agnostic [18], it has been commonly associated with the HTTP protocol. Thus, many of its security features are mainly inherited or simply adopted from the ones used for HTTP-based applications. Transport layer security (TLS), in the form of HTTP secure (HTTPS), has been the main ground for RESTful web services security, which provides a secure point-to-point communications channel on top of the transport layer. The HTTP basic access authentication scheme, which was initially specified in the HTTP/1.0 specification, provides a simple authentication mechanism to access resources on a web server (based on URIs) by means of username and password. This scheme is not considered to be a secure method of user authentication, as the username and password are transmitted through the network as plain text (unless used in conjunction with other secure transport mechanism, such as HTTPS). Nevertheless, the  
Figure 3: Relationships between the information provider, information channel (in the IIP) and information consumer. combination of HTTPS and HTTP basic authentication in many cases is enough for securing resources on a web server, as everything being sent through the wire is encrypted. From IIP's perspective (as shown in Figure 2a), information providers are applications that relay information from devices used by patients to information channels in the IIP. Likewise, information consumers are applications that consume/use information by subscribing to information channels in the IIP. To strengthen the privacy of information being exchanged between different applications through the IIP, access control to information channels should be maintained by the IIP. Identity-based access control is utilized, and an access control matrix is maintained. Information channels are registered by information providers (_i.e._, the owners), and each information channel has exactly one owner who can publish information (add new information) to the registered information channel (write access to the information channel). The access control matrix is used for authorizing information consumers to access/subscribe to information channels (read access to information channels). An information provider has the privilege of specifying which credentials (e.g., usernames in HTTP basic authentication scheme) have read access (_i.e._, can subscribe) to information channels it owns. Table 1 shows an example of an access control matrix maintained by the IIP. The rows in Table 1 represent the capabilities of users (information consumers) in the IIP, and the columns represent access control lists of information channels. Information consumers can list all information channels (by utilizing a catalog service provided by the IIP), but they can only access/subscribe to information channels listed in their capabilities lists. Since one of the IIP's main responsibilities is to manage information channels, the access control matrix can be simplified to access control lists only (_i.e._, the columns in Table 1). Whenever an information provider adds/removes a user (_i.e._, an information consumer) from/to its allowed user list of a specific information channel it owns, the IIP will update the access control list of the corresponding information channel. Figure 4 shows the relationship between an information provider and its registered information channels with their allowed user lists.