## 3 Proposed Solution: Modelling Components of a Communication Protocol as Resources
### Functional Flows
#### 3.2.3 Phase 3--Performing MQTT Actions  
In this phase, the previously acquired RPT Token is used to access the resource, to publish and/or subscribe using the topic. The IoT Device Owner must configure his/her devices including the valid RPT obtained in phase 2 and must define which actions to perform. From this moment on, devices can publish or receive data to the configured topic without any further IoT Device Owner intervention.  
It is important to notice that phase 3 of the UMA specification \"is effectively the success path embedded within phase 2\" [4]. Full message flow is shown in Figure 4 and is described below.  
1. Initial Configuration: The IoT device must contain the information defined by the IoT Device Owner such as the Resource Server Broker location, topic name, actions to perform, etc. This information can be stored during the IoT device manufacturing process and can be modified later by the IoT Device Owner. In our proposal, it is mandatory that all devices contain: 1. [label=()] 2. MRF_id: Unique identifier of the device manufacturer. 3. Device_id: Unique identifier of the device. 4. SN: Unique Serial Number composed by a 8-bit Unicode Transformation Format (UTF-8) encoded alphanumeric string.
2. CONNECT: The IoT device, following the MQTT protocol, starts the flow, defined by the actions configured by its owner. The IoT device will send a CONNECT message to the Resource Server Broker. This message must include the RPT.
3. Check Permissions: Using the RPT in the request and the Protection API Token (PAT) associated to the service, the Resource Server Broker performs an OAuth Introspection [46] at request, including the list of scopes associated to the RPT.
4. Return permissions: The AS evaluates the policies. To do this, it has to take into account the RS identity (identified by the PAT), the requester identity (identified by the RPT), and the specific list of scopes included in the request. The AS will then create a list of permissions that will be returned to the Resource Server Broker.
5. CONNACK: The Resource Server Broker binds these permissions to the open session between the IoT device and itself. It will return a CONNACK message. If the RPT issued in the request has not been validated, the AS response (step 4) will be an empty list. In that case, the Resource Server Broker will answer with a code 5 in the header of the CONNACK message. This indicates that the IoT device that is not authorized and that it must start the RPT validation process. This process is explained in Section 3.2.4.
6 PUBLISH/SUBSCRIBE: The IoT device will perform the actions described by its configuration.
7 Check Permissions: As in step 3, the Resource Server Broker performs an OAuth Introspection request including the list of scopes associated to the publish/subscribe actions.
8 Return Permissions: As in step 4, the AS will then create a list of permissions after evaluating them.
9 Interaction: In this step, the IoT device can publish and subscribe to MQTT queues, and perform the required interaction with its sensors and actuators.
10 Response: The sensors and actuators will answer according to the actions performed.
11 DISCONNECT: Once all actions have been performed, the IoT device will close the MQTT session by sending a DISCONNECT message to the broker.