Design document. This describes a planned capability. It is not yet implemented in the SWT3 SDK or server. Feedback welcome at engineering@tenovaai.com.
OIDC ephemeral signing eliminates long-lived shared secrets for payload signing. Instead of configuring a static signing_key, the SDK obtains a short-lived OIDC identity token from the workload's identity provider (AWS IAM, GCP Workload Identity, Azure Managed Identity, GitHub Actions OIDC) and uses it to sign payloads. The server verifies the signature against the IdP's public JWKS endpoint. No shared secret to rotate, leak, or manage.
1. Problem Statement
Static HMAC signing keys solve payload authenticity but introduce operational burden:
- Keys must be provisioned, stored, and rotated across all environments.
- A leaked key allows an attacker to forge valid signatures until rotated.
- Multi-team organizations must coordinate key distribution without exposing secrets.
- CI/CD pipelines need secret injection for every environment.
OIDC ephemeral signing removes the shared secret entirely. The workload proves its identity using its existing cloud identity, and the server verifies against the identity provider's public key infrastructure.
2. How It Works
2.1 Flow
- The SDK detects that
signing_mode: "oidc" is configured (no signing_key provided).
- At flush time, the SDK requests a short-lived OIDC identity token from the workload's identity provider.
- The SDK signs the payload using the OIDC token as the HMAC key (the token itself is the ephemeral secret).
- The SDK includes the OIDC token in the
X-SWT3-OIDC-Token header.
- The server validates the OIDC token against the IdP's JWKS endpoint (cached, refreshed hourly).
- The server extracts the subject claim (
sub) and verifies it matches the tenant's registered OIDC identity.
- The server re-computes the HMAC using the token as the key and validates the signature.
- The payload is accepted with
signature_status: "oidc_verified".
2.2 Token Lifecycle
| Provider | Token Source | TTL | Audience |
|---|
| AWS | STS AssumeRoleWithWebIdentity | 1 hour | swt3.tenova.io |
| GCP | Metadata server /computeMetadata/v1/instance/service-accounts/default/identity | 1 hour | swt3.tenova.io |
| Azure | Managed Identity endpoint | 1 hour | swt3.tenova.io |
| GitHub Actions | ACTIONS_ID_TOKEN_REQUEST_URL | 5 minutes | swt3.tenova.io |
| Kubernetes | Service Account Token projection | Configurable | swt3.tenova.io |
2.3 Server-Side Verification
The server performs three checks:
- Token validity: Verify JWT signature against IdP's JWKS. Check
exp, aud, iss.
- Identity binding: Match the
sub claim against the tenant's registered OIDC identities.
- Payload signature: Re-compute HMAC-SHA256 using the raw JWT as the key. Compare against
payload_signature using constant-time comparison.
3. Configuration
3.1 SDK Configuration
# .swt3.yaml
endpoint: https://sovereign.tenova.io/api/v1/witness
api_key_env: SWT3_API_KEY
tenant_id: ACME_DEFENSE
signing_mode: oidc
oidc_audience: swt3.tenova.io
3.2 Server-Side Registration
POST /api/v1/oidc-bindings
{
"issuer": "https://token.actions.githubusercontent.com",
"subject": "repo:acme/fraud-detector:ref:refs/heads/main",
"label": "GitHub Actions - fraud detector CI"
}
3.3 Supported Identity Claims
| Provider | Issuer | Subject Example |
|---|
| AWS | https://sts.amazonaws.com | arn:aws:iam::123456:role/fraud-detector |
| GCP | https://accounts.google.com | 123456789@developer.gserviceaccount.com |
| Azure | https://login.microsoftonline.com/{tenant}/v2.0 | system-assigned-managed-identity-id |
| GitHub | https://token.actions.githubusercontent.com | repo:org/repo:ref:refs/heads/main |
4. Security Properties
Advantages over static HMAC keys:
- No shared secret to store, rotate, or leak.
- Token validity measured in minutes or hours, not indefinitely.
- Identity is cryptographically bound to the cloud workload.
- Compromising one token does not compromise future signatures.
- Works with existing cloud IAM infrastructure (no new secret stores).
Limitations:
- Requires network access to the IdP's JWKS endpoint (not suitable for air-gapped environments).
- Token refresh adds a network call per flush cycle (cached, but adds latency on cold start).
- OIDC subject registration is per-environment (the same code running in staging vs production has different subjects).
- Static HMAC signing remains the recommended approach for air-gapped, on-prem, or edge deployments.
5. Comparison: Signing Modes
| Property | Static HMAC | OIDC Ephemeral |
|---|
| Shared secret required | Yes | No |
| Key rotation needed | Yes (manual) | No (automatic) |
| Air-gap compatible | Yes | No |
| Identity binding | By key possession | By cloud identity |
| Compromise blast radius | Until key rotated | Token TTL (minutes/hours) |
| Setup complexity | Low | Medium |
| Latency impact | None | Token fetch (cached) |
| Observation field | signature_status: "verified" | signature_status: "oidc_verified" |
6. Patent Considerations
Patent pending. The combination of OIDC identity tokens as ephemeral HMAC keys for compliance witness payload signing, with server-side JWKS verification and identity-to-tenant binding, represents a novel application of workload identity federation to cryptographic compliance attestation.
7. Implementation Roadmap
- Server: OIDC identity binding store (issuer, subject, tenant, active status).
- Server: JWKS cache with hourly refresh per issuer.
- Server: OIDC token validation in witness endpoint (parallel path to HMAC validation).
- SDK (Python):
signing_mode="oidc" with provider auto-detection.
- SDK (TypeScript):
signingMode: "oidc" with provider auto-detection.
- Dashboard: OIDC binding management UI on settings page.