Kiosk check-in

In a kiosk check-in, the visit starts on a screen the clinic controls, such as a kiosk in the waiting room or the front desk's computer, and the patient finishes it on their own phone. The clinic's screen can't reach the patient's wallet, and a shared screen is the wrong place to review health information, so the screen shows a code that the patient scans, and the wallet on the phone answers the request. The diagram shows the four steps and what each device holds. You can try it in the kiosk demo.

The four steps

Kiosk check-in, step by step Three columns: the clinic kiosk, the connection between devices, and the patient's phone. Step 1, start: the kiosk builds the request and a one-time key, keeps the private key, and shows a code. Step 2, join: the patient scans the code and the request travels to the phone's check-in page. Step 3, share: the patient reviews in their wallet and shares some or all items; private information stays on the phone. Step 4, return: the encrypted response travels back; the connection cannot read it; the kiosk opens it with its key, checks it against the request, and shows staff that check-in was received. Clinic kiosk or front-desk screen The connection sees only public material Patient's phone check-in page and wallet 1START 2JOIN 3SHARE 4RETURN Builds the request and a one-time key pair. Private key stays here patient scans the code request + public key Opens the check-in page for this visit, on the phone. Reviews in their wallet Shares all, some, or none. Private details stay on the phone Encrypted response can't be read or changed on the way Opens it with its key Checks it against the request, then shows staff: Check-in received
Kiosk check-in, step by step Four steps, top to bottom. Step 1, start, on the clinic kiosk: it builds the request and a one-time key pair, keeps the private key, and shows a code. Step 2, join: the patient scans the code, and the request and public key travel through the connection, which sees only public material, to the check-in page on the patient's phone. Step 3, share, on the patient's phone: the patient reviews in their wallet and shares all, some, or none; private details stay on the phone. Step 4, return: the encrypted response goes back through the connection, which cannot read or change it; the clinic kiosk opens it with its key, checks it against the request, and shows staff that check-in was received. 1 START · CLINIC KIOSK Builds the request and a one-time key pair. Private key stays here 2 JOIN the patient scans the code The connection sees only public material request + public key PATIENT'S PHONE Opens the check-in page for this visit, on the phone. 3 SHARE · PATIENT'S PHONE Reviews in their wallet Shares all, some, or none. Private details stay on the phone 4 RETURN Encrypted response back through the connection; it can't be read or changed on the way CLINIC KIOSK Opens it with its key Checks it against the request, then shows staff: Check-in received

What the handoff must guarantee

The handoff is everything that connects the clinic's screen to the patient's phone: the code, the page the phone opens, and the service that carries messages between them. Whatever form it takes, it has to deliver the request the kiosk built to the phone unchanged, connect the phone to the one session that is waiting for it, and bring the encrypted response back to that session. The code identifies the session, so it needs a random identifier that no one can guess from another visit's code.

Anyone who scans the code can read the request, so the request should say what the clinic needs without containing private details itself. The code also doesn't prove who is holding the phone. A response tells the kiosk what the patient chose to share; matching it to the right patient's record, identity checks, clinical provenance, writing the data back to the EHR, and billing stay with the site and its integration.

Keys and origins

The kiosk's key pair is the HPKE key pair of the ordinary same-device flow: the public key travels to the phone inside encryptionInfo, and the wallet seals its response to it. That is why the connection can't read the response, and why a response changed on the way fails to decrypt at the kiosk instead of reaching staff altered.

The page that calls navigator.credentials.get is the check-in page on the phone, not the kiosk, and the wallet binds its response to the origin of the page that called it (TR-2). The check-in page must therefore pass exactly the argument the kiosk built, and the kiosk must compute the session transcript with the check-in page's origin rather than its own, together with the exact encryptionInfo string it sent (TR-1). If the two origins differ at all, even by a trailing slash, the response doesn't decrypt. The client library's kiosk hand-off does all of this.

The connection can vary

The spec defines the request, the wallet step, and the response. How the phone reaches the waiting session is outside its scope (§1.4): once the check-in page on the phone makes the call, the rest is the ordinary same-device flow of §8. A clinic can therefore choose the connection that fits its setting, such as a QR code on a kiosk or front-desk screen, or a link that the clinic's own app or a text message opens on the patient's phone, as long as it meets the guarantees above. What the clinic's screen shows when the answer arrives is also up to the implementation.