Support For Ads.Cert 2.0

[SyntaxNode]

Summary

The IAB Security Foundations Working Group has published a new Ads.Cert 2.0 standard, which is currently in the public comment period. This new standard has the same general concept as the original Ads.Cert feature in that it intends to provide a cryptographically secure means of authenticating bid requests between servers, but is a complete departure in terms of approach and implementation. CTV is identified as a specific focus area.

Please review the Ads.Cert 2.0 standard on the IAB Tech Lab ads.cert website. I recommend you begin with the ads.cert Primer followed by the Calls Sign Protocol and then the Authenticated Connections Protocol.

Proposal

Support the IAB Tech Lab's security efforts by integrating Ads.Cert 2.0 into Prebid Server. This functionality will provide hosts, researchers, and other interested parties a quick way to participate in the proof of concept.

This is an experimental feature which will be disabled by default. The Ads.Cert 2.0 standard is not yet finalized and the official IAB ads.cert open source project has only implemented MVP level features, most notably excluding persistent DNS discovery for large PBS deployments and robust security for the signing key. You are recommended to take steps to reasonably secure the signing key, but all hosts involved at this time will be asked to generate new keys when Ads.Cert 2.0 is ready for prime time and improved key ring support is implemented.

Implementation

PBS-Go and PBS-Java will take different paths on this implementation.

PBS-Go will be able to offer both remote gRPC and in-process signatory options, the later is only possible since the IAB ads.cert open source project is natively written in Go.

PBS-Java will be offer just remote gRPC signatory and will need to contribute a Java implementation of the gRPC endpoints.

Signatory Service

If a host chooses to participate in the proof of concept testing, they will need to configure either a remote or in-process signatory service. PBS will fail to start if the experiment is enabled and has either no configured signatory, more than one configured signatory, or a configuration validation error.

The latency of singing a request is expected to be very small since the bidder's call sign will already be cached (or skipped if it's not cached) and the communication overhead for gRPC can be very small through the use of the side car container pattern.

In-Process (PBS-Go Only)

This is the simplest approach which where PBS does all processing without the requirement of a remote service.

experiment:
  adscert:
    enabled: true
    in-process:
     origin: "origin url"
     key: "base64 encoded signing key"
     domain_check_interval_seconds: 30
     domain_renewal_interval_seconds: 30

Remote gRPC

This approach uses gRPC to send the entire body of the bid request to a remote service which returns the signatory information.

experiment:
  adscert:
    enabled: true
    remote:
     url: "remote service url"
     timeout_seconds: 30

Signing

Prebid Server will sign outgoing requests if the host has explicitly enabled the experimental feature and if either the request opts-in by setting request.ext.prebid.experiment.adscert.enabled to true or the account opts-in by setting experiment.adscert.enabled to true. The IAB desires for bidders to begin receiving signed authenticated requests once they have published their call sign (aka - public dns key). If the bidder has not yet published their call sign, they will receive an unsigned header announcing support to the bidder. We hope the unsigned header will encourage bidders to add support once they see the signals are available from their upstream partners.

In case a bidding server cannot handle unexpected headers, Prebid Server can be configured to exclude specific bidders. By default, all bidders will be sent a signed or unsigned authentication header if the overall Ads.Cert 2.0 experimental feature is enabled by the host and configured for the request.

experiment:
  adscert:
    signing:
      enabled: true
      log_rate: 0.01

Performance will be captured by the following metrics:
experiment_adscert_sign_count
experiment_adscert_sign_success
experiment_adscert_sign_error with status label values generate_nonce, invocation_counterparty_lookup, and emboss_message.
experiment_adscert_sign_duration

It is undesirable to use per-adapter metrics due to high cardinality. Instead, a log sampling approach is used to report on the bidder and the signing process result.

Possible Log Entries

coming soon

Verification

Prebid Server will attempt to verify incoming bid requests if the host has explicitly enabled the feature and a signed X-Ads-Cert-Auth header is present in the request. At this time, Prebid Server will only report on the verification result and will not include an option to reject the request.

experiment:
  ads_cert:
    verification:
      enabled: true
      log_rate: 0.01

Performance will be captured by the following generalized metrics:
experiment_adscert_verify_count
experiment_adscert_verify_success
experiment_adscert_verify_error with status label values sig_decode, host_mismatch, counterparty_lookup, missing_shared_secret, sig_invalid.
experiment_adscert_verify_duration

Unbounded cardinality of the incoming signature prevents the use of metrics for capturing the origin of the request. Instead, this proposal includes a log sampling approach in line with other PBS log options to report on the origin and validation result of requests received.

Possible Log Entries

coming soon

Answered Questions

• Do we really need a exclude_bidders block list? If a bidder has configured their DNS to support ads.cert 2.0 isn't it logical to assume they will support the header signature? Yes, because we want to send an unsigned header to all bidders.
• Is this a good candidate to be implemented as a PBS Module? No, because existing Modules hooks in PBS-Java and planned hooks in PBS-Go do not support adding HTTP headers to outgoing bid requests.

Open Questions

• Should we include the option to block failed verified requests at this time?
• How should we define the configuration to exclude a bidder from Ads.Cert 2.0? We can either use a block list in the Ads.Cert config (ex: experiment.adscert .signing.exclude_bidders) or a config on the bidder itself (ex: adapters.BIDDER.experiment.adscert.signing.enabled). Which approach do we prefer?

[SyntaxNode]

We discussed this proposal in a special committee meeting on November 16, 2021. We decided:

• This is not a good candidate for a PBS Module because the current hook interfaces do not allow setting HTTP headers in the outgoing bid request. This may an interesting hook option to consider in the future, but for now Ads.Cert 2.0 functionality will be part of PBS Core.
• We want to send the authorization header to all outgoing bidders and have an option to disable it per-bidder in case a bidder does not gracefully handle unexpected headers. If the bidder does not have their call sign registered via DNS the authorization header cannot have a signature, but will have enough information to inform the bidder that the party sending them the request supports authenticated connections if they choose to implement it in the future.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[SyntaxNode]

This is implemented in PBS-Go. We're going to leave it as "experimental" pending real world usage (let us know if you're using it) and a change for the IAB library which will send a discovery Ads.Cert message to bidders which do not yet have established an Ads.Cert Call Sign to signal upstream support.