# An Identity Model for Providing Inclusive Services and Applications
## 4 Proposed Model
### Basic Architecture  
As we pointed out earlier, the model we propose allows service providers to decide the interface they should serve to the users depending on their functional capabilities. To achieve this, we have considered IAACaaS (IoT Application-Scoped Access Control as a Service) model [46; 47] as a starting point. IAACaaS enables the complete delegation of authentication and authorization to enable an as a service access control mechanism for Internet of Things applications. The authorization mechanism provided by IAACaaS is based on OAuth 2.0 protocol and ABAC to enable the decision making based on the attributes of users and IoT devices. Attributes are defined in a centralized Identity Manager (IdM) as part of the identity profile of the actors (users or devices) registered in such IdM. On the other hand, services are also registered in the IdM in order to enable the delegated authentication and authorization. Thus, when actors consume the services, they log in using their IdM accounts and services can then delegate the access decisions to a Policy Decision Point (PDP) deployed together with the IdM. The PDP takes the decisions based on the actors' attributes and the policies previously defined by the service providers. In a first approach we have simplified the IAACaaS architecture for providing the users' profile to the services allowing them to decide which interface they should provide depending on the defined attributes. We also propose the extension of the IdM features to permit the definition of the identity attributes in the users' profile. Figure 1 shows the connections between the user, the service and the IdM. \begin{table}
\begin{tabular}{l l} \hline \hline
**Body’s Organ System** & **Attributes** \\ \hline Musculoskeletal system & Manipulation, Strength, Reach \\ Nervous system & \\ Respiratory system & \\ Cardiovascular system & \\ Hematogotic system & \\ Digestive system & \\ Genitourinary system & \\ Skin and annex & \\ Neoplasms & \\ \hline Visual system & Vision, Color Perception \\ \hline Ear, throat and related & Hearing, Manipulation, Strength, Reach \\ \hline Speech/talk/voice & Vocal capability, Cognition \\ \hline Intellectual disability & Cognition \\ \hline Mental illness & Cognition \\ \hline \hline \end{tabular}
\end{table} 
Table 4: Parallelism between attributes and body’s organ systems. The service has to be registered in the IdM and to implement OAuth 2.0 protocol to support delegated authentication. As the model is thought to be used in web applications, services use Authorization Code grant type (OAuth 2.0 grant types: [[https://oauth.net/2/grant-types](https://oauth.net/2/grant-types)]([https://oauth.net/2/grant-types](https://oauth.net/2/grant-types))), designed for web clients. Developers have to implement adapted interfaces and configure the application business logic to serve them depending on the users' attributes received from the IdM. The IdM acting as OAuth 2.0 server has to support the definition of the functional attributes proposed above and to include their values in the user profile returned to the service when validating an OAuth 2.0 access token. Figure 2 shows the interaction between these entities in a basic flow:  
1. The model assumes users have been previously registered in the IdM and that their identity attributes have been configured there. In case the IdM interfaces are not adapted to the functional capabilities of an specific user, the assistance of a third actor could be necessary the first time. Once users have been registered and their functional attributes have been defined, their profile should be modified only if any of the functional capabilities changes. 2. When users access the service, they have to login using their previously registered account in the IdM. For doing this, the service redirects the authentication requests to the IdM login page using OAuth 2.0 protocol. Both the service and the IdM login pages must be as simple as possible and must provide accessible interfaces to facilitate the authentication process to every user. 3.