Lesson 3.3 · 12 min read
Passport and background-check models
Two ways to move evidence and results between parties, and when to use each.
Background-check model
The Attester sends Evidence to the Relying Party, which forwards it to a Verifier and acts on the result. This is how AWS KMS handles Nitro Enclaves: the enclave attaches its attestation document to the KMS request, and KMS itself checks it against the conditions in the key policy.
Passport model
The Attester sends Evidence to a Verifier first, receives an Attestation Result (often a signed token such as a JWT), and presents that token to Relying Parties. Microsoft Azure Attestation and Google Cloud's Confidential Space attestation service both issue signed tokens that downstream services can check without understanding hardware-specific evidence.
| Background-check | Passport | |
|---|---|---|
| Relying Party must understand evidence formats? | Yes, or must call a verifier | No, only the result token |
| Freshness | Relying Party can supply a nonce directly | Token lifetime and nonce handling need care |
| Typical example | AWS KMS with Nitro Enclaves | Azure Attestation tokens, Confidential Space OIDC tokens |
| Main risk | Each Relying Party re-implements checks | Over-long token lifetimes; tokens accepted by unintended audiences |
Key takeaways
- Background-check: the Relying Party consults the verifier. Passport: the Attester carries a result token.
- Passport tokens must have short lifetimes and a restricted audience.
- Log every appraisal decision; failed attestations are security events.
Primary source: RFC 9334: Remote ATtestation procedureS (RATS) Architecture.
End of module 3
Take the module 3 quiz to check your understanding.