The Entity Attestation Token (EAT)
Extracted elements (34)
EAT is defined as a framework with a profile mechanism rather than a fixed token, because no single set of claims can accommodate all use cases. Profiles explicitly narrow CBOR/JSON encoding options, cryptographic algorithms, required claims, and freshness mechanisms to guarantee interoperability for a specific use case.
Nested tokens are cryptographically bound to the enclosing token by inclusion as a signed submodule claim. If submodule attestations were conveyed in parallel without binding, an attacker could substitute a valid attestation from one device for the attestation of a compromised subsystem.
The UEID RAND type uses a minimum of 128 random bits rather than a UUID to avoid the UUID registry and central administration requirements, while still providing sufficient entropy for probabilistic global uniqueness even across ten billion manufacturers.
A CBOR-encoded EAT may contain a JSON-encoded nested token and vice versa, enabling composite devices to be built without regard to encoding used by components. JSON-encoded nested CBOR tokens are base64url encoded; CBOR-encoded nested JSON tokens are text strings.
A receiver of an EAT MUST NOT assume that debug is turned off in a submodule because a superior module claims it is disabled. Every submodule must explicitly describe its own debug state; there is no inheritance.
A UEID consumer MUST treat the UEID as a completely opaque string of bytes and MUST NOT make any use of its internal structure. All implementations MUST be able to receive UEIDs up to 33 bytes long.
All claims in an EAT MUST use the same encoding. CBOR-encoded tokens MUST only use integer labels for claim keys; JSON-encoded tokens MUST only use text strings for claim names.
An EAT MUST contain a Claims-Set and MUST have authenticity and integrity protection. CWT and JWT provide that protection in this document; further documents may define other encodings and security mechanisms.
An EAT nonce MUST have at least 64 bits of entropy. In CBOR, it MUST be a byte string 8–64 bytes long; in JSON, a text string 8–88 bytes long. All receivers MUST be able to accommodate the maximum size.
Any new token format plugging into the $CBOR-Tagged-Token, $EAT-CBOR-Untagged-Token, or $EAT-JSON-Token-Formats sockets MUST be defined by an IETF Standards Action.
Full EAT profiles MUST be complete such that a complying receiver can decode, verify, and check freshness for every EAT created by a complying sender. The 'eat_profile' claim MUST NOT be used to identify partial profiles.
The 'iat' claim MUST NOT contain a floating-point value in an EAT token; any recipient receiving a floating-point 'iat' MUST consider it an error. A 64-bit integer is sufficient to represent +/- 500 billion years.
The JWT 'nonce' claim MUST NOT be used in EAT because it does not support multiple nonces. EAT defines 'eat_nonce' instead, which supports arrays for multistage verification.
UEIDs MUST be universally and globally unique across manufacturers, countries, protocols, and systems. A UEID is permanent and MUST NOT change for a given entity.
The 'bootseed' claim is public and allows correlation of multiple EATs from the same boot session, creating a temporary but linkable pseudonym. It MUST NOT be used as a secret seed, and profiles should specify its lifetime and disclosure constraints.
The 'location' claim can reveal the precise physical location of the entity and its user. Implementations should carefully consider whether location data is necessary, and verifiers should apply privacy-preserving transformations when forwarding location claims to relying parties.
The UEID is a permanent, globally unique identifier that enables cross-context tracking of a device across all interactions. Implementations should limit UEID exposure, and profiles may prohibit its inclusion for privacy-sensitive use cases.
The 'dbgstat' claim reports debug facility status using five ordered levels: enabled, disabled, disabled-since-boot, disabled-permanently (only OEM can re-enable), and disabled-fully-and-permanently. Higher levels imply all lower constraints are met.
The 'eat_profile' claim identifies an EAT profile by URI or absolute OID. It uniquely identifies the profile for both public and private profiles and is used to narrow implementation options for a specific use case.
The 'measres' (measurement results) claim reports comparisons of measurements against reference values. Individual results use an enumerated type: comparison-success (1), comparison-failure (2), comparison-not-run (3), or measurement-absent (4).
The 'oemid' claim identifies the hardware OEM in one of three forms: a PEN-based integer, a 3-byte IEEE MA-L/MA-M/MA-S/CID identifier, or a 16-byte random number. The receiver MUST be able to handle all three forms.
The 'submods' claim is a map whose values may be a Claims-Set, a Detached-Submodule-Digest (algorithm + digest), or a nested token (CBOR or JSON). Submodules do not inherit claims from enclosing tokens and must explicitly include all claims.
The UEID (Universal Entity ID) claim identifies an individual manufactured entity using a type byte followed by unique bytes. Three types are defined: RAND (0x01, 128–256-bit random), IEEE EUI (0x02, EUI-48/60/64), and IMEI (0x03, 14-digit GSMA identifier encoded as 14 bytes).
IANA registered CBOR tag 602 for the Detached EAT Bundle format (BUNDLE-Tagged-Message). This tag is used to distinguish detached EAT bundles from other CBOR token types.
This document creates the 'Entity Attestation Token (EAT) Intended Uses' registry for values of the 'intuse' claim, which signals how an EAT consumer should use the token.
This document registers Device Identifier (DevID) URNs for UEIDs and SUEIDs to provide stable URN-based identifiers for use in protocols that require URN-formatted device identifiers.
This document registers new EAT-specific claims in the IANA 'CBOR Web Token (CWT) Claims' and 'JSON Web Token Claims' registries, including eat_nonce, ueid, sueids, oemid, hwmodel, hwversion, swname, swversion, oemboot, dbgstat, location, uptime, bootcount, bootseed, dloas, manifests, measurements, measres, submods, eat_profile, and intuse.
Freshness must be ensured by including an EAT nonce (at least 64 bits of entropy) or an alternative freshness mechanism defined in the profile. Without freshness, an attacker can replay a previously valid EAT from a compromised device.
The trustworthiness of EAT claims depends entirely on the security level of the attesting environment. Claims from a TEE or Secure Element with hardware defenses carry significantly more weight than claims from a software-only attester with no special protections.
When a detached EAT bundle is used, the integrity of each detached claims set is protected only by the digest included in the main token. If the claims sets are modified in transit before the digest is verified, validation will fail; protocols carrying bundles must ensure integrity of the detached parts.
A Detached-EAT-Bundle encodes as a two-element CBOR array: a main-token (Nested-Token) and a map of label-to-wrapped-claims-set pairs. In CBOR, each claims set is a byte-string-wrapped Claims-Set; in JSON, it is base64url encoded. CBOR tag 602 identifies tagged bundles.
A Detached-Submodule-Digest encodes as a two-element array: a hash algorithm identifier (text or integer from the COSE Algorithms registry) and a binary-data digest. The input to the digest is the raw CBOR or JSON-encoded Claims-Set with no additional wrapping.
A UEID encodes as a single type byte (0x01, 0x02, or 0x03) followed by the type-specific unique bytes. Total length is 7–33 bytes in CBOR (base64url 10–44 characters in JSON); RAND type requires at least 128 bits (16 bytes) of unique bytes.
The 'location' claim encodes latitude and longitude as required numeric fields, with optional altitude, accuracy, altitude-accuracy, heading (number or null), speed, timestamp (integer epoch), and age (unsigned integer seconds). Field labels are integers 1–9 in CBOR.