3 ms·

This is going in the right direction, but you identified the acceptor double-spend problem. What about if, instead of the spender handing the token directly to

This is going in the right direction, but you identified the acceptor double-spend problem. What about if, instead of the spender handing the token directly to the acceptor, the spender instead first makes an HTTP "I want to spend token 456" request to the issuer, which replies with a "receipt" that the spender then sends to the acceptor, which in turn sends a "If the token associated with this receipt is not yet burnt, burn it, record C next to it and report OK, otherwise if it was already recently burnt using C also report OK (for idempotence), otherwise (if it was already burnt with some other C') report FAIL" request to the issuer. The receipt not being valid as a spendable token cuts out the double-spend issue, at the cost of one extra HTTP request for the spender.

Terr_ 2y ago
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.
- akoboldfrying 2y ago
  >AcmeWidgetForum secretly sends the data onwards It can't do this, because the only "data" it has from the spender is a receipt. A receipt is by design not a spendable token itself; this is trivial to make evident to any party (e.g., tokens are all 100 characters, receipts are all 50).
  - Terr_ 2y ago
    > It can't do this, because the only "data" it has from the spender is a receipt. It can because nothing in that artifact binds it to the one and only one site that the user expects. The only thing keeping it from being used elsewhere is if everybody keeps it secret, and the malicious not-really-spending site simply won't obey that rule. In scenario form: 1. User goes to Attestor, inputs a Token for an output of a Burn Trigger. (I object to "receipt" because that suggests a finalized transaction, and nothing has really happened yet.) 2. Users submits that Burn Trigger to malicious AcmeWidgetForum, which (fraudulently) reports a successful burning and puts a "Verified" badge on the account. 3. In the background, AcmeWidgetForum acts like a different User and submits the Burn Trigger to InnocentSite, which sees no issue and burns it to create a new "verified" account. Even if the User can somehow audit "which site actually claimed responsibility for burning my Token" and sees that "InnocentSite" shows up instead, most won't check, and even knowing that AcmeWidgetForum was evil won't do much to stop the site from harvesting more unwitting Users.
    - akoboldfrying 2y ago
      Ah, you're right. The receipt is "spendable" by the acceptor, since it contains nothing identifying the original spender.
      - Terr_ 2y ago
        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.

Terr_ 2y ago

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.

akoboldfrying 2y ago
>AcmeWidgetForum secretly sends the data onwards It can't do this, because the only "data" it has from the spender is a receipt. A receipt is by design not a spendable token itself; this is trivial to make evident to any party (e.g., tokens are all 100 characters, receipts are all 50).
- Terr_ 2y ago
  > It can't do this, because the only "data" it has from the spender is a receipt. It can because nothing in that artifact binds it to the one and only one site that the user expects. The only thing keeping it from being used elsewhere is if everybody keeps it secret, and the malicious not-really-spending site simply won't obey that rule. In scenario form: 1. User goes to Attestor, inputs a Token for an output of a Burn Trigger. (I object to "receipt" because that suggests a finalized transaction, and nothing has really happened yet.) 2. Users submits that Burn Trigger to malicious AcmeWidgetForum, which (fraudulently) reports a successful burning and puts a "Verified" badge on the account. 3. In the background, AcmeWidgetForum acts like a different User and submits the Burn Trigger to InnocentSite, which sees no issue and burns it to create a new "verified" account. Even if the User can somehow audit "which site actually claimed responsibility for burning my Token" and sees that "InnocentSite" shows up instead, most won't check, and even knowing that AcmeWidgetForum was evil won't do much to stop the site from harvesting more unwitting Users.
  - akoboldfrying 2y ago
    Ah, you're right. The receipt is "spendable" by the acceptor, since it contains nothing identifying the original spender.
    - Terr_ 2y ago
      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.