Summary

  • RFC 9783 profiles an Entity Attestation Token for PSA Initial Attestation, carrying bounded claims such as nonce, client ID, instance ID, implementation ID, lifecycle and software components.
  • Protected evidence can support a verifier’s appraisal. It does not, by itself, establish a relying party’s authority to enroll, admit, retain, route work to or otherwise act on a device.

The useful question is not whether the token is “trusted” in the abstract. It is which proposition each field can support, who checks it, and which later decision remains with a separately accountable actor. RFC 9783 is unusually clear material for that exercise because it does not offer a magic device verdict. It profiles PSA Initial Attestation within the IETF’s broader Remote ATtestation procedureS model, where an Attester produces Evidence, a Verifier appraises it, and a Relying Party uses an Attestation Result for its own purpose. The token is evidence in a chain, not a shortcut around the chain.

Start with the nonce. The profile requires one nonce and allows lengths of 32, 48 or 64 bytes. It binds a report to a caller’s challenge, so a verifier can test freshness against the challenge it issued or accepted. That is important protection against replay. It is not proof that the caller is entitled to a particular service, that the device’s operator is contractually eligible, or that a still-valid challenge should lead to a permanent grant. Freshness is a time-bounded property of evidence, not a blanket permission.

The client ID carries a different, carefully limited proposition: it represents the security domain from which the Initial Attestation service was called. RFC 9783 says a verifier must check it to prevent one endpoint from presenting itself as another domain. This makes the field operationally serious; an unchecked client ID is an invitation to spoofing across a boundary. But a correctly checked client ID still does not tell a Relying Party which account, tenant, asset owner, business process or risk class should receive a benefit. It separates callers. It does not write the admission policy.

Instance ID and implementation ID are deliberately not substitutes for one another. The instance ID identifies the particular Initial Attestation Key and is unique to that instance. The implementation ID identifies an immutable PSA Root of Trust hardware assembly, not an individual instance; a verifier can use it to locate information from an Endorser, including manufacturer details or certification status. A policy that collapses those two questions loses a useful distinction.

“Which particular key and instance produced this?” and “what immutable implementation family is claimed?” may both matter, yet neither answers “what should this service now do?”

Lifecycle and software-component claims need the same restraint. Lifecycle can state a PSA state with major and minor values. The profile gives a verifier meaningful constraints: reports outside specified secured or non-PSA-RoT-debug states should not be trusted. Software-component claims describe the code, configuration or other loaded components within the PSA Root of Trust’s measured scope. These are strong reasons for a verifier to reject a report, request more evidence, apply a narrower appraisal policy or return a qualified result.

They are not evidence of every fact that a service owner might care about: a workload’s current purpose, an operator’s authorization, a tenant’s approval, a commercial commitment, a retained exception or the effect of an action after it is taken.

That difference is not pedantry. A signed field can be technically genuine and still be insufficient for a particular decision. A verifier might establish that the report is protected as expected, that its nonce is fresh, that the client domain matches the request, and that an implementation and lifecycle meet a stated appraisal policy. The Relying Party may nevertheless reject enrollment because the device belongs to an unapproved fleet, keep access temporary because an endorser record is incomplete, or decline a high-impact action because a separate operator approval is absent. Those are not failures of RFC 9783.

They are the decisions the profile deliberately does not impersonate.

Heng Lu’s minimum-initial-specification argument points to the design virtue here. A common mechanism earns confidence by stating just enough that different parties can check the same bounded claim, while leaving future and local decisions to the party that bears them. The running-code test is equally useful: successful generation and validation show that a defined mechanism ran and an evidence check was performed. They do not turn a device-produced statement into control over a service, a budget or a human consequence.