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 modules, 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 2 major new fields of interest:

• inserter
• matcher

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. 2 new permission criteria are added: inserter and matcher. They follow the same rules as the existing source criteria.
3. The incoming request can specify any combination of the 3 supported permission criteria.
4. 3. 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.
5. PBS-core should follow strict permission matching.
   1. If eidPermissions specify a strict match of all 3 (or any 2) of source, inserter, and matcher, but request.user.eids[*] etry only have source (or only inserter, or only matcher) 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 a loose match for only one of source, inserter, or matcher, but request.user.eids[*] has all (or any 2) of source, inserter, and matcher populated, then the EID entry should only be available to specified bidders if the criteria (source, inserter, or matcher) matches EID entry.

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