Configure & Attest

Privasys apps configure themselves on first boot and bind opaque values into their RA-TLS leaf certificate at runtime. Two declarations drive this:

Per-app owners team

The deployer of an app is automatically added to its owners team (a list of platform OIDC sub claims persisted on the management service under app_owners). Owners can:

1. Deploy / re-deploy the app.
2. Call @config-api (or org.privasys.config_api) endpoints — i.e. the freeze-gate. Even a platform manager cannot configure an app they don't own; the configure entrypoint is private to the team.
3. Manage the team itself via:
   • GET /api/v1/apps/{id}/owners
   • POST /api/v1/apps/{id}/owners (body: {sub, email, name})
   • DELETE /api/v1/apps/{id}/owners/{sub}

The original creator (apps.owner_sub) cannot be removed from the team — this guarantees there is always at least one principal able to recover the app. The owners list is shipped to the enclave on wasm_load/container_load and persisted with the app metadata, so owner-only calls keep working across enclave restarts without consulting the platform.

Lifecycle

1. Deploy. A user (or a token bearing privasys-platform:manager) deploys an app version to an enclave. The deploy call carries only enclave_id and the version pin — no per-app secrets.
2. Wait for app. The container or wasm module starts and binds its listener.
3. Freeze. The manager intercepts the first request to the app's hostname and replies 503 Retry-After to anything that does not match config_api.{method,path}. The configure path is forwarded in-process.
4. Configure. The deployer POSTs the configuration payload to ${config_api.path}. The app validates it, seals it to its own storage (encrypted volume / sealed KV), and calls setConfigComplete(). The manager flips the freeze flag.
5. Serve. All subsequent traffic is forwarded normally.
6. Restart. On any restart, the app reloads its sealed config from storage; the manager keeps the freeze flag set so the configure step never runs twice for the same payload.

Per-app attestation extensions (OID 1.3.6.1.4.1.65230.3.5.*)

Apps that want to bind opaque values into their RA-TLS leaf certificate — for example: an MCP server URL list, a vector-DB project ID, a hash of a configured API key — call the SDK at runtime:

setAttestationExtension(arc_suffix: u32, value: list<u8>)

The platform:

1. Asserts the OID is under 1.3.6.1.4.1.65230.3.5.<arc_suffix> and under the calling app's namespace.
2. Stores the (oid, value) pair durably so it survives restarts.
3. Re-issues the per-app RA-TLS certificate so subsequent connections see the new extension immediately.
4. On restart, replays the stored extensions into the leaf cert before unblocking traffic.

This means the OID set is part of the verified app surface and is owned by the app itself, not by the operator at deploy time.

SDK surface

Both wasm and container apps expose the same two SDK calls:

The intended pattern in the configure handler is:

1. Validate the inbound payload.
2. Persist anything that needs to survive restart (sealed KV / encrypted volume).
3. setAttestationExtension(<your-arc>, sha256(payload)) so verifying clients can confirm the running app saw exactly the configuration they delivered.
4. setConfigComplete().
5. Return 2xx.

Verifying as a client

A client connecting to the app:

1. Performs the standard RA-TLS handshake; the leaf cert carries the TDX/SGX quote.
2. Pulls the per-app OIDs out of the leaf and recomputes the expected value (e.g. SHA-256 of the API key it provisioned).
3. Equality means this enclave instance was configured with exactly that input — no env var indirection, no out-of-band attestation document needed.

Next steps

• Deploy a container
• Deploy a wasm app
• Attestation and verification