User Object

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 without an overall view of where user data is maintained.
• It has been pointed out that calling this concept a User Object makes it obvious that objectification is the goal of internet web sites, but changing its name would not change the reality.

Solutions

One instantiation of the user object in a relying party is described in the Best Practice and Example Relying Party. 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 Party 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. Completely out-of-band flows should honor the User Intent in the ideal case, but have not been traditionally reported to the user. 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.

Controlling Data Flows

Information Sharing is the name used for one Data Controller (aka Web Site with a User Object) sharing data with another. That is where the GDPR focuses its attention. It completely ignores the problem that the Data Controller might not have had a good reason to have collected the data in the first place, or even force it to prove User Intent in acquiring that information. No relief is provided for the misuse of User Private Information with existing regulations. They focus on the sharing aspect completely. See the page "GDPR is a scam" for details on that.