## 2 Communication Protocols and Access Control Systems in IoT Environments
### User-Managed Access (UMA)  
Although OAuth 2.0 is a widely used protocol in many different services, there are scenarios which cannot be covered by the standard. In fact, the main scenario in OAuth implies an application owner giving access permissions to another application he/she owns. However, there are scenarios where this is not the case, for instance, a user might want to give access permissions to a third party which could use the resources he/she owns (defining resource as any personal data, content, services, etc.), which is not directly possible using OAuth. UMA on the other hand, has been designed specifically to provide a solution for these scenarios. It is being developed by a working group of the Kantara Initiative [43], a non-profit organization composed by different companies and communities. The UMA specification draft has been contributed by the Internet Engineering Task Force (IETF) [44].  
In the specification, the UMA schema is defined as composed of a series of entities:  
* Resource Owner (RO): The entity in charge of granting or denying access to a protected resource. Usually this role is represented by an end-user.
* Requesting Party (RP): The entity which requests access to the protected resource. As is the case of the RO, is usually represented by an end-user.
* Client: An application used by RPs to make requests in their name to access protected resources owned by any RO.
* Resource Set (RS): A group composed of one or more resources managed together by a Resource Server [45], that is, using the same access policies (which are defined in the Authorization Server) for each resource in the set.
* Resource Server: The entity which implements the management of RS protection by their ROs.
* Authorization Server (AS): The entity in charge of issuing authorization and permission tokens to clients, and which enforces the RS protection at the resource servers. It is composed of two OAuth-protected Application Programming Interfaces (APIs) (Authorization API, and Protection API) and an RS management interface used by ROs.  
The whole UMA protection and resource access is based on three tokens, which can be seen in Table 1.  
These entities from the UMA schema and its main phases are shown in Figure 2.  
The three main phases of UMA are:  
1. Resource Protection: The RO of an RS registers it into the AS though the Protection API (using the Protection API Token, PAT). Additionally, the RO configures the access policies for the RS scopes in the RS management interface.  
\begin{table}
\begin{tabular}{c c c c} \hline \hline
**Token** & **Used by** & **To Access** & **Goal/s** \\ \hline Authorization API Token (AAT) & RP Client & AS Authorization API & Request an RPT \\ \hline Protection API Token (PAT) & Resource Server & AS Protection API & \
\begin{tabular}{c} Register resources or \\ check permissions \\ \end{tabular} \\ \hline Requesting Party Token (RPT) & RP Client &
\begin{tabular}{c} A resource in a \\ Resource Server \\ \end{tabular} & Access a \\ \hline \hline \end{tabular}
\end{table}
Table 1: Tokens used in User-Managed Access (UMA). API: Application Programming Interface; AS: Authorization Server; RP: Requesting Party.  
Authorization Request: The RP, through a client, requests access to a resource through the Resource Server. It must obtain the authorization data and a Requesting Party Token (RPT) through the Authorization API of the AS (using the Authorization API Token, AAT).
3. Resource Access: Using the RPT and the authorization data associated with it, the RP is able to access the resource through its client.