TLS, mTLS and Device Identity

This lesson is not about seeing a lock icon and concluding that every trust decision is solved. The task is to separate four boundaries: channel protection, service identity verification, mutual client/workload authentication, and authorization for a concrete action. The final artifact is Transport & Workload Identity Trust Record v1. The executable exercise is SEC013-LAB1, which uses only synthetic certificate/SVID metadata and opaque trust-anchor identifiers. No real certificate, private key, production account, external endpoint, or live identity plane is required.

1. TLS protects a channel; it does not collapse every identity decision

TLS provides a protected communication channel. In SEC-013, protocol claims about the current TLS 1.3 specification are bound to RFC9846, which obsoleted RFC 8446 in 2026. That freshness detail matters because treating RFC 8446 as the current TLS 1.3 specification is now stale. Even a correct TLS session, however, does not by itself prove that the observed endpoint is the application identity the caller intended, nor does it authorize every business action.

The evidence record therefore keeps TLS Version Source separate from Server Identity. A channel can be protected while the expected service name is wrong, the trust anchor is not the expected one, or the calling workload is authenticated but not authorized. “Handshake succeeded” and “the intended service identity was verified” are different claims.

2. Service identity is bound to application expectation

A client needs an expectation for the service it meant to reach. A synthetic identity for api.internal.example must not satisfy an expectation for admin.internal.example. The lab models that decision with harmless strings: expected identity, presented identity, identity status, and trust anchor. No certificate parser or private key is involved.

RFC9525 is used only for the frozen claim boundary concerning representation and verification of application service identity in TLS. The exercise does not turn the RFC into an organization-specific authorization policy. The evidence must show where a wrong-name failure is detected so that it is not confused with a later authorization denial.

3. mTLS authenticates a client/workload; authorization remains separate

Mutual TLS can establish cryptographic client/workload identity under a configured PKI. That authentication result is still not a universal business authorization. SEC-013 intentionally implements authentication and authorization as separate gates. A valid workload identity can be authenticated and still receive DENY_ACTION_UNAUTHORIZED for an operation outside its scope.

This is one of the most important rows in the evidence table: Authenticated? = yes while Authorized Action? = no. If those two fields are collapsed, the learner can no longer demonstrate the lesson’s central judgment boundary.

4. Trust anchor and trust domain are explicit inputs

A workload identity is meaningful only inside an explicit trust boundary. The verifier needs to know which trust anchor or trust domain applies to the current context. The local fixture has two contexts, internal_api and admin_endpoint, each with an expected server identity, trust anchor, accepted client trust domain, and action map.

The changed-context transfer does not permit copying the internal API identity policy into the admin endpoint. The learner must rebuild the trust record because the client identity and authorization scope differ. This forces the evidence to remain contextual rather than turning one successful path into a global claim.

5. SPIFFE/SVID concepts are used without operating an identity plane

SPIFFE-X509-SVID is used for the bounded concepts of workload identity, SPIFFE ID, SVID, and trust domain. The lesson does not run SPIRE, a Workload API, or real issuance. A synthetic record such as spiffe://prod.example/workload/orders-api lets the learner reason about trust-domain mismatch without exposing keys or connecting to an external system.

A valid SVID can support cryptographic workload identity, but it is not proof that the workload is uncompromised or authorized for every action. Issuer policy, workload compromise, and environment-specific authorization remain residual or adjacent risks.

6. Failure evidence belongs to the correct boundary

Four failure families are deliberately separated: expired identity, wrong server name, wrong trust domain, and unauthorized action. An expired identity fails before business authorization. A wrong server name fails service identity verification. A wrong client trust domain fails client authentication. An otherwise valid identity performing a disallowed action fails authorization.

Saying only “TLS failed” hides this diagnostic structure. Failure Boundary and Evidence are separate fields so the artifact can distinguish observation from inference.

7. Worked baseline: internal API

The baseline context is internal_api. Its TLS version source is RFC9846. The expected and presented server identities are both api.internal.example. The trust anchor is trust:corp-service-root. The client identity is spiffe://prod.example/workload/orders-api under trust domain prod.example. The action orders.read is allowed for that workload.

The model should produce three positive observations: SERVER_IDENTITY_VERIFIED, CLIENT_AUTHENTICATED, and ALLOW_ACTION. A complete record row contains Connection / TLS Version Source / Server Identity / Client Identity / Trust Anchor / Authenticated? / Authorized Action? / Failure Boundary / Evidence / Residual Risk.

8. Negative Evidence: wrong name

The first safe mutation changes the presented server identity to admin.internal.example while the expectation remains api.internal.example. The correct outcome is DENY_SERVER_IDENTITY_MISMATCH. The request must not reach authorization because the peer identity boundary has already failed.

This negative case demonstrates that a trusted certificate chain alone is not enough; the application identity being verified must match the intended service context.

9. Negative Evidence: authenticated but unauthorized

The second mutation keeps the client identity valid but changes the action from orders.read to admin.read. The client remains authenticated, yet the action must produce DENY_ACTION_UNAUTHORIZED. This is direct evidence that mTLS identity is not being misread as universal authorization.

10. Negative Evidence: wrong trust domain and expiry

If the client identity is presented under dev.example while the context accepts only prod.example, the model returns DENY_CLIENT_TRUST_DOMAIN. If the identity status is expired, it returns DENY_CLIENT_IDENTITY_EXPIRED. These probes mutate only local metadata and never use a real certificate.

11. Authorization follows authentication

The evidence schema preserves two independent fields for authentication and authorization. The baseline policy contains no wildcard action grant. orders-api has a narrow internal API scope; the admin workload has a different action set. Successful authentication is therefore an input to authorization, not the authorization result itself.

12. Observation and security inference are distinct

The Evidence field records local observed output such as SERVER_IDENTITY_VERIFIED / CLIENT_AUTHENTICATED / ALLOW_ACTION. The Residual Risk field records a bounded inference such as: “This synthetic fixture does not prove the real workload, issuer, endpoint, or production policy is uncompromised.”

A green run is not production security certification. owner_acceptance remains blank in the starter artifact so the human decision is not fabricated by tooling or AI assistance.

13. Changed-context transfer: admin endpoint

The independent transfer changes the context to admin_endpoint. Its expected server identity, client identity, and allowed actions differ from the internal API. The learner must rebuild the record and is explicitly forbidden from copying the primary identity/authorization policy as the final answer.

The transfer template keeps final_decision and residual_boundary blank. AI may suggest defensive probes after the learner states the objective, but it may not supply the decisive risk or authorization conclusion.

14. Positive Evidence and Negative Evidence

Positive Evidence includes a verified service identity, authenticated workload identity, accepted trust domain, and authorized action. Negative Evidence must include at least a wrong-name case and an authenticated-but-unauthorized case. Happy-path-only evidence is insufficient for SEC-013.

15. Residual Risk

This lab does not prove certificate parsing, a real TLS handshake, PKI operation, revocation checking, hardware identity, device attestation, production issuer security, or workload integrity. It also does not treat a valid certificate or SVID as proof that a workload is uncompromised. Those limits belong in the final record.

16. Freshness and source boundary

RFC9846 is the current TLS 1.3 specification and obsoletes RFC 8446. RFC9525 is used for service identity verification. SPIFFE-X509-SVID is used for workload identity and trust-domain concepts. None of these sources defines the site-specific business authorization policy for this synthetic system.

17. Final artifact

At the end of SEC013-LAB1, Transport & Workload Identity Trust Record v1 must contain Positive Evidence, Negative Evidence, independent changed-context transfer, and an explicit residual-risk statement. owner_acceptance remains blank in the starter. The local output is evidence for the declared synthetic boundary only; production proof is forbidden.