Difference between revisions of "User Object"
(→Data Flows Between User Objects) |
|||
| Line 1: | Line 1: | ||
==Full Title or Meme== | ==Full Title or Meme== | ||
| − | The [[User Object]] is any part of a data store which can be accessed by a user identifier. The user object is a collection of [[identifier]]s, [[ | + | The [[User Object]] is any part of a data store which can be accessed by a user identifier. The user object is a collection of [[identifier]]s, [[Attribute]]s, relationships and inferences held by a digital entity. This is similar to the database Entity, Attribute Relationship (EAR) model. |
==Context== | ==Context== | ||
Revision as of 15:32, 3 August 2018
Contents
Full Title or Meme
The User Object is any part of a data store which can be accessed by a user identifier. The user object is a collection of identifiers, Attributes, relationships and inferences held by a digital entity. This is similar to the database Entity, Attribute Relationship (EAR) model.
Context
In order to track flow of User Information we would like to understand how, where and were that information flows.
The user object is assumed to describe a single Subject as maintained in a database controlled by a single Internet connected entity (aka Data Controller). The user object in the database can describe any sort of Subject, such as organizations as well as individuals. Most regulations apply specifically to data about individual nature persons maintained in a user object.
The working assumption here is that the various digital entities need access to User Private Information on a high-availability access device. It has been argued that digital entities not under the immediate control of the user should ever store User Private Information. For example Thomas Hardjono argues that various attributes of User Private Information should be stored wherever that data can be validated by the relying party. The problem with that is that user's have grown used to response web sites that can accommodate their every whim with very little delay. The only way that computer science has so far been able to accommodate the user's need for speed is caching of data close to the point where authorizations need to occur. This works well with claims that can be given short life-times. With data bases the User Object may live long after the need has expired. While it is possible to imagine a data base where each attribute has its own life time specified, such a system has not be deemed worthwhile at this time.
Problems
It is hard to visualize the ways that user private information is used and misused.
Solutions
One instantiation of the user object in a relying party is described in the Best Practices and Example for RP System. That example describes the user object as a collection of tables in a SQL data schema. Note that the User Object consists of User Private Information plus linkages and status information that are internal to the relying party. In this instantiation all attributes in the data base have a static tag indicating how the user interaction with that attribute is permitted.
Another instantiation of the user object might allow for attributes that are dynamically configured during a consent negotiation with the user. In this case one or more elements might be bundled into a claim received from another party, or data entered directly by the user, but with a set of stipulations on the use of that particular collection of data by the web site.
No matter how the User Object is realized, it is important the that user can understand what User Private Information is held by the relying part and what redress the user has to change that information if user desires. In particular the terms that stipulate how the web site will handled the User Private Information is communicated to the user by some sort of Consent Receipt which might be as simple as a set of prescribed terms of the site's choosing (aka a Privacy Statement), or as complex as the Kantara Receipt.
It is likely that databases controlled by entities will include other information that are covered by regulation. Although these data are not described in the work of the IDESG, they are still of concern to the users. The behavior patters of the user are an example of such information. Specifically the right to be forgotten applies to past user behaviors such as legal actions and user actions which are ruled by courts to be excluded from internet accessible collections, even if those behaviors are a matter of public record and still internet accessible.
Note that the User Agent is also a digital entity that has a User Object associated with it. This is mostly in the form of short lifetime packets of claims typically stored in cookies.
Data Flows Between User Objects
In other to understand the flows of User Private Information among the entities that have it and track it on user devices, the follow diagram shows these flows. The User Object (UO) on the left is the one held by the Web Site and the one on the right is held in the user device, typically as Cookies.
The dashed lines show the flows controlled by the user. The Solid lines are not controlled by the user, nor are completely out-of-band flows. The user objects to the right are typically held in cookies in the user agent, which are not typically known to the user. Note that third parties (Advertisers in the image) do not explicitly get User Private Information, rather they are given access to user cookie space by the other web sites in return for advertising prices they pay to those sites. They then use that access to create a user object of their own, both on their own web site as well as in the user cookie space. They can then use that data to track the user and target ads to the user based on past user behavior.
