Extend EID Permissions

[Net-burst]

With the slow rollout of user ID modules in Prebid Server, there is now a need to have more granular permissions for user ID propagation. The current implementation only allows setting the permissions based on source, which is not enough for some use cases, as the entire specification was based on the pre-ORTB2.6 implementation of EIDs.

Reference for the current EID Permissions feature can be found here: https://docs.prebid.org/prebid-server/endpoints/openrtb2/pbs-endpoint-auction.html#eid-permissions

OpenRTB 2.6 standardized and extended the EID object and added 3 major new fields of interest:

• inserter
• matcher
• mm

The details can be found here: https://github.com/InteractiveAdvertisingBureau/openrtb2.x/blob/main/2.6.md#objecteid

The original EID Permissions issue can be found here: #1621

The proposal is to extend the feature by allowing the caller (or user ID module) to specify the permissions based on a combination of source, inserter, mm, and matcher instead of only source.

Example format:

{
  "ext": {
    "prebid": {
      "data": {
        "eidpermissions": [
          {"source": "sharedid.org", "bidders": ["*"]},  // * is the default
          {"source": "neustar.biz", "inserter": "userIdProvider.com", "bidders": ["bidderB"]},
          {"source": "id5-sync.com", "matcher": "id5-sync.com", "bidders": ["bidderA", "bidderC"]},
          {"source": "id5-sync.com", "inserter": "id-bridge.com", "matcher": "id5-sync.com", "bidders": ["bidderD"]}
        ]
      }
    }
  }
}

1. All the existing handling logic for EID permissions remains the same as it is right now.
2. 3 new permission criteria are added: inserter, matcher, and mm. They follow the same rules as the existing source criteria.
3. The incoming request can specify any combination of the 4 supported permission criteria.
4. ext.prebid.data.eidpermissions validation is changed from requiring source to be specified to requiring any of the criteria fields to be specified: source, inserter, matcher, or mm.
5. PBS-core should follow strict permission matching.
   1. If eidPermissions specify a combination of source, inserter, matcher, and/or mm but request.user.eids[*] etry only have source (or only inserter, or only matcher, or only mm) populated, then EID entry is considered a non-match and all bidders can receive it as it requires to be matched on all the specified fields.
   2. If eidPermissions specify only one of source, inserter, matcher, or mm, but request.user.eids[*] has a combination of source, inserter, matcher, and mm populated, then the EID entry should be considered a match if the criteria (source, inserter, matcher, or mm) matches EID entry and only be available to specified bidders.
   3. If several rules apply to the same EID entry, the more specific rule wins.
   4. If several rules with identical number of fields but different combinations of fields (inserter + source, source + matcher, etc.) match the same combination of EID + bidder, the bidder can receive the EID if at least one matching rule allows it.

As a new requirement, the same configuration should also be definable through the account config at auction.eidpermissions, with request taking priority over account.

[Net-burst]

Updated the issue to fix typos and also added a clause that a more specific EID permission should override broader EID permission.

[Net-burst]

Was released in PBS-Java v3.38 https://github.com/prebid/prebid-server-java/releases/tag/3.38.0