dev.cocore.devicePair.confirm

Approve 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.

Repository @cocore.dev did:plc:5quuhkmwe2q4k3azfsgg7kdz namespace authority
Details · procedure
Kindprocedure
AuthoritydevicePair.cocore.dev
Indexed

Procedure

procedure · POST

Input

application/json

decision

requiredstring
  • enum: approve | deny

session

unknown

Provider session to grant to the device; required when `decision` is `approve`.

userCode

requiredstring

The code the device displayed (case-insensitive).

Output

application/json

ok

requiredboolean

returnUrl

string · uri

Present on approval when the requester asked to be returned to an allowlisted URL.

status

requiredstring

Errors

InvalidRequest

Missing `userCode`, an invalid `decision`, or `approve` without a `session`.

NotFound

No pairing attempt matches the `userCode`.

Conflict

The pairing attempt could not be approved in its current state.

RateLimited

Too many confirm attempts from this client; retry later.

Similar lexicons

semantic match

Lexicons whose schemas describe something close to this one. Check them before publishing a new one that overlaps.

  • 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. The optional input lets an application (rather than a provider machine) say who it is: `appName` is shown on the approve screen, `keyName` names the minted API key so the user can recognise and revoke it, and `returnUrl` is where the a

  • 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`.

  • 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.