dev.cocore.devicePair.start
Begin a device-pairing flow (OAuth 2.0 device-authorization style). Returns a `deviceId` plus a short human-typable `userCode` and the `verificationUri` where a signed-in user approves the pairing. The caller then polls `dev.cocore.devicePair.poll` until approval.
Details · procedure
| Kind | procedure |
|---|---|
| Authority | devicePair.cocore.dev |
| Indexed |
Showing version bafyreibupusaow3u5mg7pikgsaarvnfn5u2xuvizwofshi7c4hanob6pnu. Show the latest
Procedure
procedure · POSTOutput
application/jsonSeconds until this pairing attempt expires.
Minimum seconds between poll calls.
Short code the user types at the verification URI.
Similar lexicons
semantic matchLexicons whose schemas describe something close to this one. Check them before publishing a new one that overlaps.
-
dev.cocore.devicePair.confirm
procedureApprove or deny a pending device-pairing attempt, identified by the `userCode` the device displayed. Called from the verification UI by a signed-in user. Approving requires the provider `session` to grant to the device. When the requester supplied an allowlisted `returnUrl` at `start`, an approval echoes it back so the verification UI can send the browser there.
-
Describe a pending pairing attempt by its `userCode`, so the approve screen can say who is asking and for what. Public: it only echoes what the requester supplied at `start` (application name, key name, return URL) plus the attempt's status and remaining lifetime. It never returns the `deviceId` or a session.
-
Poll a device-pairing attempt by `deviceId`. While the user has not acted, returns `pending`. On approval, returns `session` together with the granted provider session. Terminal negative states are `denied`, `expired`, and `consumed`. An unknown `deviceId` is `unknown`.
-
How an application announces itself to co/core so it can connect users' accounts with one click ("Sign in with co/core"). Published by the application on ITS OWN account (a did:plc or did:web with a repo), one record per DID at rkey `self` — there is no central app registry. When the app calls `dev.cocore.devicePair.start` with `appDid`, the AppView reads this record from the app's PDS: `name` is what the approve screen shows, and `returnUrls` are the only places the approve screen may send the