INFORMATION TRUST EXCHANGE WORKING PAPERS

An overview:

Mapping ITEGA relationships

https://docs.google.com/document/d/1bcR-uGO8NuUG1afOPckJXk2bcXGhytvZgQ7K-coKmXk/edit

(Initial author: Bill Densmore March 2, 2016,

insight from Rick Lerner,

rewriting, additions, analysis from Don Marti)

This document outlines relationships among key participants in an ITEGA ecosystem -- users, publishers, advertiser and the network services.

1. NARRATIVE

The core approach:   Publishers create an Audience Profile Book (APB) of anonymous attributes of their users, which is shared with an ITE sharing infrastructure, not unlike a cloud service such as DropBox, or Firefox Sync.  The ITE can then work with member ad networks and agencies to provide access to cohorts of like-interest users across parts or all of the ITE -- sorted by interests or geography.

Adverts get passed through to users via the ITE, so the advertiser/agency doesn't know individual users, but is assured of delivery to real people who are contained within one or more interest cohorts.  Logged reports of ad views come from the ITE as a trusted third party; these two aspects should reduce most fraud and make higher CPMs more defensible.  Also, since the process of collecting and collating user attributes into APB cohorts happens at the network level, it eliminates the need for third-party cookies on user machines -- eliminating privacy compromises and sluggish end-user browser behavior.  The publisher is responsible for seeing that ads contracted for delivery to a particular cohort (of which the publisher’s APB has a piece) actually are viewed by the publisher’s users within that cohort. Thus only the publisher has to “know” the digital address of a unique user.

The ITE knows individual users by a unique ID provided by the user's home-base publisher (this is necessary to be able to bill ads (and, futurely content views or subscriptions), but does not have any way of mapping that unique ID to a real person at the home-base publisher level. Again, only the publisher can do that.

The architecture is designed so that user "persona" data is managed by individual publishers, or a collaborating group of publishers (such as Pangaea)  in a first-party relationship with their users/subscribers, but that data can be shared on a session basis -- with a user ID that persists for at least a week or longer with advertisers and agencies able to use it as part of real-time-bidding (RTB) processes. The user data would be stored temporarily at a ITE Data Aggregator (potentially Mozilla in alpha) or  ITE-contracted data-service provider (DSP) to whom all advertisers/agencies/networks/exchanges would make calls for the data as they are engaged in RTB. In this way the network would not be relying on the reliability of thousands of publisher's servers for real-time user-data services; it would be dependent on one, or perhaps a few, providers of user identity data.

So this should allow publishers to repudiate networks that set third-party cookies on their user's machines and offer this higher-quality alternative.  This will also allow users to implement privacy-protection technologies on the browser or device, without interfering with the operation of high-quality advertising gatewayed through first parties -- such as this describes.

Key  points:

1. Trustworthy, fraud-free, non-PII, current knowledge of user interests
2. Plays nicely with reputable privacy-protection services (DNT, etc.)
3. Creates new opportunity for publishers to add value to user relationship as privacy helper ("InfoValet")
4. Advertisers can have a single view of aggregated user cohorts (without PII), through that home-base publisher. Audiences are addressable but individuals are not.
5. This means everyone has a common contact source of user data -- Audience Profile Books (APBs) from which to figure their bids for ad space
6. The system does not preclude the continuation of the current cookie-matching world but over time it should be marginalized for its inefficiency and bad user experience.
7. Only the APBs are updated and combined by the Data Aggregator in real time, no individual user data PII or otherwise, is included.  ("Big Brother is blind.")
8. Distributing the user data-management functions reduces the potential for identity theft on a massive, systematic scale and allows for the application of local laws and customs regarding privacy.

Here are some steps in the system operation as planned:

B. ESTABLISHING PERSONA

1. User chooses a “Home Base”  to manage their personal

1. A publisher
2. An identity service provider (such as RespectNetwork)
3. Their browser (such as Firefox)
4. An affinity group or tech company

2. Home Base must be a member of the ITE
3. Home Base gathers minimal info – email address – and creates profile that can be gradually filled out with user permission
4. Home Base assigns a permanent ID to user in ITE standard format
   (example FooBar123@ite.HomeBase.com)
5. ID is never shared to anyone other than the ITE network services
6. For federation authentication purposes (billing, service class) but not for advertising, ITE may create an encrypted session ID for a user (a “token ID”) that can be shared with other publishers and which times out.

C.  VISITING THIRD-PARTY SERVICES -- NON-ADVERTISING

7. When user visits other ITE member services, those services check with ITE to see if the user is an ITE participant. A session ID is either created or retrieved.
8. This happens by looking for a non-cookie ITE unique identifier on the user’s browser
9. If so, they get the anonymous ID either at the third-party site or by running a JavaScript function to get the ID stored on the browser.  The third-party site can create additional “attributes” (interests, preferences) and contribute them to the ITE linked to the anonymous ID. This propagates the new attribute(s) to the user’s HomeBase core profile. Sites might attempt to set ITE attributes for a non-ITE user, or change attributes that have been locked by the user or their Home Base, but these should fail harmlessly.
10. Complete temporary profile is at the ITE, but the core (master) profile is at the Home Base publisher (or identity-service provider).
11. User can modify user-generated or controlled attributes. User can choose to share attributes with sites (like “share my location”, under user control, not like a cookie, behind the scenes)
12. Changes propagate (like DropBox-type cloud service) to the publisher’s chosen ITE cloud service (possibly using Firefox Sync in alpha)
13. A few attributes are “locked” by contributor and can only be made private or deleted by user; cannot be changed  (i.e., subscription terms or skill levels earned on special-interest sites)
    
    D.  ADVERTISING EXCHANGE

For a more detailed description of how ITE advertising exchange services will work, see the WORKING document:

How the Audience Profile Book can work

 -- a method for assembling web-service user demographics and interests in anonymous cohorts