EAT Attestation Results

3.1. Input Digest

The ear_input_digest claim cryptographically binds an EAR to the exact appraisal request input received by the Verifier, providing a protection that eat_nonce alone does not provide. While eat_nonce establishes freshness and confirms that the Verifier processed the requester's nonce, it does not bind the remainder of the request.¶

For example, an adversary positioned between the TLS terminator and the Verifier's trust boundary could substitute the evidence carried in the request while leaving the nonce intact. The Relying Party would then receive an EAR with a valid nonce, but for attacker-chosen evidence. ear_input_digest closes this attack by allowing the Relying Party to check that the digest matches the appraisal request input it originally sent (or caused to be sent), exposing any substitution. Other, similar, attacks that rely on tampering with the appraisal request input without affecting the nonce are also expected to be closed by the same mechanism.¶

The digest is computed over the raw wire bytes of the complete appraisal request input:¶

• The sender computes the digest over the encoded request bytes, after encoding and before transmission, and retains those exact bytes for later verification.¶

• The Verifier computes the digest over the raw bytes as received on the wire, before any decoding or processing.¶

Because neither side re-encodes the input before hashing, encoding format and field ordering are irrelevant: the sender and the Verifier are comparing the same bytes -- the ones that were sent on the wire. This also means ear_input_digest is transport-agnostic: it does not matter whether the bytes are carried in an HTTP body, a gRPC message, or any other framing, as long as the sender has access to, and retains, the exact bytes that the Verifier will hash.¶

When using ear_input_digest, use of CMW ([RFC9999]) as the appraisal request format is RECOMMENDED. CMW provides a well-defined encapsulation boundary that makes it straightforward for both parties to identify which bytes constitute the complete request input, and to apply the hash at the correct point in their respective pipelines.¶

3.2. EAR Appraisal Claims

;# import ar4si as ar4si
;# import rfc9711 as eat

EAR-appraisal = {
  ? eat.profile-label => eat.general-uri / eat.general-oid
  status-label => ar4si.trustworthiness-tier
  ? status-details-label => details-type
  ? trustworthiness-vector-label => ar4si.trustworthiness-vector
  ? trustworthiness-vector-details-label => trustworthiness-vector-details
  ? appraisal-policy-ids-label => [ + text ]
  ? eat.nonce-label => eat.nonce-type
  ? attester-claims-label => claims-map-type
  ? verifier-claims-label => claims-map-type
  ? endorser-claims-label => supply-chain-claims-type
  ? reference-value-provider-claims-label => supply-chain-claims-type
  * $$ear-appraisal-extension
}

status-label = eat.JC<"ear_status", 1000>
trustworthiness-vector-label = eat.JC<"ear_trustworthiness_vector", 1001>
status-details-label = eat.JC<"ear_status_details", 1010>
trustworthiness-vector-details-label =
  eat.JC<"ear_trustworthiness_vector_details", 1011>

details-type = [ + text ]

trustworthiness-vector-details = ar4si.non-empty<{
  ? ar4si.instance-identity-label => details-type,
  ? ar4si.configuration-label => details-type,
  ? ar4si.executables-label => details-type,
  ? ar4si.file-system-label => details-type,
  ? ar4si.hardware-label => details-type,
  ? ar4si.runtime-opaque-label => details-type,
  ? ar4si.storage-opaque-label => details-type,
  ? ar4si.sourced-data-label => details-type,
}>
appraisal-policy-ids-label = eat.JC<"ear_appraisal_policy_ids", 1003>
attester-claims-label = eat.JC<"ear_attester_claims", 1005>
verifier-claims-label = eat.JC<"ear_verifier_claims", 1006>
endorser-claims-label = eat.JC<"ear_endorser_claims", 1008>
reference-value-provider-claims-label = eat.JC<"ear_reference_value_provider_claims", 1009>

; supply chain entity name => claims it asserted
supply-chain-claims-type = { + text => claims-map-type }

eat_profile (optional)

The EAT profile (Section 6 of [RFC9711]) associated with the EAR-appraisal claims-set. Note that if multiple EAR-appraisal submods exist within the same EAR token, they may all have different values for this claim. If the EAR-appraisal contains extensions, this claim SHOULD be present unless the profile can be implied by other means (e.g., via the application context or outer protocol elements).¶

ear_status (mandatory)

The overall appraisal status for this attester represented as one of the five trustworthiness tiers (Section 3.2 of [I-D.ietf-rats-ar4si]). The none tier is the neutral element of this computation: it does not affect the result and MUST NOT be used as the value of this claim. The value of this claim MUST be set to a tier of no higher trust than the tier corresponding to the worst trustworthiness claim across the entire trustworthiness vector.¶

ear_status_details (optional)

A non-empty array of strings, each giving a reason for the value of ear_status.¶

ear_trustworthiness_vector (optional)

The AR4SI trustworthiness vector providing the breakdown of the appraisal for this attester. See Section 3.1 of [I-D.ietf-rats-ar4si] for the details.¶

ear_trustworthiness_vector_details (optional)

A map from trustworthiness vector categories to non-empty arrays of strings, each giving a reason for the value of the corresponding category. Each key MUST be a category that is present in ear_trustworthiness_vector. This claim MUST be present unless the party requesting Evidence appraisal explicitly asks for it to be dropped, e.g., via an API parameter or similar arrangement. Such consumer would therefore rely entirely on the semantics of the ear_status claim. This behaviour is NOT RECOMMENDED because of the resulting loss of quality of the appraisal result.¶

ear_appraisal_policy_ids (optional)

A list of one or more unique identifiers for appraisal policies used to evaluate the attestation results. The order of the identifiers in the list represents the order in which the policies are applied, with those appearing earlier being applied first. The list MUST NOT be empty.¶

eat_nonce (optional)

The nonce extracted from Evidence corresponding to this appraisal record. Note that this is entirely distinct from the nonce in Section 3. It reflects evidence freshness rather than attestation results freshness. Specifically, it reflects the freshness of the evidence whose attestation results are contained in this appraisal record. This is useful when the relying party is the challenger in the remote attestation protocol and needs to verify that the nonce in the supplied evidence matches, without having to parse the evidence format. See also Section 4.1 of [RFC9711].¶

ear_attester_claims (optional)

A map containing claims with Attester authority, i.e., claims extracted from the appraised Evidence.¶

ear_verifier_claims (optional)

A map containing claims with Verifier authority, i.e., claims added by the Verifier during appraisal and derived from evaluating the Appraisal Policy for Evidence.¶

ear_endorser_claims (optional)

A map containing claims with Endorser authority, i.e., claims that are not present in the appraised Evidence and that the Verifier added during appraisal using Endorsements. Each key identifies the supply chain entity that asserted the claims in the associated value, which is a map of claims. Identifiers are subject to the rules given under ear_reference_value_provider_claims.¶

ear_reference_value_provider_claims (optional)

A map containing claims with Reference Value Provider authority, i.e., claims that are present in the appraised Evidence and that the Verifier corroborated using Reference Values. Each key identifies the supply chain entity that provided the Reference Values, and the associated value is a map of the corroborated claims. A corroborated claim MAY be omitted from ear_attester_claims: the complete set of claims extracted from the Evidence is the union of the two maps. The identifier is a human-readable string (e.g., "Arm" or "NVIDIA") that the Verifier derives from the cryptographic identity of the supply chain entity (e.g., the key that signed the Endorsements or Reference Values) when it ingests them, so that Relying Parties do not have to handle keys. The same entity MUST be given the same identifier throughout an EAR, and an identifier MUST NOT be shared by distinct entities. A claim asserted by more than one authority appears under the identifier of each of them. Each occurrence is an independent assertion. To avoid arbitrary values, the Verifier SHOULD derive the identifier from the first of the following sources that is available: the subject name (e.g., the organization or common name attribute) of the certificate of the key that signed the CoRIM conveying the Endorsements or Reference Values, provided the certification path validates to a trust anchor of the Verifier; the entity-name of the entity with the manifest-signer role in the corim-entity-map (Section 4.1.5 of [I-D.ietf-rats-corim]); the signer-name in the corim-signer-map (Section 4.2.3.1 of [I-D.ietf-rats-corim]); a name configured in the Appraisal Policy for Evidence. The entity-name and signer-name are asserted by the signer itself, so the Verifier MUST NOT use them unless it has authenticated the binding between the name and the key that signed the CoRIM.¶

$$ear-appraisal-extension (optional)

Any registered or unregistered extension. See Section 4 for further details.¶

3.3. Details Claims

The ear_status_details and ear_trustworthiness_vector_details claims let a Verifier tell the Relying Party the reasons for the values of ear_status and of the trustworthiness vector categories. They are optional, and are intended for values other than affirming.¶

Each string states one reason, in text meant for people (e.g., logs, diagnostics, support). The text is not standardised: it can change between Verifiers, versions of the same Verifier and, if localised, languages. A Relying Party MUST NOT base automated decisions on it. Those rely entirely on ear_status and ear_trustworthiness_vector, which remain authoritative.¶

The text can reproduce data controlled by the Attester (e.g., file names found in the Evidence), so a Relying Party MUST treat it as untrusted input (see Section 7). It can also reveal details of the Attester's state, see Section 8.¶

3.4. Recursive and Tunnelled Submods

In addition to a flat EAR-appraisal, a submod MAY instead carry a nested EAR or a Nested-Token (Section 4.2.18.3 of [RFC9711]). This gives the EAR a recursive structure that can directly reflect the topology of a mesh of cooperating verifiers, e.g., the lead verifier of the Hierarchical pattern defined in [I-D.ietf-rats-multi-verifier], which dispatches the appraisal of composite evidence to one or more sub-verifiers and then collects their results into its own EAR.¶

The three $submod-value alternatives serve different purposes:¶

EAR-appraisal

The existing, flat representation. Used when the verifier itself performs the appraisal of the associated attester, or restates a sub-verifier's result as its own appraisal.¶

EAR

A complete EAR claims-set produced by a sub-verifier, embedded directly, in the same serialization (JSON or CBOR) as the enclosing EAR. This lets a sub-verifier's full result -- including its own submods, potentially several levels deep -- be embedded as plain claims data, integrity-protected only by the enclosing EAR's own signature.¶

Nested-Token

A complete, independently signed EAR produced by a sub-verifier and tunnelled opaquely, using the nesting mechanics described in Section 4.2.18.3 of [RFC9711]. This is the only alternative that supports a sub-verifier whose EAR uses a different serialization than the enclosing token (e.g., a JWT-serialized sub-EAR nested inside a CWT-serialized top-level EAR, or vice versa). The nested token's encoding is self-describing, so the consumer needs no out-of-band knowledge of it: for CBOR it is given by the CBOR tag found after removing the byte string wrapping, for JSON by the JSON-Selector name (Section 4.2.18 of [RFC9711]). EAR restricts Nested-Token to its "JWT" and "CBOR" forms; the "BUNDLE" and "DIGEST" forms defined by [RFC9711] for detached claims-sets are out of scope for EAR. The content of a Nested-Token MUST be an EAR. The CDDL cannot enforce this, because the token is opaque to the schema; a verifier that finds otherwise treats the submod as incomplete (see ear_status in Section 3).¶

The existing flat representation of device topology, the ear_device_topology claim (Section 3), is unaffected by, and can be used independently of, the above; it remains the appropriate choice when a single verifier appraises a composite attester made up of several evidence sources without delegating appraisal to other verifiers.¶

A Relying Party that only consumes the top-level ear_status claim (see Section 3) does not need to understand any of the above: correctness only depends on the verifier correctly rolling up the status of every submod, regardless of its representation, into that claim. A Relying Party that wants a full audit trail, however, needs to be able to recurse into nested EAR submods and to decode Nested-Token submods -- which, per above, may require support for a different serialization or signature scheme than the one used by the enclosing token.¶

Figure 3 shows a lead verifier's EAR for a confidential computing scenario: a confidential VM ("cvm") running on a confidential platform ("cpu") and using a trusted device ("gpu") to offload a specialized ML workload. Each submod uses a different $submod-value kind, reflecting a realistic split of appraisal responsibilities across independent, vendor-specific verifiers: "cvm" is appraised directly by the lead verifier and carries a flat EAR-appraisal; "cpu" is appraised by Vendor-A's confidential computing verifier, whose full EAR claims-set, including its own "platform" submod, is embedded in-band as a nested EAR, because it happens to use the same (JSON) serialization as the enclosing token; "gpu" is appraised by Vendor-B's confidential computing verifier, whose EAR is tunnelled opaquely as a Nested-Token, JWT-serialized regardless of the serialization of the enclosing token. The lead verifier's ear_status reflects the worst status found across all three; the one it cannot itself parse is accounted for as incomplete.¶

=============== NOTE: '\' line wrapping per RFC 8792 ================

{
  "eat_profile": "tag:ietf.org,2026:rats/ear#05",
  "iat": 1666529184,
  "ear_status": "warning",
  "ear_verifier_id": {
    "developer": "https://veraison-project.org",
    "build": "vts 0.0.1"
  },
  "submods": {
    "cvm": {
      "ear_status": "affirming",
      "ear_trustworthiness_vector": {
        "instance-identity": 2,
        "executables": 2,
        "configuration": 2
      }
    },
    "cpu": {
      "eat_profile": "tag:ietf.org,2026:rats/ear#05",
      "iat": 1666529150,
      "ear_verifier_id": {
        "developer": "https://vendor-a.example/cc-verifier",
        "build": "cc-verifier 1.2.0"
      },
      "submods": {
        "platform": {
          "ear_status": "warning",
          "ear_trustworthiness_vector": {
            "hardware": 2,
            "configuration": 1
          }
        }
      }
    },
    "gpu": [
      "JWT",
      "eyJhbGciOiJFUzI1NiJ9.\
eyJlYXRfcHJvZmlsZSI6InRhZzppZXRmLm9yZywyMDI2OnJhdHMvZWFyIzA0IiwiaWF0\
IjoxNjY2NTI5MTAwLCJlYXJfc3RhdHVzIjoiYWZmaXJtaW5nIn0.\
                         QjJyZlBoM0tzWjF2WHdRbjlMbURhU3lFb1RjNGdIak0"
    ]
  }
}

3.5. JSON Serialisation

{
  "eat_profile": "tag:ietf.org,2026:rats/ear#05",
  "iat": 1666529184,
  "ear_verifier_id": {
    "developer": "https://veraison-project.org",
    "build": "vts 0.0.1"
  },
  "ear_raw_evidence": [
    "application/vnd.evidence",
    "NzQ3MjY5NzM2NTYzNzQK"
  ],
  "ear_input_digest": [
    "sha-256",
    "TInrSlzsaz9jfL7abgvJ2roo2P93Jozst3x3OU_afNg"
  ],
  "submods": {
    "PSA": {
      "ear_status": "contraindicated",
      "ear_status_details": [
        "The 'executables' category is contraindicated."
      ],
      "ear_trustworthiness_vector": {
        "instance-identity": 2,
        "executables": 96,
        "hardware": 2
      },
      "ear_trustworthiness_vector_details": {
        "executables": [ "unauthorized code found in runtime memory" ]
      },
      "ear_appraisal_policy_ids":
        [ "https://veraison.example/policy/1/60a0068d" ]
    }
  }
}

{
  "eat_profile": "tag:ietf.org,2026:rats/ear#05",
  "iat": 1666529300,
  "ear_verifier_id": {
    "developer": "https://veraison-project.org",
    "build": "vts 0.0.1"
  },
  "ear_raw_evidence": [
    "application/vnd.evidence",
    "NzQ3MjY5NzM2NTYzNzQKNzQ3MjY5NzM2NTYzNzQK"
  ],
  "submods": {
    "CCA Platform": {
      "ear_status": "affirming",
      "ear_trustworthiness_vector": {
        "instance-identity": 2,
        "executables": 2,
        "hardware": 2
      },
      "ear_appraisal_policy_ids":
        [ "https://veraison.example/policy/1/60a0068d" ]
    },
    "CCA Realm": {
      "ear_status": "affirming",
      "ear_trustworthiness_vector": {
        "instance-identity": 2
      },
      "ear_appraisal_policy_ids":
        [ "https://veraison.example/policy/1/60a0068d" ]
    }
  }
}

3.6. CBOR Serialisation

{
  265: "tag:ietf.org,2026:rats/ear#05",
  6: 1666529184,
  1004: {
    0: "https://veraison-project.org",
    1: "vts 0.0.1"
  },
  1002: [
    "application/vnd.evidence",
    h'6C696665626F61746D616E'
  ],
  1008: [
    1,
    h'4c89eb4a5cec6b3f637cbeda6e0bc9daba28d8ff77268cecb77c77394fda7cd8'
  ],
  266: {
    "PSA": {
      1000: 96,
      1010: [ "The 'executables' category is contraindicated." ],
      1001: {
        0: 2,
        2: 96,
        4: 2
      },
      1011: {
        2: [ "unauthorized code found in runtime memory" ]
      },
      1003: [ "https://veraison.example/policy/1/60a0068d" ]
    }
  }
}

4.1. Unregistered claims

An application-specific extension will normally mint its claim from the "private space" - using integer values less than -65536 for CWT, and Public or Private Claim Names as defined in Sections 4.2 and 4.3 of [RFC7519] when serializing to JWT.¶

It is RECOMMENDED that JWT EARs use Collision-Resistant Public Claim Names (Section 2 of [RFC7519]) rather than Private Claim Names.¶

4.2. Registered claims

If an extension will be used across multiple applications, or is intended to be used across multiple environments, the associated extension claims SHOULD be registered in one, or both, the CWT and JWT claim registries.¶

In general, if the registration policy requires an accompanying specification document (as it is the case for "specification required" and "standards action"), such document SHOULD explicitly say that the extension is expected to be used in EAR claims-sets identified by this profile.¶

An up-to-date view of the registered claims can be obtained via the [IANA.cwt] and [IANA.jwt] registries.¶

4.3. Choosing between registered and unregistered claims

If an extension supports functionality of a specific application (e.g. Project Veraison Services), its claims MAY be registered.¶

If an extension supports a protocol that may be applicable across multiple applications or environments (e.g., TEEP), its claims SHOULD be registered.¶

Since, in general, there is no guarantee that an application will be confined within an environment, it is RECOMMENDED that extension claims that have meaning outside the application's context are always registered.¶

It is also possible that claims that start out as application-specific acquire a more stable meaning over time. In such cases, it is RECOMMENDED that new equivalent claims are created in the "public space" and are registered as described in Section 4.2. The original "private space" claims SHOULD then be deprecated by the application.¶

4.4. Grouping Claims Under a Single Top-Level Key

EAR places no constraint on the type of value carried by an extension claim. An extension may therefore use any CBOR or JSON value type that is appropriate for the information it conveys.¶

However, when an extension introduces more than one logically related claim and those claims are intended to be registered in the CWT or JWT claim registries, it is RECOMMENDED to group them as members of a single map value carried under one top-level registered key. This minimises consumption of the public codepoint namespace, which is a finite shared resource.¶

This recommendation does not apply to claims minted from the private space (integer values less than -65536 for CWT, and Private Claim Names as defined in Section 4.3 of [RFC7519] for JWT), where namespace pressure is not a concern.¶

4.5. TEEP Extension

The TEEP protocol [I-D.ietf-teep-protocol] specifies the required claims that an attestation result must carry for a TAM (Trusted Application Manager) to make decisions on how to remediate a TEE (Trusted Execution Environment) that is out of compliance, or update a TEE that is requesting an authorized change.¶

The list is provided in Section 4.3.1 of [I-D.ietf-teep-protocol].¶

EAR defines a TEEP application extension for the purpose of conveying such claims.¶

;# import rfc9711 as eat
;# import rfc9393

$$ear-appraisal-extension //= (
  ear.teep-claims-label => ear-teep-claims
)

ear-teep-claims = non-empty<{
  ? eat.nonce-label => eat.nonce-type
  ? eat.ueid-label => eat.ueid-type
  ? eat.oemid-label => eat.oemid-pen / eat.oemid-ieee / eat.oemid-random
  ? eat.hardware-model-label => eat.hardware-model-type
  ? eat.hardware-version-label => eat.hardware-version-type
  ? eat.manifests-label => eat.manifests-type
}>

ear.teep-claims-label = eat.JC<"ear_teep_claims", 65000>

{
  "eat_profile": "tag:ietf.org,2026:rats/ear#05",
  "iat": 1666529184,
  "ear_verifier_id": {
    "developer": "https://veraison-project.org",
    "build": "vts 0.0.1"
  },
  "ear_raw_evidence": [
    "application/vnd.evidence",
    "NzQ3MjY5NzM2NTYzNzQK"
  ],
  "submods": {
    "PSA": {
      "ear_status": "contraindicated",
      "ear_trustworthiness_vector": {
        "instance-identity": 2,
        "executables": 96,
        "hardware": 2
      },
      "ear_appraisal_policy_ids":
        [ "https://veraison.example/policy/1/60a0068d" ],
      "ear_teep_claims": {
        "eat_nonce": "80FH7byS7VjfARIq0_KLqu6B9j-F79QtV6p",
        "ueid": "AQIDBAUGBwgJCgsMDQ4PEBESExQVFhcYGRobHB0eHyAh",
        "oemid": "Av8B",
        "hwmodel": "fJYq",
        "hwversion": ["1.2.5", 16384]
      }
    }
  }
}

{
  265: "tag:ietf.org,2026:rats/ear#05",
  6: 1666529184,
  1004: {
    0: "https://veraison-project.org",
    1: "vts 0.0.1"
  },
  1002: [
    "application/vnd.evidence",
    h'6C696665626F61746D616E'
  ],
  266: {
    "PSA": {
      1000: 0,
      1001: {
        0: 2,
        1: 2,
        2: 2,
        4: 2
      },
      1003: [ "https://veraison.example/policy/1/60a0068d" ],
      65000: {
        10: h'948f8860d13a463e',
        256: h'0198f50a4ff6c05861c8860d13a638ea',
        258: 64242,
        259: h'ee80f5a66c1fb9742999a8fdab930893',
        260: ["1.2.5", 16384]
      }
    }
  }
}

4.6. Project Veraison Extensions

The Project Veraison verifier defines a private, application-specific extension:¶

ear_veraison_key_attestation

contains the public key part of a successfully verified attested key. The key is a DER encoded ASN.1 SubjectPublicKeyInfo structure (Section 4.1.2.7 of [RFC5280]).¶

;# import rfc9711 as eat

$$ear-appraisal-extension //= (
  ear.veraison.key-attestation-label => ear-veraison-key-attestation
)

ear-veraison-key-attestation = {
  "akpub" => eat.binary-data
}

ear.veraison.key-attestation-label = eat.JC<"ear_veraison_key_attestation", -70002>

{
  "eat_profile": "tag:ietf.org,2026:rats/ear#05",
  "iat": 1666529184,
  "ear_verifier_id": {
    "developer": "https://veraison-project.org",
    "build": "vts 0.0.1"
  },
  "ear_raw_evidence": [
    "application/vnd.evidence",
    "NzQ3MjY5NzM2NTYzNzQK"
  ],
  "submods": {
    "PSA_IOT": {
      "ear_status": "contraindicated",
      "ear_trustworthiness_vector": {
        "instance-identity": 2,
        "executables": 96,
        "hardware": 2
      },
      "ear_appraisal_policy_ids":
        [ "https://veraison.example/policy/1/60a0068d" ],
      "ear_attester_claims": {
        "eat-profile": "http://arm.com/psa/2.0.0",
        "psa-client-id": 1,
        "psa-security-lifecycle": 12288,
        "psa-implementation-id":
          "AQIDBAUGBwgJCgsMDQ4PEBESExQVFhcYGRobHB0eHyA=",
        "psa-software-components": [
          {
            "measurement-value":
              "AQIDBAUGBwgJCgsMDQ4PEBESExQVFhcYGRobHB0eHyA=",
            "signer-id":
              "AQIDBAUGBwgJCgsMDQ4PEBESExQVFhcYGRobHB0eHyA="
          },
          {
            "measurement-value":
              "AQIDBAUGBwgJCgsMDQ4PEBESExQVFhcYGRobHB0eHyA=",
            "signer-id":
              "AQIDBAUGBwgJCgsMDQ4PEBESExQVFhcYGRobHB0eHyA="
          }
        ],
        "psa-nonce":
          "AQIDBAUGBwgJCgsMDQ4PEBESExQVFhcYGRobHB0eHyA=",
        "psa-instance-id":
          "AQIDBAUGBwgJCgsMDQ4PEBESExQVFhcYGRobHB0eHyAh",
        "psa-certification-reference": "1234567890123-12345"
      },
      "ear_endorser_claims": {
        "ACME Security Lab": {
          "psa-certified": {
            "certificate-number": "1234567890123-12345",
            "date-of-issue": "23/06/2022",
            "test-lab": "Riscure",
            "certification-holder": "ACME Inc.",
            "certified-product": "RoadRunner",
            "hardware-version": "Gizmo v1.0.2",
            "software-version": "TrustedFirmware-M v1.0.6",
            "certification-type": "PSA Certified Level 1 v2.1",
            "developer-type": "PSA Certified – Device"
          }
        }
      },
      "ear_reference_value_provider_claims": {
        "Arm": {
          "psa-implementation-id":
            "AQIDBAUGBwgJCgsMDQ4PEBESExQVFhcYGRobHB0eHyA="
        }
      }
    }
  }
}

{
  "eat_profile": "tag:ietf.org,2026:rats/ear#05",
  "iat": 1666529184,
  "ear_verifier_id": {
    "developer": "https://veraison-project.org",
    "build": "vts 0.0.1"
  },
  "ear_raw_evidence": [
    "application/vnd.evidence",
    "NzQ3MjY5NzM2NTYzNzQK"
  ],
  "submods": {
    "PARSEC_TPM": {
      "ear_status": "affirming",
      "ear_trustworthiness_vector": {
        "instance-identity": 2,
        "executables": 2,
        "hardware": 2
      },
      "ear_appraisal_policy_ids":
        [ "https://veraison.example/policy/1/60a0068d" ],
      "ear_veraison_key_attestation": {
        "akpub":
          "MFkwEwYHKoZIzj0CAQYIKoZIz___"
      }
    }
  }
}

{
  265: "tag:ietf.org,2026:rats/ear#05",
  6: 1666529184,
  1004: {
    0: "https://veraison-project.org",
    1: "vts 0.0.1"
  },
  1002: [
    "application/vnd.evidence",
    h'6C696665626F61746D616E'
  ],
  266: {
    "PSA_IOT": {
      1000: 0,
      1001: {
        0: 2,
        1: 2,
        2: 2,
        4: 2
      },
      1003: [ "https://veraison.example/policy/1/60a0068d" ],
      1005: {
        "eat-profile": "http://arm.com/psa/2.0.0",
        "psa-client-id": 1,
        "psa-security-lifecycle": 12288,
        "psa-implementation-id":
          "AQIDBAUGBwgJCgsMDQ4PEBESExQVFhcYGRobHB0eHyA=",
        "psa-software-components": [
          {
            "measurement-value":
              "AQIDBAUGBwgJCgsMDQ4PEBESExQVFhcYGRobHB0eHyA=",
            "signer-id":
              "AQIDBAUGBwgJCgsMDQ4PEBESExQVFhcYGRobHB0eHyA="
          },
          {
            "measurement-value":
              "AQIDBAUGBwgJCgsMDQ4PEBESExQVFhcYGRobHB0eHyA=",
            "signer-id":
              "AQIDBAUGBwgJCgsMDQ4PEBESExQVFhcYGRobHB0eHyA="
          }
        ],
        "psa-nonce":
          "AQIDBAUGBwgJCgsMDQ4PEBESExQVFhcYGRobHB0eHyA=",
        "psa-instance-id":
          "AQIDBAUGBwgJCgsMDQ4PEBESExQVFhcYGRobHB0eHyAh",
        "psa-certification-reference": "1234567890123-12345"
      },
      1008: {
        "ACME Security Lab": {
          "psa-certified": {
            "certificate-number": "1234567890123-12345",
            "date-of-issue": "23/06/2022",
            "test-lab": "Riscure",
            "certification-holder": "ACME Inc.",
            "certified-product": "RoadRunner",
            "hardware-version": "Gizmo v1.0.2",
            "software-version": "TrustedFirmware-M v1.0.6",
            "certification-type": "PSA Certified Level 1 v2.1",
            "developer-type": "PSA Certified – Device"
          }
        }
      },
      1009: {
        "Arm": {
          "psa-implementation-id":
            "AQIDBAUGBwgJCgsMDQ4PEBESExQVFhcYGRobHB0eHyA="
        }
      }
    }
  }
}

6.1. Project Veraison

The organization responsible for this implementation is Project Veraison, a Linux Foundation project hosted at the Confidential Computing Consortium.¶

The organization currently provides three separate implementations: one in Golang, one in Rust and another in C17.¶

The developers can be contacted on the Zulip channel: https://veraison.zulipchat.com/#narrow/stream/357929-EAR/.¶

7.1. Binding EAR to the Appraisal Request

eat_nonce alone only proves that the Verifier processed a request carrying a given nonce; it does not prove that the request contained the evidence (or any other input) that the requester actually sent. An on-path attacker able to tamper with the appraisal request without disturbing the nonce -- for example, by substituting the evidence while leaving the nonce intact -- can therefore cause a Relying Party to accept an EAR that has a valid nonce but does not reflect the evidence the Relying Party asked to have appraised.¶

The ear_input_digest claim (see Section 3.1), when applicable, mitigates this class of attack by binding the EAR to the exact wire bytes of the appraisal request the Verifier received. Implementers and deployers are strongly encouraged to read Section 3.1 in full before deciding to produce or verify ear_input_digest, since an inappropriate deployment topology can silently negate its security benefit.¶

9.1. New EAT Claims

This specification adds the following values to the "JSON Web Token Claims" registry [IANA.jwt] and the "CBOR Web Token Claims" registry [IANA.cwt].¶

Each entry below is an addition to both registries.¶

The "Claim Description", "Change Controller" and "Specification Documents" are common and equivalent for the JWT and CWT registries. The "Claim Key" and "Claim Value Types(s)" are for the CWT registry only. The "Claim Name" is as defined for the CWT registry, not the JWT registry. The "JWT Claim Name" is equivalent to the "Claim Name" in the JWT registry.¶

10.1. Normative References

[I-D.ietf-rats-ar4si]

Voit, E., Birkholz, H., Hardjono, T., Fossati, T., and V. Scarlata, "Attestation Results for Secure Interactions", Work in Progress, Internet-Draft, draft-ietf-rats-ar4si-11, 30 October 2026, <https://datatracker.ietf.org/doc/html/draft-ietf-rats-ar4si-11>.

[I-D.ietf-rats-eat-measured-component]

Frost, S., Fossati, T., Tschofenig, H., and H. Birkholz, "Entity Attestation Token (EAT) Measured Component", Work in Progress, Internet-Draft, draft-ietf-rats-eat-measured-component-12, 20 February 2026, <https://datatracker.ietf.org/doc/html/draft-ietf-rats-eat-measured-component-12>.

[I-D.ietf-teep-protocol]

Tschofenig, H., Pei, M., Wheeler, D. M., Thaler, D., and A. Tsukamoto, "Trusted Execution Environment Provisioning (TEEP) Protocol", Work in Progress, Internet-Draft, draft-ietf-teep-protocol-26, 26 February 2026, <https://datatracker.ietf.org/doc/html/draft-ietf-teep-protocol-26>.

[RFC2119]

Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/rfc/rfc2119>.

[RFC5280]

Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., and W. Polk, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, <https://www.rfc-editor.org/rfc/rfc5280>.

[RFC7519]

Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token (JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015, <https://www.rfc-editor.org/rfc/rfc7519>.

[RFC8174]

Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.

[RFC8392]

Jones, M., Wahlstroem, E., Erdtman, S., and H. Tschofenig, "CBOR Web Token (CWT)", RFC 8392, DOI 10.17487/RFC8392, May 2018, <https://www.rfc-editor.org/rfc/rfc8392>.

[RFC8610]

Birkholz, H., Vigano, C., and C. Bormann, "Concise Data Definition Language (CDDL): A Notational Convention to Express Concise Binary Object Representation (CBOR) and JSON Data Structures", RFC 8610, DOI 10.17487/RFC8610, June 2019, <https://www.rfc-editor.org/rfc/rfc8610>.

[RFC9711]

Lundblade, L., Mandyam, G., O'Donoghue, J., and C. Wallace, "The Entity Attestation Token (EAT)", RFC 9711, DOI 10.17487/RFC9711, April 2025, <https://www.rfc-editor.org/rfc/rfc9711>.

[RFC9782]

Lundblade, L., Birkholz, H., and T. Fossati, "Entity Attestation Token (EAT) Media Types", RFC 9782, DOI 10.17487/RFC9782, May 2025, <https://www.rfc-editor.org/rfc/rfc9782>.

[RFC9999]

Birkholz, H., Smith, N., Fossati, T., and H. Tschofenig, "Remote ATtestation procedureS (RATS) Conceptual Message Wrapper (CMW)", RFC 9999, DOI 10.17487/RFC9999, July 2026, <https://www.rfc-editor.org/rfc/rfc9999>.

[STD94]

Bormann, C. and P. Hoffman, "Concise Binary Object Representation (CBOR)", STD 94, RFC 8949, DOI 10.17487/RFC8949, December 2020, <https://www.rfc-editor.org/rfc/rfc8949>.

[STD96]

Schaad, J., "CBOR Object Signing and Encryption (COSE): Structures and Process", STD 96, RFC 9052, DOI 10.17487/RFC9052, August 2022, <https://www.rfc-editor.org/rfc/rfc9052>.

10.2. Informative References

[I-D.ietf-rats-corim]

Birkholz, H., Fossati, T., Deshpande, Y., Smith, N., and W. Pan, "Concise Reference Integrity Manifest", Work in Progress, Internet-Draft, draft-ietf-rats-corim-12, 1 November 2026, <https://datatracker.ietf.org/doc/html/draft-ietf-rats-corim-12>.

[I-D.ietf-rats-multi-verifier]

Deshpande, Y., jun, Z., Labiod, H., and H. Birkholz, "Remote Attestation with Multiple Verifiers", Work in Progress, Internet-Draft, draft-ietf-rats-multi-verifier-01, 30 October 2026, <https://datatracker.ietf.org/doc/html/draft-ietf-rats-multi-verifier-01>.

[IANA.cwt]

IANA, "CBOR Web Token (CWT) Claims", <https://www.iana.org/assignments/cwt>.

[IANA.jwt]

IANA, "JSON Web Token (JWT)", <https://www.iana.org/assignments/jwt>.

[RFC4151]

Kindberg, T. and S. Hawke, "The 'tag' URI Scheme", RFC 4151, DOI 10.17487/RFC4151, October 2005, <https://www.rfc-editor.org/rfc/rfc4151>.

[RFC7942]

Sheffer, Y. and A. Farrel, "Improving Awareness of Running Code: The Implementation Status Section", BCP 205, RFC 7942, DOI 10.17487/RFC7942, July 2016, <https://www.rfc-editor.org/rfc/rfc7942>.

[RFC9334]

Birkholz, H., Thaler, D., Richardson, M., Smith, N., and W. Pan, "Remote ATtestation procedureS (RATS) Architecture", RFC 9334, DOI 10.17487/RFC9334, January 2023, <https://www.rfc-editor.org/rfc/rfc9334>.

[RFC9839]

Bray, T. and P. Hoffman, "Unicode Character Repertoire Subsets", RFC 9839, DOI 10.17487/RFC9839, August 2025, <https://www.rfc-editor.org/rfc/rfc9839>.