# On the Need for a General REST-Security Framework
## 6 Towards a General REST-Security Framework
### REST Message Confidentiality (REMC)  
In layered systems such as those constrained by REST, confidentiality is of specific importance, since intermediate systems otherwise have plain-text access to traversing messages and those systems most commonly reside outside organizational boundaries of service providers and consumers. To prevent intermediaries from accessing sensitive message parts, the encryption of REST messages is a required foundational REST message security building block. REMA ensures the authenticity, integrity and--when using asymmetric digital signatures in conjunction with a suitable PKI--non-repudiation of REST-ful protocol messages. In order to approach a comprehensive REST message security, the confidentiality must be taken into account as well. Following the introduced methodology of this paper, a REST message confidentiality scheme has to define a general policy and algorithms for protecting REST messages from unauthorized data disclosure. Such a scheme then serves as a guideline for adapting and implementing confidentiality services for concrete REST-ful technologies including HTTP, CoAP and prospective ones (see Figure 10). Figure 10: General REST message confidentiality and its instantiation to concrete REST-ful protocols. In contrast to REMA, we do not specify the complete REMC framework, as this is not required to prove the proposed concept. REMA is sufficient and more suitable for this purpose, since there is much more related work available that can be used for evaluation. Still, we want to briefly discuss the requirements and challenges REST message confidentiality framework needs to tackle. Encrypting the whole REST message--so that only the endpoints can read and interpret the intention of it--does not conform with the self-descriptive messages and layered systems constraint, though. As mentioned before, the both principles require that the semantics of REST messages have to be visible to intermediaries for enabling intermediate processing [1]. This means that the key challenge of a REST message confidentiality scheme is to shield REST message from unauthorized data disclosure while retaining the self-descriptiveness for endpoints and authorized intermediate systems. Hence, distinct message elements, which are required for a particular intermediary in order to render the message self-describing, must remain accessible for this respective intermediary. Consequently, a general policy for encrypting REST messages need to consider and specify what message parts are required to be accessible for which class of intermediaries. This is especially true for caches, which must be able to read required message elements in order to store responses. As cacheability represents one of the core REST constraints for ensuring scalability, encrypted REST messages must therefore still provide the option to be cacheable. This aspect is, e.g., neglected by OSCORE [59] and [PERSON] et al. [57; 58]. The first approach does not consider cacheability of messages protected by OSCORE. The latter mechanism encrypts a REST message as a whole inducing so that an intermediate cache system is not able to interpret and store the message. The body of a REST message is special in this context. In some cases it may contain a resource representation in others it does not. As XML, JSON and CBOR [62] are prevalent data formats for the resource representation in REST-based service systems, such a resource representation might already been encrypted by an according data encryption technology, such as XML encryption [21], JSON web encryption [63] and CBOR encryption [64; 65] respectively. Independent of an existing application-controlled resource representation encryption, the REST layer needs to incorporate own mechanisms for ensuring the confidentiality of the body. This is especially important for resource representations which do not include an encryption scheme such as HTML [66], YAML [67] or CSV [68]. As discussed before, the access to the body can then be granted to classes of intermediaries requiring it.