A look at Identity as a Service (IDaaS) and Federated Identity Management (FIM) and acceptance amongst organizations, users, and general population. While FIM has shown acceptance amongst educational, commercial and government organizations, the general population acting has not seen the level of trust as the former. What are the barriers or enablers for acceptance that might allow, in the extreme example, the ability to logon to a bank with your Facebook credentials and transact business?
Many solutions, products, and protocols exist for establishing federated identity for enabling users to securely logon to Service Providers (SP) for various purposes, yet, there is still a chasm with regards to trust. That is whether consumers trust both Identity Providers (IdP) and SP to participate in a federation.
We take a look at research that examines commercial and public organizations and various implementation impediments and facilitators. Additionally, while Federation amongst universities, government, and, commercial partners is much more prevalent, we lack that level of acceptance for the general population. We take a look at government efforts, most notably in the European Community towards establishing a common credential provider and broker-based approach.
Finally, for future research, we ask a rhetorical questionwhen will I be able to use my Facebook Identity to logon to my bank?
Initially organizations started to use Single-Sign-On (SSO) to unify authentication systems together for better management and security. SSO was adopted across different internal applications and via APIs for external applications. With platforms spread across different devices bringing in together user authentication and authorization with increased security is a challenge which Federated identity tries to address [5].
In Federated identity an application uses an identity management system that stores user’s electronic identity to authenticate. It decouples authentication and authorization functions. It avoids a situation where every application has to maintain a set of credentials for every user [5].
Since 1995, EU member nations have been implementing various forms of electronic Identity Management (eIDM) based on the interoperability of eSignatures. The lack of an EU-wide legal framework governing such an implementation has resulted in difficulties in defining actor responsibilities and liabilities. Cross-border requirements amongst EU countries have created incremental challenges. This has unfortunately resulted in a degree of “subsidiarity” amongst the member nations: each member nation maintaining its autonomy and responsibility. [1] Both the U.S. and the U.K. governments have decided that citizens will authenticate to government resources using Federated Identity; however, neither government wishes to perform the role of IdP [1]. This defers to private industry the opportunity to offer identity management solutions to consumers while still not answering questions such as (1) who will oversee the solution design and implementation, and (2) who will control and monitor the governance of the solution. What limited functionality has been implemented on the consumer side in the UK has been received with a reasonable level of trust on the part of the consumer, with ease-of-use scoring the highest. Opportunities have been identified [1]: • 50% left the site once reaching the hub page, • 25% left the site once reaching the consent page, • 34% of users felt threatened, not reassured, by the privacy. The success of InCommon may be linked back to the Shibboleth model that was implemented, along with Trust in Privacy from the IdPs and alleviation of significant identity management functionality for SP [3]. This also was a step-up for many organizations in having better security than previous implementations. For example, JSTOR had been using IP address blocks to permit access from users cross Universities. The implementation of InCommon using Shibboleth allowed clarity in who is requiring access with some level of assurance that the actual user has been authenticated and permissioned for access by the supplying IdP amongst the trust.
What may be core to the success of InCommon is a captive community of practitioners that utilize the services offered within the Federation for their daily needs. It may also be attributed to a community well versed in the underlying technology, or at least comfortable with it in general. We still haven’t seen the ability to access your Bank Account through this federation.
Amongst the general population we have different motivations that may attribute to the slow uptake or resistance. In the UK, the Identity Assurance (IDA) program issued guidelines and mandates for implementation of an approach that has yet to take hold [1].
In a series of studies [1] various obstacles were cited ranging from poor User Interface Design, to Security and Trust concerns. Major concerns still exist over unauthorized release of privacy information, along with inability to understand associations of an IdP to a SP -one stating “PayPal have nothing to do with the National Health Service (NHS)” [1].
The lack of general Trust in the federation amongst the general public may be attributed to their naivety or lack of understanding of the overall Federation model. The same study suggests that this may be improved through better User Experience (UX) and also presents as part of that argument which examples of
This content is AI-processed based on open access ArXiv data.
