app-server: implement device key v2 methods

[euroelessar]

Why

The device-key protocol needs an app-server implementation that keeps local key operations behind the same request-processing boundary as other v2 APIs.

app-server owns request dispatch, transport policy, documentation, and JSON-RPC error shaping. codex-device-key owns key binding, validation, platform provider selection, and signing mechanics. Keeping the adapter thin makes the boundary easier to review and avoids moving local key-management details into thread orchestration code.

What changed

• Added DeviceKeyApi as the app-server adapter around DeviceKeyStore.
• Converted protocol protection policies, payload variants, algorithms, and protection classes to and from the device-key crate types.
• Encoded SPKI public keys and DER signatures as base64 protocol fields.
• Routed device/key/create, device/key/public, and device/key/sign through MessageProcessor.
• Rejected remote transports before provider access while allowing local stdio and in-process callers to reach the device-key API.
• Added stdio, in-process, and websocket tests for device-key validation and transport policy.
• Documented the device-key methods in the app-server v2 method list.

Test coverage

• device_key_create_rejects_empty_account_user_id
• in_process_allows_device_key_requests_to_reach_device_key_api
• device_key_methods_are_rejected_over_websocket

Stack

This is PR 3 of 4 in the device-key app-server stack. It is stacked on #18429.

Validation

• cargo test -p codex-app-server device_key
• just fix -p codex-app-server

[viyatb-oai]

[P1] Add regression coverage that device/key/* is rejected over remote‑control origin (not just raw websocket). Code blocks it via ConnectionOrigin::RemoteControl, but no test asserts the slingshot path can’t call device/key/sign.

[euroelessar]

[codex] Addressed in f664fa1: added regression coverage for ConnectionOrigin::RemoteControl attempting device/key/sign through the app-server message processor. The test asserts the request is rejected with INVALID_REQUEST and the remote-transport rejection message.

[chatgpt-codex-connector]

💡 Codex Review

codex/codex-rs/device-key/src/platform.rs

Lines 10 to 24 in a2c2733

	pub(crate) fn default_provider() -> Arc<dyn DeviceKeyProvider> {
	Arc::new(UnsupportedDeviceKeyProvider)
	}
	#[derive(Debug)]
	pub(crate) struct UnsupportedDeviceKeyProvider;
	impl DeviceKeyProvider for UnsupportedDeviceKeyProvider {
	fn create(&self, request: ProviderCreateRequest<'_>) -> Result<DeviceKeyInfo, DeviceKeyError> {
	let _ = request.key_id;
	let _ = request
	.protection_policy
	.allows(DeviceKeyProtectionClass::HardwareTpm);
	let _ = request.binding;
	Err(DeviceKeyError::HardwareBackedKeysUnavailable)

Back device-key API with a real provider

device/key/* now routes through DeviceKeyStore::default(), but platform::default_provider() still returns UnsupportedDeviceKeyProvider. Its create always errors with HardwareBackedKeysUnavailable, and get_public/sign always return KeyNotFound, so the newly exposed app-server methods cannot succeed on any platform.

ℹ️ 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".

[etraut-openai]

One recommended addition for future maintainability, but otherwise looks good.

[etraut-openai]

I recommend adding a big comment here so it's clear to future reviewers (and more importantly to Codex!) that it's important to restrict this to local connection origins. That way, if a new remote connection origin is added, it will be properly excluded from this check.