EAR format#

The CoRIM verifier returns an Entity Attestation Result (EAR) as a JSON object. It is the result of appraising CMW evidence against CoRIM reference manifests. The same object is the payload of an EAR JWT when the verifier is configured to sign its output.

This page describes the format currently emitted by the NVIDIA CoRIM verifier. It is a pre-release format and is subject to change.

The terms EAR, ear_status, and submods follow the IETF RATS EAR model. The ear_nvidia_* claims are NVIDIA extensions.

Top-level claims#

The verifier emits the following top-level claims:

Claim	Description
`eat_profile`	The composite EAR profile identifier.
`iat`, `nbf`, `exp`	JWT numeric dates. The current validity window is one hour.
`ear_verifier_id`	Identifies the verifier implementation with `developer` and `build` fields.
`jti`	A newly generated identifier for this EAR.
`eat_nonce`	The CMW collection nonce, base64url encoded, when present.
`ear_nvidia_inputs.digests`	Digests of verifier inputs, when available. Each entry has an `alg` and a base64url-encoded `val`.
`ear_status`	The aggregate result across all submodules.
`submods`	An object containing one appraisal result for each evidence item.

ear_status is affirming only when every evidence item affirms. It is contraindicated when an item cannot be corroborated or has a verification or appraisal error. The aggregate status is therefore the least favorable status of its submodules. warning is reserved for future use.

The top-level eat_nonce identifies the CMW collection processed by the verifier. It is distinct from a nonce reported by an individual submodule, which comes from that evidence item. A relying party that requires freshness should verify the nonce appropriate to the evidence it requested.

When an EAR is signed, the JWT also carries an iss claim supplied in the EAR signing options. The compact JWT header identifies the signing key with kid.

Submodules#

submods is keyed by the evidence-item label. A label identifies an item in the CMW input; it is not a device-type declaration. Relying parties must use the submodule profile and claims, rather than infer device type from a label.

Each submodule currently has:

Claim	Description
`eat_profile`	The submodule EAR profile identifier.
`evidence_profile`	The profile from the source Concise Evidence or SPDM table of contents, when supplied.
`ear_status`	The appraisal status for that evidence item.
`eat_nonce`	The nonce authenticated in the evidence, base64url encoded, when available.
`ear_nvidia_purpose`	The CoRIM appraisal purpose, when available.
`ear_attester_claims`	Claims reported by the attester, such as hardware model or debug state, when available.
`ear_verifier_claims`	Information produced by the verifier while evaluating the evidence.
`ear_nvidia_error_details`	Errors and diagnostics produced during verification or appraisal, when present.

ear_verifier_claims can contain the following NVIDIA extension claims:

Claim	Description
`ear_nvidia_evidence`	Summary of the evidence processed for this submodule.
`ear_nvidia_rims`	CoRIM manifests used or considered during appraisal.
`ear_nvidia_evidence_rim_cmp`	Comparison results, including matched, mismatched, and unmatched environments.

The contents of these extension claims are implementation details of the current verifier and may evolve with the CoRIM profiles and evidence adapters.

ear_nvidia_purpose qualifies the context of an appraisal. A policy that depends on a particular attestation purpose must check it in addition to ear_status; an affirming result for one purpose does not imply suitability for another.

Privacy#

EARs can contain attester claims and evidence summaries. Treat them as attestation data and share them only with authorized relying parties. The current verifier does not emit stable per-device identifiers, such as device certificate serial numbers, in the EAR. This does not remove the need for a relying party to apply its own data-handling rules to the claims it receives.

Using the EAR#

An EAR describes the verifier’s appraisal; producing or authenticating one does not itself establish that an application accepts it. Apply a relying-party policy to the complete EAR object and make the acceptance decision from the claims relevant to that application. See the CoRIM verifier guide for local policy evaluation and authenticated EAR handling at a remote relying party.