Consider agent-backed OIDC workload identity issuance

Context

Consider extending Revault with a narrowly scoped workload-identity issuer. The immediate use case is replacing interactive Google account reauthentication during OnePub deployments with short-lived credentials obtained through Google Workload Identity Federation.

This should be evaluated as a general workload identity and attestation feature, not as a Google-specific password workaround or a general human identity provider.

Proposed scope

Add an agent-backed command resembling:

lbx identity issue \
  --profile onepub-deployment \
  --audience <audience> \
  --output <token-file>

An identity profile would define:

• an immutable workload subject
• an allowlist of audiences
• maximum token lifetime
• a dedicated signing key
• optional fixed claims
• whether interactive confirmation is required
• issuance audit policy

The caller must not be able to supply arbitrary claims or ask the agent to sign arbitrary JWT content.

Standards and interoperability

Issue short-lived OIDC-compatible JWT assertions containing at least iss, sub, aud, iat, exp, and jti.

Use conventional OIDC signing algorithms such as RS256 and/or ES256. These keys must be separate from lockbox encryption keys and Revault's existing Ed25519/ML-DSA owner-signing keys.

Potential consumers include Google Workload Identity Federation, AWS IAM OIDC federation, Azure federated identity credentials, HashiCorp Vault JWT/OIDC authentication, Kubernetes, CI systems, and custom OIDC/JWT consumers.

Two possible integration modes:

1. Static JWKS: export/upload the public JWKS to consumers that support locally configured keys.
2. Discoverable issuer: publish only OIDC metadata and public keys over HTTPS at /.well-known/openid-configuration and /jwks.json.

Private signing keys must remain in the local Revault agent.

Security requirements

• Dedicated workload-identity signing keys with strict key separation.
• Short token lifetime, initially around five minutes.
• Audience allowlists and fixed/immutable subjects.
• No generic JWT signing API.
• Require an unlocked Revault session.
• Owner-only runtime files or authenticated local IPC for token delivery.
• Key rotation with overlapping kid entries and documented revocation.
• Audit issuance metadata without logging assertions or secrets.
• Consider explicit approval for the first issuance in each session.
• Treat any process running as the same OS user as potentially able to reach the session agent; assess whether approval, executable identity, or additional policy is required.
• Complete a focused threat model and security review before production use.

Google proof of concept

1. Create a Google Workload Identity Pool and OIDC provider.
2. Upload a Revault-generated JWKS.
3. Map google.subject=assertion.sub.
4. Restrict the provider using subject/audience conditions.
5. Permit that principal to impersonate a narrowly privileged deployment service account using roles/iam.workloadIdentityUser.
6. Generate a five-minute assertion through the local agent.
7. Exchange it through Google STS and execute a non-interactive gcloud compute ssh command.

No Google account password or long-lived Google service-account key should be involved.

Questions to resolve

• Should Revault support both RS256 and ES256, or start with one?
• Should token retrieval use a file, authenticated local HTTP endpoint, executable credential source, or direct IPC?
• Is publishing discovery/JWKS metadata part of Revault, a separate companion service, or documentation only?
• How should installation/workload subjects be generated, backed up, and revoked?
• What confirmation policy provides useful protection against another process running as the same user?
• How should profiles and audience policies be represented in the vault?
• What rotation workflow works consistently across Google, AWS, Azure, and local JWT consumers?
• Does this belong in the existing session agent or in a separate least-privilege signing agent?

Non-goals

• Human login or account management
• Password authentication
• OAuth consent screens
• Refresh-token issuance
• A general OAuth authorization server
• Arbitrary JWT signing
• Reusing lockbox encryption or owner-signing keys

No implementation files or tests are named. Start by mapping the existing session agent, vault profile, and local IPC entry points, then review the threat-model and security requirements; done means an agreed architecture covering scoped issuance, key separation, rotation, delivery, and the Google proof of concept.