Apple Patents a QR-Code System That Proves You're Actually There
Apple is patenting a way to use QR codes not just to share information, but to cryptographically prove that a specific device was physically present at a specific moment — a subtle but meaningful upgrade to how we think about QR-based check-ins.
What Apple's proof-of-presence QR trick actually does
Imagine you walk up to a kiosk at a concert venue and scan a QR code on the screen. Normally, anyone who photographed that same code five minutes ago could scan it too. Apple's patent describes a system designed to close that gap.
Here's how it works in plain terms: your phone scans an initial QR code, which kicks off a live connection to a server. The server then shows your phone a new, updated QR code that contains a token — a short-lived credential tied specifically to your device. Your phone scans that second code and sends the token back to the server over the same live connection it already opened.
Because the token only works on the connection your device initiated, it's very hard for someone else to replay or reuse it. The whole point is to confirm: this device was here, right now.
How the token handshake ties device to session
The patent describes a four-step protocol designed to establish proof of presence — a verifiable record that a specific user device was physically present at a location at a given time.
- Step 1 — Capture initial code: The user device scans a machine-readable code (think QR or Data Matrix) displayed at a physical location. That code carries session metadata pointing to a server.
- Step 2 — Initiate connection: Using the session info from the first code, the device opens a connection to the server. Crucially, this connection is tied to a specific data exchange session already running on the server.
- Step 3 — Capture updated code: The server responds by displaying or delivering a second machine-readable code containing a token bound to the user's device.
- Step 4 — Send request with token: The device scans that updated code and sends the token back to the server over the already-open connection.
The key security property here is session binding: the token is only valid on the connection that was opened by the device that scanned the first code. A screenshot of either code, taken out of context, can't be trivially replayed by a different device.
What this means for ticketing, payments, and access control
QR codes are everywhere — boarding passes, event tickets, payment terminals, access control systems — but they have a well-known weakness: a static code can be screenshotted, forwarded, or reused. Apple's approach threads a device-specific token through a live session, making the code ephemeral and device-bound rather than just a static URL.
If this ends up in Apple Wallet or Apple Pay flows, it could meaningfully reduce ticket fraud and credential sharing at venues. It could also serve as infrastructure for secure tap-and-verify scenarios in enterprise or healthcare settings where you need to prove not just what you have, but where you are right now.
This is a genuinely useful piece of authentication infrastructure — not flashy, but solving a real problem with QR codes that has plagued ticketing and access control for years. The session-binding approach is clever and pragmatic. Whether it surfaces in Apple Wallet or some other product context, this is the kind of quiet security plumbing that tends to ship.
Get one Big Tech patent every Sunday
Plain English, intelligent commentary, no hype. Free.
Editorial commentary on a publicly published patent application. Not legal advice.