Attestation evidence and bounded issuance

Separate who supplied evidence from what the evidence actually says. An orchestrator can report a workload's namespace and service account; a kernel can identify a local caller; a hardware mechanism may report measured state. Trusting one statement does not extend its coverage to every application property. A correctly named service can still contain a vulnerability, and approved deployment metadata can coexist with a compromised runtime. State the trusted boundary and the remaining attack surface instead of calling every selector an integrity proof.

Freshness and binding prevent evidence from floating free of its requester. Depending on the mechanism, nonces, channel binding, signed time, or authenticated platform queries can help establish a current relationship. The exact attestation protocol determines which are required and what replay resistance exists. Do not bolt an arbitrary timestamp onto untrusted metadata and assume it becomes authoritative. Use the platform's supported attestor and document what a compromised host, control plane, or evidence source could falsify.

For a key-bound certificate, issuance needs a supported proof and binding to the intended public key, subject, trust domain, and validity rules. For an audience-bound token, claims must identify the permitted issuer, subject, audience, and time constraints under the selected format. A bearer token remains usable by a holder who steals it within those constraints unless additional binding is part of the protocol. Treat key-bound and bearer credentials as different security mechanisms rather than interchangeable labels.

The issuer's registration policy is powerful: changing selectors can let another workload obtain the same principal even while signing keys remain secure. Audit changes to entries, attestor configuration, and issuance decisions. Review whether multiple replicas intentionally share one service principal or need instance-specific identities for containment and audit. A larger number of distinct subjects is not automatically more secure; the policy must match the operational unit whose permissions and lifecycle can actually be controlled.

Create rejection tests for a mismatched namespace, wrong service account, unregistered executable identity where applicable, stale evidence, and an unexpected key or audience. Inspect which trusted source produced each selector and whether an attacker controls it. Test registration removal and replacement as well as initial enrollment. Record issued principal, evidence category, policy version, and outcome without exposing private keys or reusable tokens. That makes an issuance anomaly diagnosable without treating every authentication failure as a network problem.

The probability lab illustrates independent acceptance checks only as a statistical contrast. Reset and set both p=0.2, n=10, predict two successes on average, then inspect the exact binomial distribution. Attestation conditions are not independent random guesses, and a shared compromised evidence source can correlate many incorrect decisions. Play highlights possible binomial counts; it performs no attestation or signature verification. Explain why multiplying imagined failure probabilities cannot establish the actual security of a chain with shared trust dependencies.