I've put together a list of some of the concerns that we had about limiting number of issuers per page. Maybe this will be helpful here.

It the examples below I'm trying to highlight how having a limited list of issuers per site (N) rewards tracking and monopolies. For simplicity I assumed that N=1 in those examples, in reality that number will be higher, but big-issuer.com can still dominate that list if it provides multiple popular services (big-issuer-search.com, big-issuer-video.com, big-issuer-email.com, big-issuer-social.com …).

• Limiting competition by rewarding popularity (1)

1. big-issuer.com is very popular
2. publisher.com sees that big % of the traffic comes from big-issuer.com, so it only accepts big-issuer.com tokens
3. small-issuer.com doesn't produce enough traffic for publisher.com, so it's excluded
4. users coming from small-issuer.com to publisher.com get CAPTCHAs, users from big-issuer.com don't

• Limiting competition by rewarding popularity (2)

1. big-issuer.com is very popular and its tokens are widely accepted
2. trust tokens successfully prevent bots including crawlers
3. big-issuer.com can issue tokens for its crawler and crawl the web, small-issuer.com can't crawl the web, or parts of it, because its tokens are not accepted

• Limiting competition by rewarding popularity (3)

1. big-issuer.com is very popular
2. publisher.com gets most of the traffic from big-issuer.com, so they want to use their tokens
3. big-issuer.com doesn't like publisher.com or doesn't want to share their bot-detection for free, so they say "no"
4. publisher.com users get CAPTCHAs, while other-publisher.com users don't (big-issuer.com likes, or gets paid by, other-publisher.com)

• Limiting competition by rewarding tracking

1. big-issuer.com gets a lot of traffic every day and tracks it across many of its services. Thanks to that, they are very good at spotting bots.
2. publisher.com doesn't want bot traffic, so they only accept tokens from big-issuer.com
3. small-issuer.com can't compete because it decided not to track its users or has limited tracking capabilities because e.g. they don't operate multiple services
4. users coming from small-issuer.com to publisher.com get CAPTCHAs, users from big-issuer.com don't

I actually had some ideas for how to check unlimited issuers, without compromising privacy, over at #23. So publisher.com could include big-issuer.com and lots of small-issuer.com's.

Summary: site provides a list of issuers and the user agent only reveals to the site how many of them it has trust tokens for but not which ones; or site provides a pure function from issuers to boolean indicating trustworthy or not, and user agent passes all available issuers to the pure function but only reveals to the site the boolean result of the pure function call (examples of enforceable pure functions: weighted sum and threshold, WebAssembly modules, Frozen Realms aka SES)

One idea for expanding the number of redemptions per page: could we allow for additional trust token redemptions so long as each redemption is isolated within a fenced frame (see https://github.com/WICG/fenced-frame)?

I'd imagine we might have to apply the same limit of redemptions within a fenced frame as the one that applies to top-level pages, but this approach could greatly open up the total number of redemptions allowed while limiting the ability to use as a fingerprint surface. Given many of the ads use cases, where advertisers and brands might have a different IVT vendor, I'd think this would greatly expand the utility of trust tokens and would reduce some of the competitive tensions between different issuers.

I'm sure there are a number of other factors I'm missing, I'd love to hear thoughts on this potential approach. What do you think?