I think that's the right direction but it seems incomplete: The new indirect-thingamabob can still be retargeted to a different site. (Ex: I sign up to AcmeWidgetForum which falsely claims it needs to confirm I'm a real person, and AcmeWidgetForum secretly sends the data onwards to verify an unrelated spam-account on Slashdot.)

[Edit: This has a flaw, but I already typed it out and I think it makes an incremental advancement.] How about:

1. User earns Token (no change from before)

2. User visits the Site and begins the "offer proof" process, the Site generates and records two random numbers/UUIDs for the process. The first is the previously-discussed Confirmation Code, which is used for idempotency and is not shared with the User. The second is a Site Handshake code which the user must copy down.

3. User goes to Attestor site and plugs in two pieces of information, the Token and the Site Handshake code. This returns a Burning code (valid for X hours) which the user carries back to the Site.

4. User passes the Burn Trigger to the Site, and it calls the previously-discussed API with both the Confirmation Code and the Site Handshake. If the Site Handshake does not match what's on file for that Burn Trigger, the attempt immediately fails with a security error.

____

No, wait, that doesn't really work. Although it protects against EvilForum later leveraging the data into a spam account on Slashdot, it fails when EvilForum has pre-emptively started a spam account on Slashdot and is reusing Slashdot's chosen Site Handshake as its own.