Proposal

Add a new field to the auctionConfig called perBuyerTrustedServerAuthenticationCode, so that

const myAuctionConfig = {
  //  ...
 'perBuyerTrustedServerAuthenticationCode': {
    'some-buyer':  {
      'authCode': <Base64String>  // with some appropriate length limit
  }
  // ...
};

The new field is passed in the trusted bidding signals request, either as part of the header or as a query parameter.

This could also be a separate special field in each buyer's perBuyerSignals. In general, it seems like it would be preferable to put all DSP data passed to SSPs in one object, so that the SSP is not required to parse buyer data in order to form and forward the data into the auctionConfig. We suggest the above approach only because it is more consistent with existing parts of the API.

Intended Use

In preparing the response to the SSP, the DSP can compute a Message Authentication Code (MAC) or digital signature of the request features that are also available in the trusted bidding signals request. Then the trusted bidding server can verify that the buyer initiated the request, either via a previously shared (symmetric) key for MACs; or via an already established public key passed in the Interest Group for digital signatures.

This allows the trusted server to establish that the request matches a recent DSP initiated auction on the publisher hostname from a browser with the same user agent within some limited time. This helps prevent adversaries from exfiltrating large and unnecessary amounts of sensitive advertiser data from the trusted server. Depending on usage of the trusted server, unauthenticated requests may additionally represent a potential threat to user privacy. For example, if the trusted bidding key is an advertiser user ID and an adversary can guess or otherwise acquire the request key, then potentially sensitive information about the users' interactions with advertiser sites could be exfiltrated from the trusted server.

In practice, some number of bits of the authCode can be used to encode a truncated timestamp and key version. The full timestamp can be used as input into the signature, and the trusted bidding server can verify that the request occurred within an appropriate amount of time, say 500ms.

Goal

The goal of this is to authenticate the trusted bidding server request. The trusted bidding server needs to return a substantial amount of potentially sensitive data to the client. It is desirable to limit the ability of adversaries to request data from the server in an exploratory (force browsing) fashion where there is no value to the DSPs, advertisers, or users.

Extensions

Ideally, we would have a nonce incorporated into the MAC, with some path for transmitting the plaintext nonce to the trusted server—this could be in the trusted bidding request as well. (The trusted server could then reject any duplicates.)

Instead, if integration with the Trust Token API is possible, then a trust token could be incorporated into the MAC and validated by the trusted server.

Privacy Considerations

Let us note that even with a long authentication code and incorporating trust tokens into the API, this proposal does not harm user privacy when the trusted server is faithful to the trust model (and indeed improves user privacy depending on how DSP's use the API); however, if the trusted server is not fully trusted, as perhaps is the case in the BYOS era, then opening additional communication channels between the ad response and the trusted bidding request may be concerning.

In the third-party trusted server era, we anticipate that the usage of this signal exclusively for request authentication would be enforceable, and without privacy concerns.

Related Issues/Concerns

• Ways to authenticate data coming from reporting events #214
• Securely Propagating Auction Signals #119
• Support for Negative Interest Group Targeting #319

Please note that suggestions in #119 and #214 are valuable, but address different threats, and require separate mitigations. (Although one could try to use similar strategies.)