Workload Identity

SPIFFE Workload Identity

In the loop of autonomous commerce identity identifies the subject of a capability is a mandate bound to a subject. A capability token without a workload binding can be used by a holder of its bearer secret. SPIFFE supplies a cryptographically verifiable workload identity from a runtime such as a mesh, node agent, or attestation service. That identity is specific to the authenticated process.

Chio uses a normalized SPIFFE shape for workload identity. Supported verifier bridges, including Envoy ext_authz principals, Azure MAA JWT, AWS Nitro, and Google Confidential VM, project into the same workloadIdentity record. Policy matches that record.

SPIFFE binds workload identity, and Chio binds the capability. A stolen token still requires the SPIFFE workload identity named in its binding. This limits the token's use when the workload binding is required; it does not add a sidecar.

The Normalized Shape

Runtime attestation and identity claims use one normalized object. Chio policy, governed validation, and receipt metadata consume this shape:

{
  "workloadIdentity": {
    "scheme": "spiffe",
    "credentialKind": "x509_svid",
    "uri": "spiffe://prod.chio/payments/worker",
    "trustDomain": "prod.chio",
    "path": "/payments/worker"
  }
}

The trustDomain and path fields are derived from uri when Chio ingests the identity record. Policy matches the derived fields instead of parsing the URI for each admission.

Credential Kinds

The credentialKind field records how the identity was presented to Chio. The supported SPIFFE credential shapes are:

How an Identity Reaches Chio

Chio does not issue SPIFFE identities. It consumes whatever the runtime already emits. The supported delivery paths are:

1. Envoy ext_authz principal

In a mesh that issues SPIFFE IDs via SPIRE, the ext_authz CheckRequest carries the caller's SPIFFE ID in the source principal. The Chio ext_authz adapter lifts that principal directly into workloadIdentity with credentialKind: uri (the mTLS peer certificate already anchored the identity; chio does not re-verify it). See the Envoy ext_authz integration for configuration details.

2. Explicit runtimeAttestation

SDK callers and CLI issuance paths pass runtimeAttestation.workloadIdentity on the governed or issuance request. Use this path when the caller already holds the SPIFFE ID and wants Chio to bind the capability to it without a verifier bridge.

3. Verifier-bridge projection

Chio's attestation verifier bridges for Azure MAA JWT, AWS Nitro, and Google Confidential VM can project a SPIFFE ID from vendor claims into the normalized shape. For Azure this is a configured x-ms-runtime.claims.* field; for Nitro and Google CVM it is a configured policy projection against the preserved vendor claims. The projection rules are identical to path 2: the derived workloadIdentity must be a valid SPIFFE URI, or issuance fails closed.

Relationship to Runtime Assurance

Workload identity and runtime assurance are separate policy inputs. The assurance tier records how the environment that presented the identity was attested. Policy can require either or both.

Issuance resolves the highest satisfied tier at token-mint time and stamps the capability with a minimum runtime-assurance constraint. Governed execution later re-checks that the presented identity record still clears the stamped tier. Workload identity can be required at any tier, including basic.

Matching on Workload Identity in Policy

Rules consume workload identity through require_workload_identity (hard) or prefer_workload_identity (soft). Both accept a WorkloadIdentityMatch object that gates on trust domain, path prefix, and credential kind:

rules:
  payments_write:
    enabled: true
    default: block
    allow:
      - transfer_funds
    require_workload_identity:
      scheme: spiffe
      trust_domain: prod.chio
      path_prefixes:
        - /payments/worker
        - /payments/reconciler
      credential_kinds:
        - x509_svid
        - jwt_svid

The match is additive. An identity satisfies the rule when trust_domain matches exactly, path starts with one of the configured prefixes, and credentialKind is in the allowed set. A missing field means "any value is acceptable" for that dimension. The full schema lives in the policy-schema reference.

Fail-Closed Rules

The kernel denies issuance or governed execution for these workload-identity conditions:

• An explicit workloadIdentity conflicts with the raw runtimeIdentity in the same runtime-attestation record
• A claimed SPIFFE URI is malformed (wrong scheme, missing trust domain, empty path)
• A require_workload_identity rule is configured and the presented identity does not satisfy it
• The verifier bridge projects a non-SPIFFE identifier into the workload-identity slot

The WORKLOAD_IDENTITY_RUNBOOK reference documents recovery for each condition. These conditions are identity-validation failures, not transient transport failures.

Receipts Carry the Identity Forward

When a governed request clears with workload identity bound, the resulting receipt records the workloadIdentity object that was accepted. A downstream auditor can use the receipt to check that the capability was valid, the guards passed, and the SPIFFE workload bound to the capability presented it.

Bound identity also makes reputation attributable. Receipts linked to the same workload identity can support a track record for that actor. An Agent Passport can include credentials derived from that history.

For the full set of receipt fields and how workload identity appears in the enterprise-profile projection, see the receipt format reference.

Summary

1. SPIFFE shape. Chio normalizes supported workload-identity records to one SPIFFE record.
2. Credential kinds. uri, x509_svid, and jwt_svid cover mesh, serverless, and explicit identity claims.
3. Delivery paths. Envoy principal, explicit runtime attestation, and verifier-bridge projection all converge on the same workloadIdentity record.
4. Identity and assurance compose. Policy can require the SPIFFE path and the runtime-assurance tier independently.
5. Receipt binding. The signed receipt records the accepted workload identity for offline checks of the capability-to-workload binding.

Next Steps

• Autonomous Commerce · how identity connects mandates, governed calls, receipts, settlement, and reputation
• Bind Workload Identity · policy recipes and issuance commands for gating capabilities on a SPIFFE ID
• Envoy ext_authz · how the mesh path lifts a SPIFFE principal into Chio
• Trust Model · the zero-ambient-authority stance that workload identity fits into
• Policy Schema · the full WorkloadIdentityMatch contract