Orbitport: Gateway to Orbital Services

Orbitport exposes key management and tenant-scoped JSON secret storage through an authenticated JSON-RPC API. The TypeScript SDK provides the KMS client, including request validation, encoding, and typed errors.

Request flow

1. Your application sends a bearer token and a JSON-RPC request to POST /api/v1/rpc.
2. The gateway validates the token through the authentication plugin.
3. The gateway parses and validates the JSON-RPC request before reserving credits.
4. The account plugin checks access, reserves credits using an operation label, and resolves the authoritative tenant for PAT requests.
5. The gateway dispatches the request to the KMS plugin, which applies tenant isolation and backend policy, then returns a result or error.
6. The gateway requests settlement of the hold after successful execution, or release after an execution failure or timeout.

The SDK presents the result as ServiceResult<T> with data, metadata, and success. Direct JSON-RPC clients receive a result or error envelope.

Malformed requests and requests rejected by gateway validation do not create credit holds. For accepted requests, the gateway labels usage with the RPC method, adding the key spec for kms.CreateKey and the signing algorithm for kms.Sign. The accounts service uses those labels for usage descriptions and operation pricing. See Credits and usage.

Plugin architecture

Gateway request handling is separate from backend implementations. Authentication, account access, and key management are implemented by plugins connected over gRPC. This separation lets deployments configure services without changing the client-facing transport.

The KMS plugin delegates cryptographic operations to configured providers. Its TRANSIT scheme supports managed encryption and signing keys; the ETHEREUM provider handles secp256k1 signing. The JSON key store uses a separate namespace for application secrets, with authorization enforced by backend policy.

The current SDK exposes key creation, metadata and versioned public-key lookup, encryption, decryption, signing, data-key generation, key rotation, capability discovery, and key-store operations. Backend code also includes threshold operations that the SDK does not expose. Availability depends on deployment configuration; implemented code alone does not establish that a service is enabled.

Authentication and tenant isolation

Public-beta clients use a PAT from the accounts portal, sent as Authorization: Bearer <token>. The SDK accepts the token through accessToken, checks JWT expiry locally, and forwards it to the gateway. It does not acquire or refresh tokens.

The authentication plugin validates PAT signatures, issuer, audience, and expiry. The gateway passes the validated subject and token ID to the account plugin. For PAT requests, the account response supplies the authoritative KMS tenant; request parameters cannot select another tenant.

Legacy Auth0-issued customer bearer tokens remain a backend authentication path. Gateway-internal capability tokens use a separate validator and cannot act as customer credentials. This backend support does not add an OAuth client-credentials flow to the TypeScript SDK.

Keys and secrets are scoped to the authenticated tenant. For JSON secrets, the KMS plugin also applies its configured Cedar policy to put, get, list, and delete operations.

API surface

POST /api/v1/rpc

The SDK groups cryptographic operations under sdk.kms and JSON secret storage under sdk.kms.keyStore. Inputs use camelCase in the SDK and PascalCase on the JSON-RPC wire. Responses preserve the gateway's PascalCase field names.

See Authentication and Use the KMS for request examples, method mappings, error handling, and retries.

Current deployment and orbital roadmap

Orbitport currently operates as a centralized gateway. KMS is experimental, and callers should use the current SDK types and verify their target deployment's configuration and capabilities.

The gateway is designed to support verifiable infrastructure: reproducible builds, measured container images, and attestation of the software serving requests. Making Orbitport Verifiable describes that work.

Orbital key custody and confidential computation introduce additional constraints: satellite pass windows, limited onboard compute, and intermittent connectivity. Satellite communication explains those constraints. Space Fabric describes the satellite-side trust architecture, and SpaceTEE describes the confidential-compute roadmap.

The progression from terrestrial key management to keys held in orbit is covered in Key Management Beyond the Data Center. These roadmap capabilities should not be assumed to be part of a current KMS deployment.