Runtime Configuration
How a product fetches scoped configuration documents from the Runtime plane — versions, product/environment scope, and fail-closed crypto. This is not Host platform.json and not the SPA boot file /runtime-config.json.
What you get
| Piece | Role |
|---|---|
| Public config | Non-secret settings delivered as a signed Compact JWS (typ=MH-RUNTIME-CONFIG-V1, ES256) |
| Secret bundle (optional) | Device-eligible secret classes as Compact JWE (typ=MH-RUNTIME-CONFIG-SECRET-V1) — never plaintext in Management read APIs |
| Effective snapshot | Resolved merge for the authenticated device / delivery context (product defaults → environment → document) |
Clients must verify the public JWS (and unwrap JWE only with the expected recipient keys) before applying settings. Unknown formatVersion, wrong typ, bad signature, or mismatched tenant/audience → reject (fail-closed).
Verify trust material (JWKS / offline trust): Verify trust (JWKS).
Human license keys and handling: Secrets · License Keys.
Boundaries
| Do | Don't |
|---|---|
| Fetch config via Runtime (and SDKs when exposed) after AuthN | Treat unsigned JSON from disk as authoritative SoR |
| Cache verified snapshots with your own TTL policy | Log secret-bearing payloads or private keys |
| Use OpenAPI for current routes and shapes | Invent Host/Management internal knobs into the client |
Server-only secrets never appear in device-bound Runtime responses. Ordinary leases / offline / relay manifests remain JWS only — configuration secret delivery is a separate envelope family.
Exact HTTP paths and claim schemas: API Reference (Runtime OpenAPI). Optional Relay cache rules stay product-specific — Relay engine internals are not public.
Related
Next steps
- Getting Started · Developer Quick Start
- Packaging rights: Entitlements