What If: The Site chooses and exposes a public key (a simple one, like SSH, unrelated to TLS/DNS/certs) which the User carries over to create the Burn Trigger.
The Attestor generates a random secret associated with each Burn Trigger, and encrypt it with the supplied public key to create a non-secret Challenge. (Which is carried back by the User or else can be looked up by another API call.)
To burn/verify the Token, the Site would need to use its private key to reverse the process, turning the Challenge back into the secret. It would they supply the secret to the burn/verify API call. The earlier Confirmation Code would no longer be needed.
Thus AcmeWidgetForum would be the only site capable of using that Burn Trigger. (Unless they granted that ability to another site by sharing the same keypair, or stole a victim-site's keypair.)
... I know this is reinventing wheels, but I'm gonna choose to believe that there's some minor merit to it.
alt Hacker News
What If: The Site chooses and exposes a public key (a simple one, like SSH, unrelated to TLS/DNS/certs) which the User carries over to create the Burn Trigger.
The Attestor generates a random secret associated with each Burn Trigger, and encrypt it with the supplied public key to create a non-secret Challenge. (Which is carried back by the User or else can be looked up by another API call.)
To burn/verify the Token, the Site would need to use its private key to reverse the process, turning the Challenge back into the secret. It would they supply the secret to the burn/verify API call. The earlier Confirmation Code would no longer be needed.
Thus AcmeWidgetForum would be the only site capable of using that Burn Trigger. (Unless they granted that ability to another site by sharing the same keypair, or stole a victim-site's keypair.)
... I know this is reinventing wheels, but I'm gonna choose to believe that there's some minor merit to it.