Identity Modeling Introduction: Difference between revisions

From IDESG Wiki
Jump to navigation Jump to search
(→‎Introduction: Added link to glossary and defined identity ecosystem)
Line 1: Line 1:
==Introduction==
==Introduction==
Any successful [[https://wiki.idesg.org/wiki/index.php?title=Glossary 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.
Any successful [[https://wiki.idesg.org/wiki/index.php?title=Glossary 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 anonymous.


==The Context==
==The Context==

Revision as of 16:36, 29 August 2017

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 anonymous.

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

"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 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.

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.