# Personas and devices

Separate a stable graph identity from the devices authorized to act for it.


A persona owns its connections. A device holds a key that can act for that persona when its binding, lifecycle and authority permit it.

| Identifier | Names | Use |
| --- | --- | --- |
| `graphNodeId` | A stable persona node | Connection endpoints, query source and target |
| `graphKeyId` | One device's P-256 public key | Read authorization, action signatures, lifecycle |

A first device can have the same identifier as its new persona. Do not rely on that equality. Keep both values returned by binding.

## Read the legacy field names correctly

An edge's `signerGraphKeyId` and `subjectGraphKeyId` contain node identifiers. A query's `sourceGraphKeyId` and `targetGraphKeyId` also contain node identifiers. Authorization's `graphKeyId` names the device signing for that node.

The server verifies both the signature and the device-to-node relationship. An app cannot query from an arbitrary persona just by knowing its identifier.

## Bind with AuthenSee

Persist the local key and pending ceremony before opening the hosted flow. Finalize with the initiation capability retained by the app and the completion capability returned to its allowed callback origin. The durable SDK helpers validate the callback and returned key against the saved intent.

To add a device to a known persona, start a fresh ceremony with `recoverNodeId`. Authentication-only recovery with `recoverByPersona` uses an existing verified provider mapping. If that mapping is ambiguous, use an explicit node reference in a fresh ceremony.


**Does not establish**
A public node reference is not authentication. Matching a human's display name or starting an unrelated first-bind ceremony does not establish that the new device belongs to the existing persona.

## Approval is a separate state

A device chain records signed roots, approvals, revocations and resets. An approved, usable device can authorize ordinary graph operations. A newly recovered device on a chained persona starts quarantined until approved or until it completes an eligible reset.

Pending binding → authenticated device → approved or quarantined; authorized device approval changes the approved set. Revoked and expired keys cannot authorize ordinary requests.

Quarantined devices retain limited own-device inspection and maintenance operations. Ordinary reads and actions are refused with `GRAPH_KEY_NOT_APPROVED`. Expired and revoked keys fail lifecycle checks; legacy personas without a chain retain their existing authorization model.

`devices.log` parses the directory. Verify its records and continuity using the SDK's device-chain verifier and retained pins before passing authority into `deviceState`. Binding completion alone is not an approval signal.

## Recovery and revocation

Each device generates its own private key. Device recovery preserves the persona and its connections. An eligible reset opens a new authority epoch and revokes the displaced devices. Recovered devices do not inherit another device's old encrypted-content delivery entitlements.

Revoking a device prevents its future authorized use; it does not automatically remove active persona connections. See [devices API](/api/devices) for the implementation sequence.


**Does not establish**
Persona membership and the `human` or `agent` classification are not proof of humanhood or a real-world identity. A membership certificate also does not establish a recipient's trust in that persona.