Bind a backchannel request to the person in front of the screen

Setup

CIBA, binding messages and user codes are not implemented yet (G32). Your tenant's email sign-in links face the same problem in another form, a prompt that anyone who knows an address can trigger, and they show binding and sending limits for real.

1. Mia Lane exists in Lab Photos with your plus-address $MIA_EMAIL, as in Sign in on one device and approve on another.

2. In Authentication, note the current values, then set sign-in by email link to Optional with links usable only in the browser that asked (cross-device off).

3. Once G32 exists: the tenant supports CIBA user codes, Ava sets one at $ISSUER/account/security, and lab-tmp-kiosk is registered as able to send it.

Planned walkthrough

1. Request with binding_message=H4PX: the approval on Ava's phone shows H4PX beside the client's name, and she approves only because the kiosk in front of her shows the same code.

2. Two requests at once, from two kiosks: the phone shows two codes, and only one matches the screen in front of her.

Why it matters: the binding message ties the two screens to one transaction, but only if the person actually compares them.

3. User codes on. A request without user_code returns missing_user_code, and a wrong one returns invalid_user_code while her phone stays quiet. Repeated wrong codes are limited per account.

4. Name Ava with id_token_hint from an earlier lab-tmp-kiosk sign-in instead of her email: an expired hint is accepted, and a hint issued to another client is not.

5. An unsuitable binding message, too long or with unprintable characters, returns invalid_binding_message.

Do today

1. A link bound to the browser that asked. On your computer, open $ISSUER/login, choose an email link, and enter $MIA_EMAIL. Open the link on your phone: "Open this link in the browser where you asked for it." Logs counts account.sign_in rejected invalid_link. Open the same link on the computer: Mia is signed in.

Why it matters: someone who only receives the link elsewhere, or is sent one they did not ask for, cannot use it. That is what a binding message tries to achieve for CIBA, with a person doing the comparison.

2. Remove the binding on purpose. Allow links to be opened on another device and repeat step 1: the phone completes the sign-in.

Restore: set email links back to the browser that asked (cross-device off).

Why it matters: removing the binding trades certainty about who started the request for convenience, and the choice belongs in the tenant's policy, made deliberately.

3. Prompts anyone can send. Request a link for $MIA_EMAIL several times in a row from the sign-in page. The page looks the same each time. Audit shows account.sign_in link_sent for each accepted request, then rejected rate_limited once the per-address limit is reached, and no further mail arrives.

Why it matters: anything that sends prompts to an address anyone can type needs limits. That is the CIBA problem the lesson describes, and why CIBA adds user codes and better hints.

4. Write in your notes which hint the lesson's kiosk should prefer, and why an email address is the weakest choice for an unattended screen.

Break it

Planned, once G32 exists: Ava declines a request she did not start. The stranger's kiosk sees access_denied on its next poll and learns nothing else.

Check your work

Today: the cross-device refusal in Logs, Mia's sign-ins in Audit, and the link_sent events followed by rate_limited for her address.

Once G32 exists, Audit shows requests refused for a missing or wrong user code before any notification, and approvals recorded with their binding message.

Cleanup

1. Restore the email link settings you noted in Setup.

2. Once G32 exists, clear Ava's user code.

Missing infrastructure

• G32 (CIBA). Including binding_message, user_code with backchannel_user_code_parameter_supported, login_hint_token, per-account request limits, and the approval surface on the authentication device.