While the permissions policy comes with important security/anti-fraud benefits (prevent arbitrary third-parties from registering sources without the publisher’s knowledge), it comes with the following limitations for API users:

Limitations

1. A permissions policy is lost in a chain of nested iframes (See developer issue)
2. A permissions policy is lost in redirects (See developer issue)
   For example, let's take an HTTPS deployed site, that embeds an ad iframe that looks like this:

<iframe src="https://page-that-redirects.glitch.me/" allow="attribution-reporting" frameborder="1"></iframe>

page-that-redirects redirects to final-destination. So while the API is allowed in page-that-redirects, it's not allowed in final-destination. Repro here in IFRAME 7: https://shimmer-well-juravenator.glitch.me/.

This can also happen in more subtle ways. e.g. redirecting from https://a.com to https://www.a.com.

Mitigations

• One way to mitigate 2. is to explicitly list the final destination of the redirect in the policy's src, but I don't know how realistic this is in practice.
• The explainer mentions Without a Permissions Policy, a top-level document and cooperating iframe could recreate this functionality. This is possible by using postMessage to send the source_event_id, attributionsrc origin, destination values to the top level document who can then wrap the iframe in an anchor tag (with some additional complexities behind handling clicks on the iframe) but IMU this doesn't solves 1. nor 2, does it?
• For 1., even if there was way for an iframe to delegate the permission to all its children, this would seem like a security issue.