Define OpenRTB location for hashed identifiers

[bretg]

LiveIntent is preparing to build a Prebid Server module to support use cases beyond what a Prebid.js can support. One of the key inputs the module requires is a hashed identifier. It's going to need to receive this data on the request from the client, whether that client is Prebid SDK, Prebid.js, or an SSAI server.

I don't believe the community has defined where to transmit this kind of data, so that's what this issue tracks.

This is the kind of data that would certainly need to get anonymized in the "transmitUfpd" activity control scenario, so the obvious place to put it would be in user.ext.data. However, all bid adapters receive data placed there, which is not necessary and seems like it ought to be avoided, particularly since this ID could be helpful for any entity attempting to fingerprint.

Since only user ID modules really need this, I would suggest that wherever we decide to put it, no bid or analytics adapter ever receives it - just user ID modules, and then only when the enrichUfpd activity is allowed.

Given these factors, how about we put this data in user.ext.hashes. e.g.

user: {
  ext: {
    hashes: {
      ph: "sxkjmnk43wo",
      email: "9w4f9wjer9js"
    }
  }
}

Then Prebid Server would:

• check the enrichUfpd activity and remove user.ext.hashes before calling modules.
• always remove user.ext.hashes before calling bid adapters
• always remove user.ext.hashes before calling analytics adapters
• still display user.ext.hashes in the 'resolvedrequest' debug output

[bretg]

From a slack discussion, the preference seems to be to put this hashed info into the eids array. Here's a straw:

user.eids: [{
        source: 'publisher.com',
        uids: [{
            id: 'some-value',
            atype: 3,
            ext: {
              stype: "preid"    // making up a new stype here
            }
        }]
    }]

In Prebid.js, this would be set as:

pbjs.mergeConfig({
     userSync: {
         userIds: [{
             name: "pubProvidedId",
             bidders: [],                                   // can this array be empty so no bidders get it?
             params: {
                 eids: [{
                   source: 'publisher.com',
                   uids: [{
                      id: 'some-value',
                      atype: 3,
                     ext: {
                       stype: "preid"
                     }
                   }]
                 }]
             }
         }]
     }
 });

For Prebid Server, the configuration could be:

{
  "ext": {
    "prebid": {
      "data": {
        "eidpermissions": [
          {"source": "publisher.com", "bidders": []} // don't think we currently support an empty array to indicate no bidder
        ]
      }
    }
  }
}

Open items:

• are we free to make up new stype values?
• can we enhance PBJS and PBS permissioning schemes to support the 'no bidder' scenario?

[FlorentDancy]

Thank you Bret for starting this conversation.

I would just recommend having a field (probably under eids.uids.ext) which indicates the type of hash used.
At Criteo, we've pushed publishers to use "eids.uids.ext.stype" IN ("hemsha256", "hemmd5", "hemsha256md5", "cleartextemail"), so that it's explicit that the ID passed is a HEM, and in which format.

[deepthivenkat]

Hello Bret,

We discussed this in Identity PMC and decided that the best way to go about passing hashed emails / phone numbers / device ids is through user syncing as defined here: https://docs.prebid.org/prebid-server/endpoints/pbs-endpoint-cookieSync.html and https://docs.prebid.org/prebid-server/developers/pbs-cookie-sync.html#bidder-instructions-for-building-a-sync-endpoint

If we use a redirect user sync, we will create an endpoint that can take separate parameters to the url to take in different hashes of emails and phone numbers and device ids along with the capability to take in gdpr, gdpr_consent, us_privacy flags

[bretg]

Not clear to me that user syncing is the right solution.

1. There's never a sync done for mobile apps which is a main use case for a PBS module
2. Space in the Prebid Server user match cookie is very limited.
3. The liveintent module will not be a bidder and therefore won't have a bidder YAML file

[bretg]

Discussed in the identity committee. Usersync doesn't work for mobile app, and it won't work for LiveIntent because they're not a bidder.

So back to the EID approach, but with an additional requirement: the publisher needs to be able to define which specific modules have access to this data. i.e. it would be best to not trust non-ID modules with potential PII.

Extend EIDs new stype 'hashid'

Note that Criteo wants publishers to provide details about what kind of ID and what hash algorithm was used. This seems more revealing than necessary and much harder for publishers, so should be debated. For now, this example shows a simpler approach.

pbjs.mergeConfig({
     userSync: {
         userIds: [{
             name: "pubProvidedId",
             bidders: [],                                   // can this array be empty so no bidders get it?
             params: {
                 eids: [{
                   source: 'publisher.com',
                   uids: [{
                      id: 'some-value',
                      atype: 3,
                     ext: {
                       stype: "hashid"
                     }
                   }]
                 }]
             }
         }]
     }
 });

module permissions

Second, there's a call to support filtering stype='hashid' from other server-side modules. This is a new feature:

{
  "ext": {
    "prebid": {
      "data": {
        "eidpermissions": [{
             "source": "publisher.com",
             "bidders": [],   // new feature: empty array indicates no bidders
             "modules": ["liveintent"]  // new feature: prevent other modules from seeing EIDs from this source
        }]
      }
    }
  }
}

account-level default eidpermissions

Third, there's an implied request here to make the eidpermissions feature more foolproof. It's currently only accepted on the incoming request (or stored request), but it would be much easier to manage if supported as an account-level configuration.

The proposal is to implement this with the 'profile' feature being discussed in #3726 . i.e. implement profiles, support a list of "default profiles", and let the publisher come up with whatever default ORTB they'd like.