This is a really difficult problem, and the solution we arrived at was a compromise. The tensions here were:

1. Forcing all publishers that want to sell ad slots to make server side changes (e.g. Feature Policy header, tag before script) is a huge undertaking. Millions of sites, including sites that are not actively maintained, would need to update to keep monetizing on their ad slots.
2. We want sites to have control over third party activity on their site

The compromise we ended with is a solution in which by default, sites don’t have to update if they trust their third party scripts (e.g. they have a business relation with them). However, publishers will be able to control (via Feature Policy) the behavior of these scripts if they so choose (by opting into stricter policies).

I think more detail would definitely need to be thought out in regard to Feature Policy implementation in regard to this feature and other ways to mitigate potential for abuse.

I understand the need here: we cannot assume that publishers would be capable of handling such attribution reporting themselves via their own set up of back-end services and many would want to delegate that responsibility either by setting Feature Policy to a trusted provider or by allowing an ad serving service to handle that process when that service sets up iFrames on-page.

It is easy to see how delegation here, both with intent by publishers (where they are intending settings to the allow of the iframe) and without intent by publishers (where they are delegating the setting of delegation on the iframe to a top-level script) could be abused through ignorance or bad practice. If we only allow restriction to occur on Feature Policy header, then--as you note--a significant undertaking would have to be made by publishers in order to restrict scripts.

There is an assumption here that most publishers would set their policy with intent (that is: select a set of trusted providers implicitly through their selection of ad server or set those to iframes/Feature Policy themselves with explicit intent). However, it seems likely to me that services seeking delegation would multiply and the majority of publishers who lack bandwidth to handle requests would simply make their pages increasingly permissive, continually increasing the potential for user data leakage. This would be less of an issue if not for the potential to align both publisher and advertiser identity on the inclusion of a user id in the conversion data, especially when that user id could be set by a third party running top level scripts on the publisher page.

Perhaps this is resolved in the considerations that could be made in https://github.com/csharrison/conversion-measurement-api#limits-on-the-number-of-conversion-pixels or perhaps not?

There is an overall secondary consideration here as well: if ad-tech.com controls and can set both the allow attribute and the setting of the user id through third-party scripts running on the top-level page, wouldn't ad-tech.com be able to create a single ID for users that would allow them to cross-site target that user based on conversion success on any publisher page which they run on?

Let me re-state your points to make sure I understand:

1. Publisher opt-in / opt-outs might not be super meaningful because publishers lack incentive to be restrictive.

This might be true, but policies like this seem better than publishers being incentivized to perform server-to-server calls to their ad tech companies (lack of transparency). Point taken though.

2. Permissive policies are non-ideal because an ad tech script running top level can "allow" themselves in an ad iframe and embed a user id in the click impression data, allowing the potential to align publisher and advertiser identity.

Yep, this is a danger of the API, which is why we tried to make it pretty difficult to align these identities (low entropy, noise, etc). It would be exceedingly difficult to prevent ad-tech from orchestrating this especially in light of (1), where we assume ad-tech and publishers are working together.

3. ad-tech.com can create a single ID for users across publishers, and use the conversion API to target users based on conversion signals on that ID.

If ad-tech.com can already create a single ID for users across publishers, then they can create a single ID across publishers and advertisers, and they wouldn't use the conversion API at all. This API addresses the use case where a single ID is unavailable or undesirable.

See #558 for our current position on where we landed with this compromise. I'm not sure we landed on the ideal mechanism, so I'm open to further explorations on concrete proposals in new issues. Closing this old issue for now though.