Let's say that attestation revocation is done in a smart contract (it might be the same smart contract that manages issuer keys, so the revocation of issuer key is together).
There is this attack scenario for Devcon:
- Buy a Devcon ticket at $200
- Wait for Ethereum to congest
- Request a refund of a ticket already purchased.
- Devcon will send a refund transaction costing $300 each.
There is a simple solution to prevent such an attack:
- Devcon ticket purchase doesn't require Ethereum address, however, the refund requires a burn† transaction. Devcon will either
- only refund you the bank transfer if you send a burn transaction or
- refund you with the Ether stored in that contract as part of that transaction.
† @jot2re burn is the blockchain Jardon for revocation.
Burning would require a valid ticket the same process as using a ticket to send a transaction. Burning may result a direct refund from the smart contract.
The specific case of devcon
Now speaking in the specific case of Devcon, they wish for a free email attestation, that is, for anyone who can prove that they know the secret of a ticket, attestation issuer (attestation.id) issues an email identifier attestation without email verification OTP, since Devcon guarantee that the users can only know the ticket's secret through email at the outset. They wish for it to reduce the number of emails the user has to act on.
The downside is that if any user shared his ticket email on the Internet, every dog and cat on the Internet becomes legit Devcon ticket holders. Devcon can guarantee they only send the secret to the user's email address thus verifying it; the users can't guarantee that they don't share it.
Let's say the worst scenario takes place: someone shared his ticket secret on the Internet. With this revocation method, every dog and cat could burn it (and potentially get a refund in ETH). This isn't necessarily bad, as it deters publishing ticket secret.
Issuer to revoke from their side
Let's say the issuer had a security exploit and the attacker got some tokens for free. Issuer wishes to revoke tokens (if ticket, let's say from No.400 to No.450), or some tickets secrets are leaked. They can either send a transaction to the said smart contract providing
- 𝑎) the list of tickets to revoke, or,
- 𝑏) provide a list of the hashes of the attestations (the stuff that was signed by the issuer), or even a bloom filter of a bunch of such hash (depends on how secure that is).
IIf we go with 𝑏, it allows defining a revocation function independent of the attestation type and make it into ERC/EIP. So if the token isn't a ticket, but a car rego (where the identifier is an IA5String instead of integer), the smart contract interface remains. The downside is that one can't learn what token is revoked unless they have it. Still using the car rego example, you will not be able to learn which rego number is revoked, unless the owner of that rego number tried to log in to a website with an attestation. Judging from today's community preference, I think it's fair to say people ain't concerned with this downside, so I'd go for 𝑏.