Attestation revocation smart contract

Tokenscript Design
1

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).

Refund scenario

There is this attack scenario for Devcon:

  1. Buy a Devcon ticket at $200
  2. Wait for Ethereum to congest
  3. Request a refund of a ticket already purchased.
  4. Devcon will send a refund transaction costing $300 each.

Devcon loses.

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 ๐‘.

2

When design the attestation revoking process, we may consider using smart contracts on Op-Rollup. http://community.optimism.io/

3

I agree that option b seems to be the nicest (and cheapest!) option. One thing we need to keep in mind is that we want to be able to ensure that tickets and attestations have not been revoked before accepting, so there should be some sort of simple way that a 3rd party can verify whether a ticket or attestation has been revoked.

In the traditional web setting I would imagine that Devcon and Attestation.id, respectively, kept track of revoked tickets and attestations which can be shared on-demand with a 3rd party site. However, since we want to advocate the decentralised web revocation information should be stored on the blockchain instead. I am not sure how efficient it would be to verify that a ticket has not been revoked by reading information stored on the blockchain. Especially if users themselves are able to burn their tickets, the information would probably not be stored in a simple and nice datastructure in one location.

This can be a problem since ideally this check should be done live, whenever a user wishes to use their ticket, even in a web browser. Meaning that a 3rd party web server would need to call the blockchain for every request they receive, or cache information from the blockchain to compare the requests to.

I am really not sure what is the best way of solving the revocation issue if we also want to be able to check whether a ticket or attestation has been revoked, on-the-fly. Maybe we simply want to have the Devcon and Attestation.id servers relay, and sign, the information from the blockchain on-demand so access to the blockchain is only necessarily if their webservers happen to be offline.

1 Like