# On the Need for a General REST-Security Framework
## 1 Introduction  
Representational state transfer (REST) [1] is an architectural style for designing distributed services systems that scale at large. This is achieved by a set of defined architectural constraints. REST-based systems have to be, e.g., stateless and cacheable in order to ensure the propagated scalability. The uniform interface is another important constraint, which provides simplicity of interfaces and performance of components' interaction. The benefits coming along by adhering to these constraints are amongst the main driving forces for the increasing adoption of service systems based on REST. Currently only a limited set of technologies exists, which can serve as a foundation for implementing REST-based systems. HTTP [2] is by far the most dominant choice. This fact is the source for many misinterpretations in which REST is often equated with HTTP. Consequences emerging from this reasoning are many-fold. One related to security is the adoption of transport-oriented protection only, as common for conventional web-based applications by means of transport layer security (TLS) [3]. This is by far not sufficient as an exclusive safeguard for REST-based services, since they are constrained to be layered. Hence, these systems consist of intermediaries, which perform functions on the data path between a source host and destination host, most commonly on the opensystems interconnection (OSI) application layer [4]. Examples of such intermediate systems include caches, load-balancers, message routers, interceptors and proxies. In order to be able to perform their tasks, intermediate systems need to terminate transport security, which as a result does not reach from end to end. This remains opaque to the user and the obtained security level depends on many more stakeholders than the two endpoints. [5] revealed that many current security interceptors struggle with the implementation of transport-oriented security protocols, as they build intermediate systems that decrease security or even provide implementations that are severely broken. Also, transport-oriented security is not designed to fulfil the security requirements of ultra large scale (ULS) [6] systems and distributed service-oriented applications in general. The various entities involved in chained processing steps require adopting more fine-grained and message-related security means such as partial encryption and signature as, e.g., provided by the web services (WS)-security [7] standard for simple object access protocol (SOAP) based web services [8]. Moreover, different protocols following the REST principles are starting to emerge in domains other than the web or the cloud. For implementing internet of things (IoT) services, for instance, constraint application protocol (CoAP) [9] is taking root as REST-compliant protocol. Datagram transport layer security (DTLS) [10], the user datagram protocol (UDP) based flavor of TLS, is applicable as transport-oriented security measure here likewise. Again, the REST inherent constraint of composing systems out of layers, in many cases prohibits the adoption of transport-oriented security as single line of protection. Especially in the IoT domain, most of the use cases comprise high security demands, asking for more elaborated and pluralistic safeguards. The limited protection of transport-oriented security in REST-based systems has already been addressed by several research and development approaches as will be discussed thoroughly in Section 5. From these, some REST message security technologies have emerged that can be used in conjunction with transport security. Still, these approaches are available for certain technologies only, mainly HTTP and CoAP until now. As REST defines an abstract concept, its implementations are not restricted to these two particular technologies, though. Since REST has been established as an important paradigm for building large-scale distributed systems, more REST-ful protocols are expected to evolve prospectively.