The direct answer
Keep the intended device, trusted verification display and pending polling record associated throughout device authorization. Follow the exact pending, slowdown, timeout and terminal rules; never turn a received OAuth token into proof of the correct user, physical device or workspace. Attachment requires separate supported binding evidence.
Choose the device grant for the problem it actually solves
An input-constrained assistant display D-A needs permission to read notes for workspace Cedar. Its owner initiates flow F-A and reviews the request on a separate personal device. This is an educational RFC 8628 client worksheet, not a deployed login system or a general recommendation to replace capable-browser authorization.
F-A belongs to a preconfigured authorization server and client. The application fixes its intended workspace and purpose before displaying anything. The model cannot choose an issuer, verification destination, code, credential reference or target workspace. Require a new explicit owner action to start a new flow; a failed or expired attempt does not silently create another.
This differs from receiving a browser authorization-code callback. The worksheet joins a human confirmation step to an outbound polling lifecycle. It does not borrow redirect-state or PKCE behavior to fill unspecified device-grant details.
Make the displayed association inspectable
RFC 8628 sections 3.2–3.3.1 distinguish the displayed user_code and verification_uri from the polling device_code, which is not for display. A complete verification URI can simplify navigation, but clients still display the user code and the server should ask users to compare it with the intended device.
For F-A, the trusted client display names the expected service and intended setup. The owner checks the device they are setting up, the verification service and the request being approved. A code or QR offered in a model reply, unsolicited message or unrelated support conversation is not an instruction to enroll that other flow.
The RFC's remote-phishing and device-trust discussion makes this distinction necessary: approval on one device does not establish the trustworthiness of the requesting device. Display comparison mitigates confusion; it is not device attestation, guaranteed phishing prevention or proof of account identity.
Retain a flow record and a changing polling interval
Propose one protected record for F-A: configured server/client revision, D-A and Cedar association, intended notes-read purpose, separate device-code and user-code references, original expiry E-A, current interval I-A, next eligible attempt and terminal disposition. Those references are inert labels, not usable codes. Keep secrets out of model context and ordinary diagnostic records.
RFC 8628 section 3.5 requires waiting the supplied interval in seconds, defaulting to 5 if absent. authorization_pending continues polling; each slow_down increases the interval by 5 seconds for that and all subsequent requests. Connection timeout requires reduced frequency; exponential backoff is recommended. Other error codes stop polling. Required expires_in gives both codes’ lifetime in seconds.
Invent an interval ledger: omitted interval gives 5; pending keeps 5; slowdown changes it to 10; a connection timeout changes it to 20 under our chosen doubling policy; another pending keeps 20; another slowdown changes it to 25. These numbers describe a proposed schedule, not requests or timings that occurred.
Our stricter worksheet waits before the first attempt too, permits only one outstanding poll, and never resets E-A after a response. Derive a conservative fixed deadline from the valid lifetime evidence; unknown timing must not extend it. Stop new polling on local expiry or an unresolved response shape. Do not claim a stopped scheduler recalls a request already sent.
Eight proposed flow and polling cards
All cards are PROPOSED_UNRUN. Record the intended device/flow, display association, protocol disposition, current interval/expiry and attachment evidence. No actual code, URI, QR, login, browser, timer or token exists in this exercise.
| Invented case | Required worksheet decision |
|---|---|
| 1. Owned-device positive: owner initiates F-A on D-A, confirms its displayed association, and a correctly paced poll later receives supported token success. | End polling as grant_received for F-A. Continue only to separate binding review; this is useful protocol completion, not automatic attachment. |
| 2. Model text or an unsolicited message supplies another device's code or complete link. | Do not adopt that flow. The intended device record and trusted display remain authoritative; apparent code possession is insufficient. |
| 3. Verification service, displayed association or pending record conflicts with F-A. | Stop setup and investigate. Do not switch endpoints, reuse another pending record or try multiple device-code references. |
| 4. authorization_pending while F-A remains live. | Keep pending and wait at least the current interval. Neither the elapsed wait nor the owner's statement substitutes for server completion. |
| 5. slow_down after earlier pending or timeout states. | Add 5 seconds to the current interval and retain that increase for later requests; it is not a one-time pause. |
| 6. Connection timeout. | Reduce frequency before retrying; this worksheet doubles the current interval without extending expiry. An uncertain response is not success. |
| 7. access_denied, expired_token or any other non-pending/non-slowdown error; or local deadline reached. | Stop this polling flow. Show its disposition; require fresh owner action before a separately authorized new initiation. |
| 8. Success arrives but subject, workspace, current rights or flow association is unsupported or changed. | Protect returned credentials and withhold attachment. A late or plausible success cannot rewrite the original target or restore expired authority. |
Separate grant receipt from identity and attachment
Use distinct application states: pending, grant_received, binding_review and attached. A protocol success can advance the positive example to grant_received without proving every later state. If a selected, independently reviewed mechanism establishes the authorized account/subject and permitted workspace association, current-rights checks can then decide attachment.
No such identity-binding mechanism is selected or verified here. Therefore real attachment evidence remains unknown; the worksheet does not treat an access token as a user-authentication assertion. The separate device and the approving browser also need not be the same trusted execution context.
Review token authenticity, allowed scope, credential handling and disconnect behavior in the actual integration before enabling it. Do not infer that consent grants arbitrary tools or that a valid grant authorizes a particular note. Unresolved evidence means an honest setup hold, not a guessed account or an administrator-credential fallback.
Keep the evidence smaller than the claim
Only the RFC body was read. No user code or device code was generated, no login or consent was attempted, and no polling, timer, account, token endpoint, model, API, storage or runtime experiment was performed. The example establishes intended decisions only.
Boundary is prelaunch. Its planned request-path policies and separate synthetic action demo do not implement device authorization, account binding or this poll coordinator. A future release claim needs evidence for the selected server, client authentication, display, timing, binding and current-rights paths; this narrow worksheet is not a current deployment or compliance assessment.
Primary sources
Official references supporting the guidance. Examples in this guide are synthetic and are not reports of a production incident.