Remote sign-out

The payer OpenAPI 0.5.0 and separate payer SDK add GET /v1/payer/devices. An active DPoP session returns at most twenty devices with opaque ID, creation/last-login time, state and current flag. Use next_cursor as the exclusive before UUID for another page. The server enforces payer ownership; listing does not extend idle time.

The payer API runs only in the local sandbox: the hosted sandbox does not serve it yet.

To sign out another already trusted device, send {target_device_id} to POST /v1/payer/device-revocations with an Idempotency-Key UUID and a fresh DPoP proof. Show the device to the user and ask for an explicit intent to sign it out before signing the challenge. Unknown devices, another payer’s devices and the current device return 404. Signing out the current session uses its existing endpoint.

Sign the returned REVOKE_DEVICE signing_bytes with the caller’s enrolled P-256 key using DER SHA256withECDSA. Submit {signature} to POST /v1/payer/device-revocations/{id}/complete with a separate mutation UUID and fresh DPoP proof. The challenge binds exact target, payer, caller key and original caller session. The target key cannot sign on behalf of the caller. DPoP uses JOSE encoding and authenticates transport; the additional purpose-bound signature authorizes this target operation.

The challenge expires after two minutes and the original session must stay active. The limits are five preparations per device per minute, ten proof attempts per challenge and fifty per device per minute. Keep the signature and the logical UUID after an uncertain response; only the DPoP proof changes on each HTTP attempt. Exact retries keep the original result. Another signature under the same UUID, or a new command on a challenge already used, fails.

Successful revocation atomically invalidates every target session and prevents further unlock by that device. Caller and other devices remain active. This permanently revokes local trust; the flow cannot enroll a new device or recover an account. Additional-device test fixtures exist only in disposable verification databases. Real enrollment/recovery policies, hardware attestation and notification providers remain separate gates. Android and iOS keep independent implementations; Android uses Retrofit, Room and Hilt.