## 3 Proposed Solution: Modelling Components of a Communication Protocol as Resources
### Functional Flows
#### 3.2.4 RPT Validation Process  
Due to the heterogeneity of IoT devices, the tokens used for message transmission can be generated and stored using different methods. The simplest scenario implies that the generation and storage of the token in the device is performed during its manufacturing process, but it might not always be the  
Figure 4: Sequence diagram for accessing the protected Message Queue Telemetry Transport (MQTT) flow. case. In this section, we propose a mechanism for RPT generation and validation which allows token management after the devices are deployed. The process will start with an IoT device which is not provided with a validated RPT, and will also be performed if the RPT is rejected when trying to stablish an authorized connection (see step 5 in Section 3.2.3). In Figure 5 we show the requests and responses used during this process, and they are further explained below. 1. Start Process: Following the methodology defined in OAuth 2.0, the IoT Device Owner is the user that starts the process by connecting himself to the client which will perform requests in its name. 2. CONNECT (from the RP Client): The client performs an MQTT connection with the Resource Server Broker using the IoT Device Owner credentials. 3. CONNACK (to the RP Client): The Resource Server Broker checks the user credentials from the client and, if they are correct, answers with a CONNACK message using the 0 code in its header. 4. SUBSCRIBE (from the RP Client): Once the client completes the connection with the Resource Server Broker, he/she subscribes him/herself to the specific topic of its manufacturer (\"MRF_id/#\"). The credentials used in the connection step will only allow this subscription, depending on the manufacturer identifier owned by the user. 5. CONNECT (from the IoT device): After the IoT device has performed the first connection, or receives a CONNACK (with Code 5, meaning not being authorized), the device starts a connection process using an empty string as an RPT. 6. Start RPT registration: When the Resource Server Broker receives a connection request with an empty RPT, it stores the client identifier and allows it to subscribe and publish in certain specific topics. 7. CONNACK (to the IoT device): The Resource Server Broker responds to the connection with a CONNACK and Code 0 to the request issued in step 6. 8. SUBSCRIBE (from the IoT device): The IoT device subscribes itself to the topic composed by the manufacturer identifier and its own identifier (\"MRF_id/RPT/Device_id\"), and waits for the RPT validation process to finish. 9. PUBLISH (IoT device): By publishing its own identifier in the \"MRF_id/RPT\" topic, the IoT device advertises that it wants to start the new RPT validation process. 10. Generate \"nonce\": The authorization module of the Resource Server Broker, after receiving a message in the topic \"MRF_id/RPT\", generates a random number to be used only once in each RPT generation (a \"nonce\") and stores it temporally. This number is included in the payload of the MQTT message sent in the next step. 11. MQTT Message (to the RP Client): The request for the RPT validation process beginning is sent to the RP client through the previous subscription to the \"MRF_id/#\" topic (step 4). 12. Generate RPT (in the RP Client): Using the Device_id, the RP Client looks for the corresponding Serial Number (SN) in its database. Using the SN and the \"nonce\" received in the previous step, the client generates a RPT by applying a hash function. The specific function to use should be previously configured by the IoT Device Owner depending on the device restrictions and its own preferences. 13. Manage Requests: RPTs generated in step 12 are stored in the RP Client until they are confirmed by the IoT Device Owner. The RPT verification process is the one specified in UMA. The RPT validation can be performed both individually or in batch mode. Also, the IoT Device Owner can previously define in the AS a set of policies to be applied to the RPTs, which would ease the configuration in this step. 14.