Application flow

[TomAFrench]

This auto check-in model works on a modified versions of the POAP protocol with some minor changes

Setup:

1. Event organiser connects to location wifi and sets up the signer. They enter an event contract address (event_addr) and a private key which is listed as an admin for that address (admin_pk) (This private key does not need funds and can be set up before and burnt after the event)
2. The signer will make a call to the server passing its local ip address (local_ip) and event_addr which are signed by the admin_pk.
3. The server verifies admin_pk against the event contract to check its admin status. If it is an admin then it updates a record on the backend with local_ip.

The signer is now ready to accept check-ins

Checking in:

1. User connects to the same wifi network as signer.
2. User goes to kickback.events/event/[event_addr] and presses a "check in" button
3. This makes a call to the server which directs the user to local_ip.
4. User passes their address (user_addr) and event_addr to signer and receives them back along with the signer's signature (event_sig)
5. The user then signs the message they receive back and sends it to the server
6. The server then verifies both of these signatures (meanwhile checking user_addr has registered for the event and admin_pk is actually an admin) and if the proofs are valid, stores it in the backend.

The fact that this message has been signed by both parties proves that the user and admin have met. (Attacks described below)

After event:

1. Event admin goes to kickback.events/event/[event_addr]/admin where they can query the received attendance proofs.
2. Event admin submits addresses to contract as currently.

Strengths:

• No specialised equipment
• Users can verify their proof of attendance instantly
• Fits into current check-in flow

Weaknesses:

• Malicious event admins who allows remote connections to signer could allow non-attending users to gain proof of attendance. (Same as currently)
• A remote user could remotely check in with a colluding person present at the event making calls to signer and passing the response back to the user to be signed and submitted. Could maybe be mitigated with a TOTP solution al a NukeManDan's solution
• Still possible for admins to maliciously omit addresses from submission to contract (although Kickback/users would have proof of this) Can be fixed with smart contract changes as below.

Notes:

• The server needn't store local_ip if the event organiser uses a simple qr code to direct the users to this address. (however it is needed for a check in button on the website)
• With smart contract changes server can be removed entirely by allowing users to directly submit proofs to the event contract.

[TomAFrench]

This process could be simplified by reversing the order of signing. This gives the check in process:

Checking in:

1. User connects to the same wifi network as signer.

2. User goes to kickback.events/event/[event_addr] and presses a "check in" button

3. This makes a call to the server which directs the user to local_ip.

4. User signs a message consisting of their address (user_addr) and event_addr and sends it to signer.

5. signer checks that user_addr is registered for event_addr and if so adds their own signature (event_sig) as a receipt.

6. signer then forwards this receipt to both server and the user.

7. The server then verifies both of these signatures (meanwhile checking user_addr has registered for the event and admin_pk is actually an admin) and if the proofs are valid, stores it in the backend.

8. The user locally verifies the receipt as valid and can also see their status updated on kickback.events (The receipt can be saved by the user in case of disputes)

[TomAFrench]

Closing this as the information has been moved to the wiki/guide