Day 2: SPIFFE Spec — IDs, SVIDs, Trust Domains, Trust Bundles

Phase 4 · August 6, 2026

Agenda (2–3 hours)

• Read (75 min): SPIFFE spec — SPIFFE ID spec + SVID spec + trust domain/bundle sections
• Study (60 min): Annotate key definitions; compare to RFC 5280 concepts
• Challenge (30 min): SPIFFE ID design exercise for your service

The SPIFFE ID

A SPIFFE ID is a URI with the scheme spiffe://:

spiffe://trust-domain/path

Constraints (from the spec):

• Scheme must be spiffe
• Trust domain: fully qualified DNS name; max 255 chars; lowercase
• Path: hierarchical workload identifier; ASCII; max 2048 chars total
• No query parameters, fragments, or port numbers allowed

Examples:

spiffe://leo.amazon.com/ns/prod/svc/provisioning
spiffe://leo.amazon.com/ns/staging/svc/provisioning
spiffe://leo.amazon.com/region/us-east-1/lambda/cert-issuer
spiffe://partner.org/service/consumer         ← different trust domain

What Is an SVID?

SVID = SPIFFE Verifiable Identity Document

An SVID is the carrier of a SPIFFE ID — the document you present to prove
your workload identity.

Two forms:

1. X.509-SVID: a standard X.509 certificate with the SPIFFE ID in a URI SAN
2. JWT-SVID: a JWT token with the SPIFFE ID as the sub claim

X.509-SVIDs are used for mTLS.
JWT-SVIDs are used for HTTP/API contexts (Bearer token).

This phase focuses on X.509-SVIDs because they're the mTLS case most relevant
to your provisioning service.

X.509-SVID Requirements (from spec)

Note: the Subject CN is optional and ignored for identity purposes.
The SPIFFE ID in the URI SAN is the authoritative identity.

Trust Domains

A trust domain is a SPIFFE administrative boundary:

• Has a name (the DNS-like string in the SPIFFE ID)
• Has a trust bundle — the set of CA certs trusted to sign SVIDs in that domain
• Controls which SPIFFE IDs can be issued

An organization typically has one trust domain per environment:

spiffe://prod.leo.amazon.com/...
spiffe://staging.leo.amazon.com/...

Or one per security boundary:

spiffe://leo.amazon.com/...            ← internal workloads
spiffe://partner.leo.amazon.com/...   ← external partner workloads

Trust Bundles

A trust bundle is an X.509 certificate set (the CA chain) for a trust domain.

trust bundle for spiffe://leo.amazon.com
├── Root CA cert  (self-signed, long validity)
└── Intermediate CA cert (signed by root, shorter validity)
    └── Leaf SVIDs are signed here (short validity)

When a workload receives an SVID from a peer, it validates:

1. The cert chain against the trust bundle for the peer's trust domain
2. The SPIFFE ID in the URI SAN is expected/allowed
3. The validity period is current

This is structurally identical to standard TLS cert validation — but the
identity semantics are different (workload URI, not hostname).

Comparing SPIFFE to Classical PKI

Short validity replaces revocation as the primary security mechanism.

Challenge Assignment

Design SPIFFE IDs for your provisioning service components:

For each logical component, define:

1. The SPIFFE ID you'd assign
2. The trust domain it belongs to
3. The mTLS peers it needs to authenticate to/from
4. The maximum cert validity you'd want

Components to consider:

• The Lambda function that handles provisioning requests
• The ACM PCA wrapper (if you had one)
• The internal audit log service
• The downstream device (satellite terminal) — does SPIFFE even apply here?

Write this as a section in spiffe-analysis.md. Think carefully about the
last one — satellite terminals probably can't run a SPIRE agent.
That tension is real and worth articulating.

Resources

• SPIFFE ID spec: github.com/spiffe/spiffe/blob/main/standards/SPIFFE_ID.md
• X.509-SVID spec: github.com/spiffe/spiffe/blob/main/standards/X509-SVID.md
• Trust Domain and Bundle spec: github.com/spiffe/spiffe/blob/main/standards/SPIFFE_Trust_Domain_and_Bundle.md