Spec — SVID Workload Identity Scheme

Internal service-to-service mTLS (stack-RFC-009 Layer 2) authenticates each workload by a short-lived x509 SVID whose SAN carries a SPIFFE-style URI. Koder ID's keys service is the single issuer (§7.4); this spec fixes the identity string so issuer, verifiers and the allow-list agree on one canonical form.

R1 — Canonical form

A workload identity is exactly:

spiffe://koder/<area>/<sector>/<instance>

• Scheme is always spiffe. Trust domain is always koder (the URI host).
• <area> and <sector> are the RFC-003 taxonomy L2 area and L3 sector of the workload (e.g. net/fleet, data/kdb, foundation/id). Lowercase, the same tokens used in the monorepo path — no koder- prefix.
• <instance> distinguishes co-running members of the same sector (e.g. hub, primary, region-b, 0). Lowercase, [a-z0-9-]+.
• All three segments are required and non-empty (crypto.SVIDID rejects otherwise).

R2 — 1:1 with a service-account

Each identity is bound to one Koder ID service-account. The issuer never lets a caller name its own identity: the authenticated SA subject is resolved to its pinned identity via the allow-list, and IssueForRequest signs only that identity (own-identity-only authz — a compromised SA can obtain only its own SVID). Two distinct workloads that must be told apart cryptographically MUST use distinct <instance> (or distinct sector) and distinct service-accounts.

R3 — TTL is the revocation

SVIDs are short-lived (≤ crypto.MaxSVIDTTL, 24h; cadence in hours). There is no CRL/OCSP in v1 — a revoked workload simply stops being re-issued (§7.5). Verifiers MUST reject expired SVIDs (standard x509 path validation) and SHOULD pin the expected peer identity string, not merely "any valid SVID".

R4 — Examples

Origin: stack-RFC-009 §9.5 ("register the SVID identity scheme under specs/naming"). Implemented by services/foundation/id/engine (id#204): pkg/crypto/svid.go (SVIDID, minting) + the keys-service issuance endpoint.