app-server: define device key v2 protocol#18428
Conversation
b857fcc to
9a85c6c
Compare
bf613e8 to
9915c86
Compare
|
[P1] Target binding is still implicit. The signed payload only carries targetOrigin/targetPath + token hash, but no explicit server_id/environment_id/session_id. If the backend controller token isn’t already bound to the target server/session, PoP doesn’t prevent cross‑server lateral movement. Either enforce target binding via token claims on the backend, or add explicit target identifiers to the signed payload. |
9915c86 to
a38e6c1
Compare
|
[codex] Addressed in |
a38e6c1 to
3f76329
Compare
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 3f76329516
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| ClientRequest::DeviceKeyCreate { .. } | ||
| | ClientRequest::DeviceKeyPublic { .. } | ||
| | ClientRequest::DeviceKeySign { .. } => { | ||
| warn!("Device key request reached CodexMessageProcessor unexpectedly"); |
There was a problem hiding this comment.
Return an error for unhandled device key RPC methods
device/key/create, device/key/public, and device/key/sign are now part of ClientRequest, but this branch only logs a warning and exits without send_response/send_error. Requests that reach here will hang until client timeout instead of receiving a deterministic JSON-RPC failure.
Useful? React with 👍 / 👎.
Clients need a stable app-server protocol surface for enrolling a local device key, retrieving its public key, and producing a device-bound proof. The protocol reports `protectionClass` explicitly so clients can distinguish hardware-backed keys from an explicitly allowed OS-protected fallback. This keeps degraded protection visible instead of hiding it behind a generic success response. Signing uses a tagged `DeviceKeySignPayload` enum rather than arbitrary bytes. That makes each signed statement auditable at the API boundary and keeps future payload additions compatible with the same `device/key/sign` method shape. - Added v2 JSON-RPC methods for `device/key/create`, `device/key/public`, and `device/key/sign`. - Added request/response types for device-key metadata, SPKI public keys, protection classes, and ECDSA signatures. - Added `DeviceKeyProtectionPolicy` with a default hardware-only behavior and an explicit `allow_os_protected_nonextractable` option. - Added the initial `remoteControlClientConnection` signing payload variant. - Regenerated JSON Schema and TypeScript fixtures for downstream app-server clients. - `just write-app-server-schema` - `cargo test -p codex-app-server-protocol`
3f76329 to
bd1ef3b
Compare
Why
Clients need a stable app-server protocol surface for enrolling a local device key, retrieving its public key, and producing a device-bound proof.
The protocol reports
protectionClassexplicitly so clients can distinguish hardware-backed keys from an explicitly allowed OS-protected fallback. Signing uses a taggedDeviceKeySignPayloadenum rather than arbitrary bytes so each signed statement is auditable at the API boundary.What changed
device/key/create,device/key/public, anddevice/key/sign.DeviceKeyProtectionPolicywith hardware-only default behavior and an explicitallow_os_protected_nonextractableoption.remoteControlClientConnectionsigning payload variant.Stack
This is PR 1 of 4 in the device-key app-server stack.
Validation
just write-app-server-schemacargo test -p codex-app-server-protocol