Identity Modeling Introduction

Introduction

Any successful Identity Ecosystem will provide users with an understanding about how they control access to their own User Private Information which is used by any Digital Entity on the internet to authorize access to resources that the user wants or needs. For our purposes, "identity ecosystem" means an inter-operable identity commonly used across identity systems, via the use of common standards used by identity providers and relying parties in order to create relationships that are understood, even if temporary or pseudonymous.

The Context

• This modelling exercise is limited to one user using a browser or similar user agent interacting with any one Digital Entity which contains User Private Information.
• In the IDESG and GDPR, the user has the right to know what data is held about them and to control the use of that data.

The Problem

Problem Summary

In order to control access to their personal information, users need a mental map connecting their personal information to the digital representation of their information held by a digital entity.

"When a user approaches a GUI, he or she does two things: thinking and doing. For a smooth interaction between man and machine, the computer's "mental" model (also the programmer's mental model) and the end user's mental model must align with each other in a kind of mind-meld. In the end, any work that users do on their side of the interface manipulates the objects in the code. If the program provides accurate real-time feedback about how user manipulations affect program state, it reduces user errors and surprises. A good GUI provides this service. Using an interactive program is like being a doctor trying to navigate a probe through a patient's bronchial tubes: just as you can't see the objects in program memory, you can't see the actual probe in the patient's body. You need some external representation of the program structure, or of the bronchial probe, to guide your interaction with a program." This is a direct quote from The DCI Architecture: A New Vision of Object-Oriented Programming.

Historical Solutions

Ever since SmallTalk at Xerox Parc, the Model–view–controller (MVC) design pattern has been used by UX designers to give user control of data held on computer systems. The basic assumption is that data held about the user should be modeled in such a way that the user would be able to effectively interact with the data store. On a personal computer this model still works wonderfully. Where it breaks down is data models that must be accessible by many systems on an increasing globalized internetwork of computers. When there is more and one type of system accessing the data, a model is required that handles requests from a wide variety of computer systems with disparate needs. For such a widely accessibly model, some domain of applicability will cover a range of uses, many of which are not attached to any GUI. The domain model is so complex that users cannot be expected to create a mental model of the entire data structure.

More recent identity models have been created around specific data structures held in computer systems with the MVC augmented with separate view-models for each user interaction page. While this allows the design of view models that the user should be able to understand, the separation into distinct view-models for each display does not provide the user with a consistent view of the data that is accessible to them for their information or control. The Model–view–viewmodel (MVVM) works well with event driven systems, but a more user-centric identity model is needed to enable users to build a single mental model of their data held in cyberspace.

A New Model

The new model proposed for IDESG is one that considers the data held by any Digital Entity from the user's perspective. In this sense it is like a consistent view-model, except that it is not bound to one data base schema, but to an abstract view that should allow a consistent user experience that will apply to any interaction that the user has with their User Private Information held by any Digital Entity on the internet.

This identity model can be considered to be an abstract view-model of User Private Information. Each designer needs to carefully create a real view-model for their own solution. The objective of this exercise is to provide a the overall framework that will be a paradigm that can be used to create the consistent internal user model of how their data is handled on the internet.

The User Trust Experience

One key assumption of the IDESG is that users want better security, privacy and usability in their online experience. While users will agree that these bed rock principles of the IDESG are very important, all real-world experience shows that user are most interested in reducing the hassle that is created in the performance of simple tasks on the internet. If security and privacy increase the difficult in their performance of simple tasks, then they will work around any barriers that good security and privacy raise for them. It is not helpful for the IDESG rules to raise barriers, those rules must work to lower barrier and provide nearly seamless user experience that sill provides the security and privacy that users deserve. After all the greatest hassle for users is created when their security or privacy are breached. While interoperability is seldom raised as a user expectation, if it is missing then the user will also complain about the hassle involved in moving amount the sites that they wish to experience.

The first point to understand in the creation of a good user experience is that users must have authentication sites that they can trust. Any site that authenticates users can impersonate the user as well. So the only area where IDESG can help the user is selecting an identifier provider (IdP) to do authentication and consent acquisition. If User recovery and redress is to be possible, the IdP must have multiple ways to contact and verify the user. There is little to be gained in trying to reduce the information given to an IdP except for those users that want to have alternate personas, also known as pseudonyms. Note that one very important pseudonym that users do expect is that provided to extremely sensitive information, like some confidential health tests. In those cases as Trusted Third Party is required, which is just another name for an IdP that provides access to user sensitive information.

Given all of the challenges of security and privacy what can the IDESG do to help create a good user experience on authentication to Relying Parties? Here the user's expectation of good experience should be conditioned to expect that a Relying Party(RP) will never ask for authentication information directly, but use a trusted IdP to perform the authentication and consent acquisition with the user's best interests at the core of the service they provide. These sites need to be trusted by the user based on years of favorable user experience with them. When the RP allows the user to select an IdP that is in everyday use by the user, then there is likely to be no separate authentication user experience at all when returning to the RP. That is the ideal user experience. The RP has the ability to request consent from the user for more information. Without some other user information the only RP redress available to the user is through the IdP authentication process.

References and Coordination

The Best Practices and Example for RP System provides an example data base schema to show one way that a Relying Party could implement a database schema to achieve the results desired.

The Identity Model Overview provides a description of the model for business decision makers.

The Identity Model provides a description of the model for designers and program architects.