# An Identity Model for Providing Inclusive Services and Applications
## 5 Validation and Results
### Discussion  
The proposed model is designed by taking two main factors into account: the usual practices in web development with regard to web accessibility and the limitations of existing adaptive UI model-based systems. Even though the approaches analyzed in the field of MBUID are automated  
Figure 8: Interface 3. Voice User Interface suggestion.  
Figure 9: Log In Interface (**left**) & Interface 2 (**right**).  
and capable of generating UI at runtime, most of them require redeployments to add new rules, and just [40] clearly presents a user model and a role-based solution. In addition, only two of them [39; 42] are proposed as an inclusive solution. On the other hand, most common accessibility approaches for designing web content are mainly based on evaluation methods, which results in social exclusion increase in most cases.  
Our approach goes beyond the [40] role-based solution, taking into account functional attributes for designing inclusive interfaces and delegating the user model management to a centralized identity manager, thus allowing users to define their profiles once and using them in several services. Moreover, our proposal stands in contrast to the prior work in web accessibility development, on the basis of a proactive solution that enables a completely flexible scenario.  
Analyzing the use case we have developed we can see how the detected gaps in the related work are covered. Web interfaces have been individually designed taking into account the conditions exposed in Table 6. In this example the three designed interfaces take into account vision, cognition and manipulation conditions of users. However, in real services other interfaces can be progressively included to cover other type of conditions. In contrast with the automated generated UIs solutions found in the existing related works, the customized design ensures the same contents are differently provided to users taking into account the way they are going to consume them.  
On the other hand, the users profiles where the functional attributes are defined (as stated in Table 7), are created in a centralized Identity Manager. This enables the use of the profiles to every service that implements OAuth 2.0 protocol to delegate authentication to an identity server. Therefore, users have to define their profile just one time and can take advantage of it in every service they use. The use of a standard like OAuth 2.0 permits the integration with well-known identity services such as the ones provided by the social networks Facebook or Twitter.  
We have implemented this use case to show how interfaces are provided to users depending on their functional attributes, previously defined in their IdM profile. However, in more complex use cases where users need to get access to protected resources served by a backend (typically RESTful servers) the integration with the advanced IAM architecture presented above can be achieved. In such cases, the services take into account the functional attributes of users to decide which interfaces provide to them and other authorization parameters (permissions, roles and attributes) to decide if users have the required grants to access the protected resources.