# On the Need for a General REST-Security Framework
## 6 Towards a General REST-Security Framework
### Formal Description of REST Messages  
Since REST is constrained to the client-server model in conjunction with the request-response model, it is always the client issuing a request message to which the server replies with a corresponding response. The request message space is denoted by \(R_{c}\) and the response message space is referred to as \(R_{s}\) respectively. The whole REST message space \(R\) is henceforth  
\[R:=R_{c}\cup R_{s}. \tag{1}\]  
The meta-data space \(M\) is composed of the set of resource meta-data \(M_{r}\), the set of resource representation meta-data \(M_{b}\) and the set of control data \(M_{c}\):  
\[M:=M_{r}\cup M_{b}\cup M_{c}. \tag{2}\]  
The control data set \(M_{c}\) consists of the set of request actions \(M_{ca}\), the set of response meanings \(M_{cm}\), the set of message parameterisation \(M_{cp}\) and the set of data to overwrite the default processing of a message \(M_{co}\):  
\[M_{c}:=M_{ca}\cup M_{cm}\cup M_{cp}\cup M_{co}. \tag{3}\]  
A REST message \(r\in R\) consists of two parts: a header \(h\) containing meta-data and a body \(b\) comprising a resource representation. With \(H\) denoting the header and \(B\) the body space, the structure of a REST message is defined as  
\[r:=h||delimiter||b,\{(r,h,b):r\in R\wedge h\in H\wedge(b\in B\lor b\in \emptyset)\}, \tag{4}\]  
where \(delimiter\) is a set of characters separating the header from the body and \(||\) represents the concatenation operation. Note, that the actual embodiment of the delimiter depends on the concrete implementation of the uniform interface, i.e., the service protocol. In case of a binary protocol, the delimiter set might even be empty. For the sake of readability but without the loss of generality, the following explanations will focus on text-based protocols only, since these protocols include additional challenges in terms of the ordering, normalization and separation of headers. To obtain an according description for binary protocols, these aspects can simply be omitted.  
A header \(h\) holds a subset \(\dot{M}\subset M\) of the meta-data entities:  
\[h:=\begin{cases}(\dot{M},i),&\text{if }r\in R_{c},\\ (\dot{M}),&\text{if }r\in R_{s}.\end{cases} \tag{5}\]  
If \(h\) is part of a request message, it additionally includes a resource identifier \(i\in I\), where \(I\) defines the set of resource identifiers. The constitution of \(h\) can further be characterized by the following policy:  
* A message \(r\in R\) comprising a resource representation must include at least the two resource representation meta-data entities \(m_{bl}\in M_{b}\) and \(m_{bt}\in M_{b}\) describing the length and the media type of the contained resource representation respectively.
* A request \(r\in R_{c}\) must contain at least one control data element \(m_{ca}\in M_{ca}\) and one resource identifier \(i\) describing the action and the target of the action respectively.
* A response \(r\in R_{s}\) must contain one control data element \(m_{cm}\in M_{cm}\) expressing the meaning of the response.  
On the basis of this formal description, the following subsections introduce two generic schemes for ensuring the authenticity, integrity and non-repudiation of REST messages.