Paapi module: extend for B&A

[patmmccann]

Chrome has an elaborate proposal here: https://github.com/privacysandbox/protected-auction-services-docs/blob/88dbcd98cfad0418412f4b57b12ed5d0e5cbd575/bidding_auction_services_multi_seller_auctions.md?plain=1#L361 . This issue is to discuss said proposal. cc @chatterjee-priyanka @jasarora-google

Linking privacysandbox/protected-auction-services-docs#164
WICG/turtledove#1338

First question: can the B+a cipher be a promise?

Relevant part reproduced:

Device-orchestrated component auctions with Prebid.js
The current Prebid modules for Protected Audience auction support can be extended to support the B&A device-orchestrated component auctions API.

The following section presents a hypothetical integration flow for Prebid.js with the B&A device orchestrated component auctions.

This concept envisions a possible set of changes to Prebid.js and seller modules to illustrate how Prebid.js seller modules can use B&A services for Protected Audience component auctions. These changes are an informal example and are not meant to be prescriptive.

Note: The Browser APIs are available for Prebid to integrate with browser to support device-orchestrated component auctions for B&A .

Flow
alt_text

Prebid.js calls seller adapter buildRequests() for contextual payload
[NEW] Seller Prebid adapter buildRequests() invokes navigator.getInterestGroupAdAuctionData() to fetch B&A ciphertext (encrypted request payload for B&A auctions)
[NEW] Browser returns a B&A ciphertext to buildRequests()
[NEW] buildRequests() includes the B&A ciphertext in the data field of ServerRequestObjects
Prebid.js module sends requests to Seller Ad Servers with the B&A ciphertext
[NEW] Seller ad server calls their B&A for component PA auction
[NEW] Seller's B&A returns an encrypted AuctionResult
[NEW] Seller ad server returns B&A AuctionResult and contextual bids to browser
Prebid.js calls interpretResponse() in the seller adapter with serverResponse.
[NEW] interpretResponse() returns contextual bids and component auctionConfig(s) with the B&A AuctionResult to Prebid.js
[1-10 for each seller adapter]

Prebid.js module provides component auctionConfig(s) to top-level seller JS
Top-level seller JScalls runAdAuction() to kick off top level scoreAd() with all component auctionConfig(s)
Top-level seller JS receives winner from top level auction
Changes in Prebid.js
Prebid.js would need to incorporate the following changes in the paapiForGpt module - While calling the seller ad server, include the adAuctionHeader in the request to prepare the browser to look for Ad-Auction-Result HTTP response headers.

Changes in Seller Prebid Module
If the fledgeForGpt module is enabled (PAAPI eligibility passed in ortb2Imp.ext.ae), invoke navigator.getInterestGroupAdAuctionData() to fetch the B&A payload ciphertext with the top level seller.
Parse the response from navigator.getInterestGroupAdAuctionData(). It contains requestID and request (the B&A payload ciphertext).
Save the requestId field for later use in interpretResponse().
Include the B&A payload ciphertext in the data field of ServerRequestObjects from buildRequests().
Construct and return component auctionConfig objects (per ad slot) in interpretResponse() using the AuctionResult ciphertexts from the server response and requestId field saved in 3.
Changes in Seller Ad Server
Note: These changes are not Prebid specific, but required for any seller's ad servers to support device-orchestrated component auctions with B&A services.

If a B&A ciphertext is received in the call from Prebid, seller's ad server sends a SelectAdRequest to SellerFrontEnd service as described in the previous section.

Device-orchestrated component auctions with Prebid.js with Browser API optimizations
Note: The following section presents a hypothetical integration flow for Prebid.js with the B&A device orchestrated component auctions with an additional proposed latency optimization - an update in the Browser API
getInterestGroupAdAuctionData to accept more than one seller origin and return a map of seller origin to B&A payload ciphertext.

Flow
alt_text

[NEW] Prebid.js calls navigator.getInterestGroupAdAuctionData() with all partner seller origins
[NEW] Browser returns B&A payload ciphertexts (one per seller origin) to Prebid.js
[NEW] Prebid.js calls seller adapter buildRequests() with B&A ciphertext for this seller
[NEW] buildRequests() includes B&A ciphertext in the data field of ServerRequestObjects
Prebid.js module sends requests to Seller Ad Servers with the B&A ciphertext
[NEW] Seller ad server calls their B&A for component PA auction
[NEW] Seller's B&A returns encrypted AuctionResult
[NEW] Seller ad server returns B&A AuctionResult and contextual bids to browser
Prebid.js calls interpretResponse() in the seller adapter with serverResponse.
[NEW] interpretResponse() returns contextual bids and component auctionConfig(s) with the B&A AuctionResult to Prebid.js
[3-10 for each seller adapter]

Prebid.js module provides component auctionConfig(s) to top level seller Js
Top level seller Js calls runAdAuction() to kick off top level scoreAd() with all component auctionConfig(s)
Top level seller Js receives winner from top level auction
Changes in Chrome
Currently, the navigator.getInterestGroupAdAuctionData() method accepts a single seller origin and returns a B&A ciphertext for this seller. Chrome will expose API changes which will enable fetching the B&A payload ciphertexts for multiple sellers at once. These API updates will be available in 2025.

Changes in Prebid.js
Prebid.js would need to accommodate the following changes in the paapiForGpt module -

If the fledgeForGpt module is enabled, invoke navigator.getInterestGroupAdAuctionData() to fetch the B&A payload ciphertexts with all partner seller origins and the top level seller.
Pass the corresponding seller’s B&A payload ciphertext when invoking the buildRequests() function in the seller module.
While calling the seller ad server, include the adAuctionHeader in the request to prepare the browser to look for Ad-Auction-Result HTTP response headers.
Changes in Seller Prebid Module
Parse the response from navigator.getInterestGroupAdAuctionData(). It contains requestID and request (the B&A payload ciphertext).
Save the requestId field for later use in interpretResponse().
Include the B&A payload ciphertext in the data field of ServerRequestObjects from buildRequests().
Construct and return component auctionConfig objects (per ad slot) in interpretResponse() using the AuctionResult ciphertexts from the server response and requestId field saved in 3.
Changes in Seller Ad Server
Note: These changes are not Prebid specific, but required for any seller's ad servers to support device-orchestrated component auctions with B&A services.

If a B&A ciphertext is received in the call from Prebid, seller's ad server sends a SelectAdRequest to SellerFrontEnd service as described in the previous section.

[patmmccann]

It seems the requirements are:
(1) make the bidder fetch interface allow for an option to include the [adAuctionHeader in the request]

(2) in the paapiForGpt module - While calling the seller ad server, include the adAuctionHeader in the request to prepare the browser to look for Ad-Auction-Result HTTP response headers.

Marking low priority until a project member (adapter maintainer) expresses desire for support

[rdgordon-index]

(1) make the bidder fetch interface allow for an option to include the [adAuctionHeader in the request]

This is also required for #10740

[chatterjee-priyanka]

Thanks for creating the issue and summarizing the flows. We are prioritizing the optimized Prebid-Chrome API that can take multiple seller origins.

Keeping @brusshamilton and @michaelkleber in loop and to confirm if the B&A ciphertext can be a promise.

[jdwieland8282]

A pull request against this issue from the chrome team would be most welcome.

[patmmccann]

Additional note: "mixed mode" b+a and on device might be prefered by most sellers over moving to B+A. in this case, a seller will typically submit two auction configs to TLS

[patmmccann]

it seems we need a B+A support module that calls navigator.getInterestGroupAdAuctionData() and gets the various blobs for each adapter to reference

MVP would be able to cache the results for the page view. Later versions may want to give bidders control of if they need to make a fresh request or pass arguments to the navigator api

[rdgordon-index]

This came up at WICG as well -- I'm trying to better understand the adapter workflow in the parallel and non-parallel IG auction scenarios -- because the 'availability' of the seller origin differs.

[patmmccann]

Some discussion today in wicg indicates since the single call will be supported in the future, calling navigator.getInterestGroupAdAuctionData() for all sellers in advance would seem to be better than in adapters. Momentum seems to be heading towards a b+a support module

[rdgordon-index]

for all sellers in advance

How do you envision that working?

[patmmccann]

@rdgordon-index @lcorrigall something needs to call navigator.getInterestGroupAdAuctionData()

It seems the options are:

prebid core
paapi module
b+a support module
bidder sidecar rtd module

the bidder module itself is too late and is not an option.

In option 2&3, prebid would loop through the sellers in the auction and gather the blob and make it avail on the bidder module request(s). Is this what you need? Option 1 and 4 do not seem desirable for obvious reasons.

[dgirardi]

@rdgordon-index are you able to help with the requirements? it's unclear to me how this works - what the SSP needs and what should be passed to the chrome API. Do we have a working example calling runAdAution directly?

[rdgordon-index]

the bidder module itself is too late and is not an option.

There are seller-specific configurations as part of the call to navigator.getInterestGroupAdAuctionData() -- it's more than just the seller origin -- perBuyerConfigs, for example...

are you able to help with the requirements

Sure -- @mkendall07 let's help define those.