]> NVIDIA

tfossati@nvidia.com

Cisco

evoit@cisco.com

Arm Limited

sergei.trofimov@arm.com

Fraunhofer SIT

Rheinstrasse 75 Darmstadt 64295 Germany henk.birkholz@ietf.contact

Security Remote ATtestation ProcedureS EAT attestation result attestation verifier AR4SI This document defines the EAT Attestation Result (EAR) message format. EAR is used by a verifier to encode the result of the appraisal over an attester's evidence. It embeds an AR4SI's "trustworthiness vector" to present a normalized view of the evaluation results, thus easing the task of defining and computing authorization policies by relying parties. Alongside the trustworthiness vector, EAR provides contextual information bound to the appraisal process. This allows a relying party (or an auditor) to reconstruct the frame of reference in which the trustworthiness vector was originally computed. EAR supports simple devices with one attester as well as composite devices that are made of multiple attesters, allowing the state of each attester to be separately examined. EAR can also accommodate registered and unregistered extensions. It can be serialized and protected using either CWT or JWT. About This Document The latest revision of this draft can be found at . Status information for this document may be found at . Discussion of this document takes place on the Remote ATtestation ProcedureS Working Group mailing list (), which is archived at . Subscribe at . Source for this draft and an issue tracker can be found at .

Introduction This document defines the EAT Attestation Result (EAR) message format. EAR is used by a verifier to encode the result of the appraisal over an attester's evidence. It embeds an AR4SI's "trustworthiness vector" to present a normalized view of the evaluation results, thus easing the task of defining and computing authorization policies by relying parties. Alongside the trustworthiness vector, EAR provides contextual information bound to the appraisal process. This allows a relying party (or an auditor) to reconstruct the frame of reference in which the trustworthiness vector was originally computed. EAR supports simple devices with one attester as well as composite devices that are made of multiple attesters (see ) allowing the state of each attester to be separately examined. EAR can also accommodate registered and unregistered extensions. It can be serialized and protected using either CWT or JWT .

Conventions and Definitions This document uses terms and concepts defined by the RATS architecture. For a complete glossary see . The terminology from CBOR , CDDL and COSE applies; in particular, CBOR diagnostic notation is defined in and . The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here.

EAT Attestation Result EAR is an EAT token which can be serialized as JWT or CWT . The EAR claims-set is as follows:

EAR (CDDL Definition) "tag:ietf.org,2026:rats/ear#05" ? status-label => ar4si.trustworthiness-tier ? status-details-label => details-type eat.iat-claim-label => ~eat.time-int ? eat.exp-claim-label => ~eat.time-int verifier-id-label => ar4si.verifier-id ? raw-evidence-label => cmw-record eat.submods-label => { + text => $submod-value } ? eat.nonce-label => eat.nonce-type ? topology-label => topology-type ? input-digest-label => mc.digest * $$ear-extension } cmw-record = eat.JC ; A submod carries one of: ; - EAR-appraisal: the appraisal of a single attester; ; - EAR: an unsigned EAR claims-set from a sub-verifier, in the same ; serialization as the enclosing token; ; - eat.Nested-Token: a complete, signed EAR from a sub-verifier, possibly ; in a different serialization than the enclosing token (see ; Section 4.2.18.3 of RFC 9711 for how the nested token is identified). $submod-value /= EAR-appraisal $submod-value /= EAR $submod-value /= eat.Nested-Token ; EAR-specific claims raw-evidence-label = eat.JC<"ear_raw_evidence", 1002> verifier-id-label = eat.JC<"ear_verifier_id", 1004> topology-label = eat.JC<"ear_device_topology", 1007> input-digest-label = eat.JC<"ear_input_digest", 1008> ]]>

Where:

eat_profile (mandatory)

The EAT profile () associated with the EAR claims-set and encodings defined by this document. It MUST be the following tag URI () tag:ietf.org,2026:rats/ear#05.

ear_status (optional)

The overall appraisal status for the (composite) attester represented as one of the five trustworthiness tiers (). 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 status found across all submods, regardless of whether a given submod is represented as an EAR-appraisal, a nested EAR, or a Nested-Token (see ). When a submod is a Nested-Token whose contents the verifier cannot parse or independently verify -- for example, because it uses a serialization or a signature scheme the verifier does not support, or because it does not contain an EAR -- the verifier MUST treat that submod as having the incomplete tier () for the purposes of computing this claim. That is, the verifier was unable to complete the appraisal of that submod, and therefore cannot vouch for the trustworthiness of the attester it represents. The verifier MUST NOT infer from the opaque submod any tier it has not itself established. Relying Parties that need to know whether the whole tree has been appraised have to inspect the Nested-Token submods individually. This claim exists to help Relying Parties easily determine the overall status of the appraisal without having to inspect each submod.

ear_status_details (optional)

A non-empty array of strings, each giving a reason for the value of ear_status. See for the rules that apply to all *_details claims.

iat (mandatory)

"Issued At" claim -- the time at which the EAR is issued. See and for the EAT-specific encoding restrictions (i.e., disallowing the floating point representation).

exp (optional)

"Expiration Time" claim -- the time at which the EAR expires and MUST NOT be accepted for processing. See . Similar to iat, an EAR token MUST NOT contain an exp claim in floating-point format. Any recipient of a token with a floating-point format exp claim MUST consider it an error.

ear_verifier_id (mandatory)

Identifying information about the appraising verifier. See for further details on its structure and serialization.

ear_raw_evidence (optional)

The unabridged evidence submitted for appraisal, including any signed container/envelope, wrapped in a Record CMW (see ). This field may be consumed by other Verifiers in multi-stage verification scenarios or by auditors. There are privacy considerations associated with this claim. See .

submods (mandatory)

A submodule map () holding, for each separately appraised attester or sub-verifier, one of: an EAR-appraisal; a nested EAR claims-set; or a Nested-Token carrying a complete, independently signed EAR produced by a sub-verifier. The map MUST contain at least one entry. For each appraised attester or sub-verifier the verifier chooses a unique label. For example, when evidence is in EAT format, the label could be constructed from the associated EAT profile. A verifier SHOULD publicly and permanently document its labelling scheme for each supported evidence type, unless EAR payloads are produced and consumed entirely within a private deployment. See for the details about the contents of an EAR-appraisal, and for the recursive and tunnelled cases.

eat_nonce (optional)

A user supplied nonce that is echoed by the verifier to provide freshness. The nonce is a sequence of bytes between 8 and 64 bytes long. When serialized as JWT, the nonce MUST be base64 encoded, resulting in a string between 12 and 88 bytes long. See .

ear_device_topology (optional)

A map that describes the device attester graph using adjacency lists. Attesters are represented by their corresponding labels in the submods claim. Each map key represents an attester in the graph, and the associated map value is an array of labels representing the list of sub-attesters for that attester. If the claim is present, the map MUST contain at least one element.

ear_input_digest (optional)

A cryptographic digest of the appraisal request input that produced this EAR, used to bind the EAR to the exact input the Verifier received. Its value is the digest type defined in . See for the details.

$$ear-extension (optional)

Any registered or unregistered extension. See for further details.

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 () 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.

Applicability Deployments that produce or verify ear_input_digest MUST satisfy both of the following conditions:

1. Encapsulation: the appraisal request input MUST be carried in a single, self-delimiting encapsulation; between the sender's encoding step and the Verifier's hashing step, this encapsulation MUST NOT be modified.
2. Byte access: the sender MUST have access to, and retain, the literal octets of the encoded appraisal request input.

If either condition does not hold, ear_input_digest SHOULD NOT be produced or verified. When both conditions hold, ear_input_digest provides strong end-to-end request binding, and Relying Parties SHOULD verify it.

EAR Appraisal Claims

EAR Appraisal Claims (CDDL Definition) 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 () 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 (). 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 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 . 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 .

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 (); the signer-name in the corim-signer-map (); 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 for further details.

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 ). It can also reveal details of the Attester's state, see .

Recursive and Tunnelled Submods In addition to a flat EAR-appraisal, a submod MAY instead carry a nested EAR or a Nested-Token (). 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 , 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 . 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 (). EAR restricts Nested-Token to its "JWT" and "CBOR" forms; the "BUNDLE" and "DIGEST" forms defined by 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 ).

The existing flat representation of device topology, the ear_device_topology claim (), 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 ) 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. 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.

JSON claims-set: recursive and tunnelled submods

JSON Serialisation

Examples The example in shows an EAR claims-set corresponding to a "contraindicated" appraisal, meaning the verifier has found some problems with the attester's state reported in the submitted evidence. Specifically, the identified issue is related to unauthorized code or configuration loaded in runtime memory (i.e., value 96 in the executables category). The appraisal is for a device with one attester labelled "PSA". Note that in case there is only one attester, the labelling can be freely chosen because there is no ambiguity.

JSON claims-set: contraindicated appraisal

The breakdown of the trustworthiness vector is as follows:

• Instance Identity (affirming): recognized and not compromised
• Configuration (warning): known vulnerabilities
• Executables (contraindicated): contraindicated run-time
• File System (none): no claim being made
• Hardware (affirming): genuine
• Runtime Opaque (none): no claim being made
• Storage Opaque (none): no claim being made
• Sourced Data (none): no claim being made

The example in contains the appraisal for a composite device with two attesters named "CCA Platform" and "CCA Realm" respectively. Both attesters have either "affirming" or (implicit) "none" values in their associated trustworthiness vectors. Note that the "none" values can refer to either an AR4SI category that is unapplicable for the specific attester (ideally, the applicability should be specified by the evidence format itself), or to the genuine lack of information at the attester site regarding the specific category. For example, the reference values for the "CCA Realm" executables (i.e., the confidential computing workload) may not be known to the CCA platform verifier. In such cases, it is up to the downstream entity (typically, the relying party) to complete the partial appraisal.

JSON claims-set: simple affirming appraisal

CBOR Serialisation

Examples The example in is semantically equivalent to that in . It shows the same "contraindicated" appraisal using the more compact CBOR serialization of the EAR claims-set.

CBOR claims-set: contraindicated appraisal

EAR Extensions EAR provides core semantics for describing the result of appraising attestation evidence. However, a given application may offer extra functionality to its relying parties, or tailor the attestation result to the needs of the application (e.g., TEEP ). To accommodate such cases, both EAR and EAR-appraisal claims-sets can be extended by plugging new claims into the $$ear-extension (or $$ear-appraisal-extension, respectively) CDDL socket. The rules that govern extensibility of EAR are those defined in and for CWTs and JWTs respectively. An extension MUST NOT change the semantics of the EAR and EAR-appraisal claims-sets. Whether or not an extension requires a new EAR profile identifier depends on whether it must be understood by all consumers of that EAR token. If an extension is optional, meaning a receiver that does not understand it can safely ignore it while still processing the rest of the EAR correctly, then the existing EAR profile identifier MAY be retained. (This is enabled by the requirement to ignore unknown claims stated in .) However, if an extension introduces claims that MUST be understood and acted upon by all consumers, i.e., a receiver that does not recognise the extension cannot safely process the EAR, then a new EAT profile identifier MUST be used to signal this requirement. Such a profile identifier would typically be defined in a specification document alongside the mandatory extension claims.

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 and of when serializing to JWT. It is RECOMMENDED that JWT EARs use Collision-Resistant Public Claim Names () rather than Private Claim Names.

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 and registries.

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 . The original "private space" claims SHOULD then be deprecated by the application.

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 for JWT), where namespace pressure is not a concern.

TEEP Extension The 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 . EAR defines a TEEP application extension for the purpose of conveying such claims.

TEEP Extension (CDDL Definition) 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> ]]>

JSON Serialization Example

CBOR Serialization Example

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 ().

Project Veraison Extension (CDDL Definition) ear-veraison-key-attestation ) ear-veraison-key-attestation = { "akpub" => eat.binary-data } ear.veraison.key-attestation-label = eat.JC<"ear_veraison_key_attestation", -70002> ]]>

JSON Serialization Examples

CBOR Serialization Example

Media Types Media types for EAR are automatically derived from the base EAT media type using the profile string defined in . For example, a JWT serialization would use: A CWT serialization would instead use:

Implementation Status This section records the status of known implementations of the protocol defined by this specification at the time of posting of this Internet-Draft, and is based on a proposal described in . The description of implementations in this section is intended to assist the IETF in its decision processes in progressing drafts to RFCs. Please note that the listing of any individual implementation here does not imply endorsement by the IETF. Furthermore, no effort has been spent to verify the information presented here that was supplied by IETF contributors. This is not intended as, and must not be construed to be, a catalog of available implementations or their features. Readers are advised to note that other implementations may exist. According to , "this will allow reviewers and working groups to assign due consideration to documents that have the benefit of running code, which may serve as evidence of valuable experimentation and feedback that have made the implemented protocols more mature. It is up to the individual working groups to use this information as they see fit".

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: .

github.com/veraison/ear The software, hosted at , provides a Golang package that allows encoding, decoding, signing and verification of EAR payloads together with a CLI (arc) to create, verify and visualize EARs on the command line. The maturity level is currently alpha, and only the JWT serialization is implemented. The license is Apache 2.0. The package is used by the Project Veraison verifier to produce attestation results.

github.com/veraison/c-ear The software, hosted at , provides a C17 library that allows verification and partial decoding of EAR payloads. The maturity level is currently pre-alpha, and only the JWT serialization is implemented. The license is Apache 2.0. The library targets relying party applications that need to verify attestation results.

github.com/veraison/rust-ear The software, hosted at , provides a Rust (2021 edition) library that allows verification and partial decoding of EAR payloads. The maturity level is currently pre-alpha, with limitted algorithm support. Both JWT and COSE serializations are implemented. The license is Apache 2.0. The library targets verifiers that need to produce attestation results as well as relying party applications that need to verify and consume attestation results.

Security Considerations EAR is a profile of the EAT specification , it also reuses the CWT specification . The security considerations of these specifications therefore apply here too. Any textual fields (e.g., the strings in ear_status_details and ear_trustworthiness_vector_details) that are stored in a file, inserted into a database, or displayed to humans must be properly sanitized to prevent attacks and undesirable behavior. Further discussion and references on this topic can be found in . The ear_endorser_claims and ear_reference_value_provider_claims claims attribute claims to supply chain entities. The attribution is the Verifier's. Relying Parties cannot see or check the keys and signatures on which it is based. Consequently, they rely on the Verifier's mapping from cryptographic identities to identifiers and on the integrity protection of the EAR.

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 ), 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 in full before deciding to produce or verify ear_input_digest, since an inappropriate deployment topology can silently negate its security benefit.

Privacy Considerations EAR is designed to expose as little identifying information as possible about the attester. However, certain EAR claims have direct privacy implications. Implementations should therefore allow applying privacy-preserving techniques to those claims, for example allowing their redaction, anonymisation or outright removal. Specifically:

• It SHOULD be possible to disable inclusion of the optional ear_status_details and ear_trustworthiness_vector_details claims
• It SHOULD be possible to disable inclusion of the optional ear_raw_evidence claim
• It SHOULD be possible to disable inclusion of the optional ear_attester_claims, ear_verifier_claims, ear_endorser_claims and ear_reference_value_provider_claims claims
• It SHOULD be possible to allow redaction, anonymisation or removal of specific claims from the ear_attester_claims, ear_verifier_claims, ear_endorser_claims and ear_reference_value_provider_claims objects

EAR is an EAT, therefore the privacy considerations in apply.

IANA Considerations

New EAT Claims This specification adds the following values to the "JSON Web Token Claims" registry and the "CBOR Web Token Claims" registry . 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.

EAR Status

• Claim Name: ear_status
• Claim Description: EAR Status
• JWT Claim Name: ear_status
• Claim Key: 1000 (suggested)
• Claim Value Type(s): unsigned integer (0, 2, 32, 96)
• Change Controller: IESG
• Specification Document(s): of RFCthis

Trustworthiness Vector

• Claim Name: ear_trustworthiness_vector
• Claim Description: EAR Trustworthiness Vector
• JWT Claim Name: ear_trustworthiness_vector
• Claim Key: 1001 (suggested)
• Claim Value Type(s): map
• Change Controller: IESG
• Specification Document(s): of RFCthis

Status Details

• Claim Name: ear_status_details
• Claim Description: EAR Status Details
• JWT Claim Name: ear_status_details
• Claim Key: 1010 (suggested)
• Claim Value Type(s): array
• Change Controller: IESG
• Specification Document(s): and of RFCthis

Trustworthiness Vector Details

• Claim Name: ear_trustworthiness_vector_details
• Claim Description: EAR Trustworthiness Vector Details
• JWT Claim Name: ear_trustworthiness_vector_details
• Claim Key: 1011 (suggested)
• Claim Value Type(s): map
• Change Controller: IESG
• Specification Document(s): of RFCthis

EAR Raw Evidence

• Claim Name: ear_raw_evidence
• Claim Description: EAR Raw Evidence as CMW
• JWT Claim Name: ear_raw_evidence
• Claim Key: 1002 (suggested)
• Claim Value Type(s): array
• Change Controller: IESG
• Specification Document(s): of RFCthis

EAR Appraisal Policy Identifier

• Claim Name: ear_appraisal_policy_ids
• Claim Description: EAR Appraisal Policy Identifiers
• JWT Claim Name: ear_appraisal_policy_ids
• Claim Key: 1003 (suggested)
• Claim Value Type(s): array
• Change Controller: IESG
• Specification Document(s): of RFCthis

Verifier Software Identifier

• Claim Name: ear_verifier_id
• Claim Description: AR4SI Verifier Software Identifier
• JWT Claim Name: ear_verifier_id
• Claim Key: 1004 (suggested)
• Claim Value Type(s): map
• Change Controller: IESG
• Specification Document(s): of RFCthis

Attester Claims

• Claim Name: ear_attester_claims
• Claim Description: Attester Claims
• JWT Claim Name: ear_attester_claims
• Claim Key: 1005 (suggested)
• Claim Value Type(s): map
• Change Controller: IESG
• Specification Document(s): of RFCthis

Verifier Claims

• Claim Name: ear_verifier_claims
• Claim Description: Verifier Claims
• JWT Claim Name: ear_verifier_claims
• Claim Key: 1006 (suggested)
• Claim Value Type(s): map
• Change Controller: IESG
• Specification Document(s): of RFCthis

Endorser Claims

• Claim Name: ear_endorser_claims
• Claim Description: Endorser Claims
• JWT Claim Name: ear_endorser_claims
• Claim Key: 1008 (suggested)
• Claim Value Type(s): map
• Change Controller: IESG
• Specification Document(s): of RFCthis

Reference Value Provider Claims

• Claim Name: ear_reference_value_provider_claims
• Claim Description: Reference Value Provider Claims
• JWT Claim Name: ear_reference_value_provider_claims
• Claim Key: 1009 (suggested)
• Claim Value Type(s): map
• Change Controller: IESG
• Specification Document(s): of RFCthis

Device Topology

• Claim Name: ear_device_topology
• Claim Description: Device Attesters Arrangement
• JWT Claim Name: ear_device_topology
• Claim Key: 1007 (suggested)
• Claim Value Type(s): map
• Change Controller: IESG
• Specification Document(s): of RFCthis

EAR Input Digest

• Claim Name: ear_input_digest
• Claim Description: Digest of the EAR Appraisal Request Input
• JWT Claim Name: ear_input_digest
• Claim Key: 1008 (suggested)
• Claim Value Type(s): array
• Change Controller: IESG
• Specification Document(s): of RFCthis

EAR TEEP Claims TODO

References Normative References JSON Web Token (JWT) is a compact, URL-safe means of representing claims to be transferred between two parties. The claims in a JWT are encoded as a JSON object that is used as the payload of a JSON Web Signature (JWS) structure or as the plaintext of a JSON Web Encryption (JWE) structure, enabling the claims to be digitally signed or integrity protected with a Message Authentication Code (MAC) and/or encrypted. CBOR Web Token (CWT) is a compact means of representing claims to be transferred between two parties. The claims in a CWT are encoded in the Concise Binary Object Representation (CBOR), and CBOR Object Signing and Encryption (COSE) is used for added application-layer security protection. A claim is a piece of information asserted about a subject and is represented as a name/value pair consisting of a claim name and a claim value. CWT is derived from JSON Web Token (JWT) but uses CBOR rather than JSON. This document proposes a notational convention to express Concise Binary Object Representation (CBOR) data structures (RFC 7049). Its main goal is to provide an easy and unambiguous way to express structures for protocol messages and data formats that use CBOR or JSON. This memo profiles the X.509 v3 certificate and X.509 v2 certificate revocation list (CRL) for use in the Internet. An overview of this approach and model is provided as an introduction. The X.509 v3 certificate format is described in detail, with additional information regarding the format and semantics of Internet name forms. Standard certificate extensions are described and two Internet-specific extensions are defined. A set of required certificate extensions is specified. The X.509 v2 CRL format is described in detail along with standard and Internet-specific extensions. An algorithm for X.509 certification path validation is described. An ASN.1 module and examples are provided in the appendices. [STANDARDS-TRACK] The Concise Binary Object Representation (CBOR) is a data format whose design goals include the possibility of extremely small code size, fairly small message size, and extensibility without the need for version negotiation. These design goals make it different from earlier binary serializations such as ASN.1 and MessagePack. This document obsoletes RFC 7049, providing editorial improvements, new details, and errata fixes while keeping full compatibility with the interchange format of RFC 7049. It does not create a new version of the format. Concise Binary Object Representation (CBOR) is a data format designed for small code size and small message size. There is a need to be able to define basic security services for this data format. This document defines the CBOR Object Signing and Encryption (COSE) protocol. This specification describes how to create and process signatures, message authentication codes, and encryption using CBOR for serialization. This specification additionally describes how to represent cryptographic keys using CBOR. This document, along with RFC 9053, obsoletes RFC 8152. Cisco Systems Fraunhofer SIT MIT NVIDIA Intel This document defines reusable Attestation Result information elements. When these elements are offered to Relying Parties as Evidence, different aspects of Attester trustworthiness can be evaluated. Additionally, where the Relying Party is interfacing with a heterogeneous mix of Attesting Environment and Verifier types, consistent policies can be applied to subsequent information exchange between each Attester and the Relying Party. This document also defines two serialisations of the proposed information model, utilising CBOR and JSON. An Entity Attestation Token (EAT) provides an attested claims set that describes the state and characteristics of an entity, a device such as a smartphone, an Internet of Things (IoT) device, network equipment, or such. This claims set is used by a relying party, server, or service to determine the type and degree of trust placed in the entity. An EAT is either a CBOR Web Token (CWT) or a JSON Web Token (JWT) with attestation-oriented claims. University of Applied Sciences Bonn-Rhein-Sieg Broadcom Amazon Microsoft Openchip & Software Technologies, S.L. This document specifies the Trusted Execution Environment Provisioning (TEEP) Protocol, which enables secure lifecycle management of Trusted Components in devices with a Trusted Execution Environment (TEE). The protocol defines message exchanges between a Trusted Application Manager (TAM) and a TEEP Agent to query device state, convey attestation evidence, and install, update, or delete Trusted Components. Messages are encoded in CBOR and secured using COSE. The payloads used in Remote ATtestation procedureS (RATS) may require an associated media type for their conveyance, for example, when the payloads are used in RESTful APIs. This memo defines media types to be used for Entity Attestation Tokens (EATs). The conceptual messages introduced by the Remote ATtestation procedureS (RATS) architecture (RFC 9334) are protocol-agnostic data units that are conveyed between RATS roles during RATS interactions. Conceptual messages describe the meaning and function of such data units within RATS data flows without specifying a wire format, encoding, transport mechanism, or processing details. The initial set of conceptual messages is defined in Section 8 of RFC 9334 and includes Evidence, Attestation Results, Endorsements, Reference Values, and Appraisal Policies. This document introduces the Conceptual Message Wrapper (CMW) that provides a common structure to encapsulate these messages. It defines a dedicated Concise Binary Object Representation (CBOR) tag, corresponding JSON Web Token (JWT) and CBOR Web Token (CWT) claims, and an X.509 extension. Together, these mechanisms allow CMWs to be used in CBOR-based protocols, web APIs using JWTs and CWTs, and PKIX artifacts such as X.509 certificates. Additionally, this document defines media types and CoAP Content-Formats that may be used to identify CMWs when transported over protocols such as HTTP, MIME, and CoAP. The goal is to improve the interoperability and flexibility of remote attestation protocols. Introducing a shared message format such as CMW enables consistent support for different attestation message types, enables the evolution of message serialization formats without breaking compatibility, and avoids the need to redefine how messages are handled within each protocol. Arm Linaro University of Applied Sciences Bonn-Rhein-Sieg Fraunhofer SIT The term "measured component" refers to an object within the attester's target environment whose state can be sampled and typically digested using a cryptographic hash function. Examples of measured components include firmware stored in flash memory, software loaded into memory at start time, data stored in a file system, or values in a CPU register. This document provides the information model for the "measured component" and two associated data models. This separation is intentional: the JSON and CBOR serializations, coupled with the media types and associated Constrained Application Protocol (CoAP) Content-Formats, enable the immediate use of the semantics within the Entity Attestation Token (EAT) framework. Meanwhile, the information model can be reused in future specifications to provide additional serializations, for example, using ASN.1. In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. Informative References This document discusses subsets of the Unicode character repertoire for use in protocols and data formats and specifies three subsets recommended for use in IETF specifications. In network protocol exchanges, it is often useful for one end of a communication to know whether the other end is in an intended operating state. This document provides an architectural overview of the entities involved that make such tests possible through the process of generating, conveying, and evaluating evidentiary Claims. It provides a model that is neutral toward processor architectures, the content of Claims, and protocols. Arm Ltd Huawei Technologies France S.A.S.U. Huawei Technologies France S.A.S.U. Fraunhofer SIT IETF RATS Architecture, defines the key role of a Verifier. In a complex system, this role needs to be performed by multiple Verifiers coordinating together to assess the full trustworthiness of an Attester. This document focuses on various topological patterns for a multiple Verifier system. It only covers the architectural aspects introduced by the Multi Verifier concept, which is neutral with regard to specific wire formats, encoding, transport mechanisms, or processing details. Fraunhofer SIT NVIDIA arm Independent Huawei Technologies Remote Attestation Procedures (RATS) enable Relying Parties to assess the trustworthiness of a remote Attester and therefore to decide whether or not to engage in secure interactions with it. Evidence about trustworthiness can be rather complex and it is deemed unrealistic that every Relying Party is capable of the appraisal of Evidence. Therefore that burden is typically offloaded to a Verifier. In order to conduct Evidence appraisal, a Verifier requires not only fresh Evidence from an Attester, but also trusted Endorsements and Reference Values from Endorsers and Reference Value Providers, such as manufacturers, distributors, or device owners. This document specifies the information elements for representing Endorsements and Reference Values in CBOR format. This document describes a simple process that allows authors of Internet-Drafts to record the status of known implementations by including an Implementation Status section. This will allow reviewers and working groups to assign due consideration to documents that have the benefit of running code, which may serve as evidence of valuable experimentation and feedback that have made the implemented protocols more mature. This process is not mandatory. Authors of Internet-Drafts are encouraged to consider using the process for their documents, and working groups are invited to think about applying the process to all of their protocol specifications. This document obsoletes RFC 6982, advancing it to a Best Current Practice. This document describes the "tag" Uniform Resource Identifier (URI) scheme. Tag URIs (also known as "tags") are designed to be unique across space and time while being tractable to humans. They are distinct from most other URIs in that they have no authoritative resolution mechanism. A tag may be used purely as an entity identifier. Furthermore, using tags has some advantages over the common practice of using "http" URIs as identifiers for non-HTTP-accessible resources. This memo provides information for the Internet community. IANA IANA

Collated CDDL "tag:ietf.org,2026:rats/ear#05", ? status-label => ar4si.trustworthiness-tier, ? status-details-label => details-type, eat.iat-claim-label => ~eat.time-int, ? eat.exp-claim-label => ~eat.time-int, verifier-id-label => ar4si.verifier-id, ? raw-evidence-label => cmw-record, eat.submods-label => {+ text => $submod-value}, ? eat.nonce-label => eat.nonce-type, ? topology-label => topology-type, ? input-digest-label => mc.digest, * $$ear-extension, } cmw-record = eat.JC $submod-value /= EAR-appraisal / EAR / eat.Nested-Token raw-evidence-label = eat.JC<"ear_raw_evidence", 1002> verifier-id-label = eat.JC<"ear_verifier_id", 1004> topology-label = eat.JC<"ear_device_topology", 1007> input-digest-label = eat.JC<"ear_input_digest", 1008> 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-claims-type = {+ text => claims-map-type} claims-map-type = eat.JC claims-map-type-json = {+ text => any} claims-map-type-cbor = {+ (text / int) => any} topology-type = {+ text => [+ text]} eat.JC = eat.JSON-ONLY / eat.CBOR-ONLY eat.JSON-ONLY = J .feature "json" eat.CBOR-ONLY = C .feature "cbor" ar4si.non-empty = M .within ({+ any => any}) ar4si.trustworthiness-tier /= ar4si.trustworthiness-tier-none-label \ / ar4si.trustworthiness-tier-affirming-label / ar4si.trustworthiness\ -tier-warning-label / ar4si.trustworthiness-tier-contraindicated-\ label / ar4si.trustworthiness-tier-incomplete-label ar4si.verifier-id = { ar4si.developer-label => text, ar4si.build-label => text, } ar4si.trustworthiness-vector = ar4si.non-empty<{ ? ar4si.instance-identity-label => ar4si.trustworthiness-claim, ? ar4si.configuration-label => ar4si.trustworthiness-claim, ? ar4si.executables-label => ar4si.trustworthiness-claim, ? ar4si.file-system-label => ar4si.trustworthiness-claim, ? ar4si.hardware-label => ar4si.trustworthiness-claim, ? ar4si.runtime-opaque-label => ar4si.trustworthiness-claim, ? ar4si.storage-opaque-label => ar4si.trustworthiness-claim, ? ar4si.sourced-data-label => ar4si.trustworthiness-claim, }> ar4si.instance-identity-label = ar4si.JC<"instance-identity", 0> ar4si.configuration-label = ar4si.JC<"configuration", 1> ar4si.executables-label = ar4si.JC<"executables", 2> ar4si.file-system-label = ar4si.JC<"file-system", 3> ar4si.hardware-label = ar4si.JC<"hardware", 4> ar4si.runtime-opaque-label = ar4si.JC<"runtime-opaque", 5> ar4si.storage-opaque-label = ar4si.JC<"storage-opaque", 6> ar4si.sourced-data-label = ar4si.JC<"sourced-data", 7> ar4si.JC = ar4si.JSON-ONLY / ar4si.CBOR-ONLY ar4si.JSON-ONLY = J .feature "json" ar4si.CBOR-ONLY = C .feature "cbor" ar4si.trustworthiness-tier-none-label = ar4si.JC<"none", 0> ar4si.trustworthiness-tier-affirming-label = ar4si.JC<"affirming", 2> ar4si.trustworthiness-tier-warning-label = ar4si.JC<"warning", 32> ar4si.trustworthiness-tier-contraindicated-label = ar4si.JC<"\ contraindicated", 96> ar4si.trustworthiness-tier-incomplete-label = ar4si.JC<"incomplete"\ , 127> ar4si.developer-label = ar4si.JC<"developer", 0> ar4si.build-label = ar4si.JC<"build", 1> ar4si.trustworthiness-claim = -128 .. 127 cmw.json-record = [ type: cmw.media-type, value: cmw.base64url-string, ? ind: uint .bits cmw.cm-type, ] cmw.cbor-record = [ type: cmw.coap-content-format-type / cmw.media-type, value: bytes, ? ind: uint .bits cmw.cm-type, ] cmw.media-type = text .abnf ("Content-Type" .cat cmw.Content-Type-\ ABNF) cmw.base64url-string = text .regexp "[A-Za-z0-9_-]+" cmw.cm-type = &( reference-values: 0, endorsements: 1, evidence: 2, attestation-results: 3, appraisal-policy: 4, ) cmw.coap-content-format-type = uint .size 2 cmw.Content-Type-ABNF = ' Content-Type = Media-Type-Name *( *SP ";" *SP parameter ) parameter = token "=" ( token / quoted-string ) token = 1*tchar tchar = "!" / "#" / "$" / "%" / "&" / "\'" / "*" / "+" / "-" / "." / "^" / "_" / "`" / "|" / "~" / DIGIT / ALPHA quoted-string = %x22 *( qdtext / quoted-pair ) %x22 qdtext = SP / %x21 / %x23-5B / %x5D-7E quoted-pair = "\\" ( SP / VCHAR ) Media-Type-Name = type-name "/" subtype-name type-name = restricted-name subtype-name = restricted-name restricted-name = restricted-name-first *126restricted-name-chars restricted-name-first = ALPHA / DIGIT restricted-name-chars = ALPHA / DIGIT / "!" / "#" / "$" / "&" / "-" / "^" / "_" restricted-name-chars =/ "." ; Characters before first dot always ; specify a facet name restricted-name-chars =/ "+" ; Characters after last plus always ; specify a structured syntax suffix DIGIT = %x30-39 ; 0 - 9 POS-DIGIT = %x31-39 ; 1 - 9 ALPHA = %x41-5A / %x61-7A ; A - Z / a - z SP = %x20 VCHAR = %x21-7E ; printable ASCII (no SP) ' mc.digest = [ alg: int / text, val: mc.digest-value-type, ] mc.digest-value-type = mc.eat.JC mc.eat.JC = mc.eat.JSON-ONLY / mc.eat.CBOR-ONLY mc.eat.JSON-ONLY = J .feature "json" mc.eat.CBOR-ONLY = C .feature "cbor" mc.bytes-b64u = text .b64u bytes eat.profile-label = eat.JC<"eat_profile", 265> eat.iat-claim-label = eat.JC<"iat", 6> eat.time-int = #6.1(int) eat.exp-claim-label = eat.JC<"exp", 4> eat.submods-label = eat.JC<"submods", 266> eat.nonce-label = eat.JC<"eat_nonce", 10> eat.nonce-type = eat.JC eat.Nested-Token = eat.CBOR-Nested-Token / eat.JSON-Selector eat.general-uri = eat.JC eat.general-oid = eat.JC eat.CBOR-Nested-Token = eat.JSON-Token-Inside-CBOR-Token / eat.CBOR-\ Token-Inside-CBOR-Token eat.JSON-Selector = eat.$JSON-Selector eat.json-oid = tstr .regexp "([0-2])((\\.0)|(\\.[1-9][0-9]*))*" eat.oid = #6.111(bstr) eat.JSON-Token-Inside-CBOR-Token = tstr eat.CBOR-Token-Inside-CBOR-Token = bstr .cbor eat.$CBOR-Tagged-Token eat.$JSON-Selector /= [ type: "JWT", nested-token: eat.JWT-Message, ] / [ type: "CBOR", nested-token: eat.CBOR-Token-Inside-JSON-Token, ] eat.$CBOR-Tagged-Token /= #6.61(bstr) / #6.18(bstr) / #6.17(bstr) / \ #6.16(bstr) eat.JWT-Message = tstr .regexp "[A-Za-z0-9_-]+\\.[A-Za-z0-9_-]+\\.[A\ -Za-z0-9_-]*" eat.CBOR-Token-Inside-JSON-Token = eat.base64-url-text eat.base64-url-text = tstr .regexp "[A-Za-z0-9_-]+" ]]>

Open Policy Agent Example Open Policy Agent OPA is a popular and flexible policy engine that is used in a variety of contexts, from cloud to IoT. OPA policies are written using a purpose-built, declarative programming language called Rego. Rego has been designed to handle JSON claim-sets and their JWT envelopes as first class objects, which makes it an excellent fit for dealing with JWT EARs. The following example illustrates an OPA policy that a Relying Party would use to make decisions based on a JWT EAR received from a trusted verifier. The result of the policy appraisal is the following JSON object: For completeness, the trusted verifier public key and the EAR JWT used in the example are provided below.

Open Issues Note to RFC Editor: please remove before publication. The list of currently open issues for this document can be found at .

Acknowledgments Many thanks to Dave Thaler, Dhawal Kumar, Ding Ma, Greg Kostal, Jerry Yu, Raghuram Yeluri, Simon Frost, Tobin Feldman-Fitzthum, Yogesh Deshpande for helpful comments and discussions that have shaped this document.