dev.cocore.devicePair.describe

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.

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

Query

query · GET

Parameters

query string

userCode

requiredstring

The code the requester displayed (case-insensitive).

Output

application/json

app

object

The registered application behind this code, when `start` carried `appDid`. `verified` means the return host proved it belongs to the app's DID; an unverified app still gets a key if the user approves, but the browser is never sent to it.

appName

string

expiresInSecs

requiredinteger

keyName

string

returnUrl

string · uri

status

requiredstring
  • enum: pending | approved | denied | expired | consumed

Errors

InvalidRequest

The `userCode` parameter is missing.

NotFound

No pairing attempt matches the `userCode`.

RateLimited

Too many describe calls 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`.

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

  • Describes a pending pairing code so an admin can see which bridge they are about to connect.