Carrying Remote Attestation Evidence in Workload Identity Tokens (WIT)

3.1. attested_environment

The "attested_environment" claim is a REQUIRED boolean value indicating whether the workload is running in an environment capable of producing valid remote attestation evidence.¶

If true, the measurements claim MUST be present, and the verifier SHOULD evaluate the measurements against its local policy. If false or absent, no attestation verification is performed.¶

3.2. tee_type

The "tee_type" claim is a REQUIRED string (when attested_environment is true) identifying the type of Trusted Execution Environment (TEE). This value determines the format of the measurements claim. Registered values include:¶

• "intel-tdx" - Intel Trust Domain Extensions¶
• "amd-sev-snp" - AMD Secure Encrypted Virtualization - Secure Nested Paging¶
• "intel-sgx" - Intel Software Guard Extensions¶
• "arm-cca" - ARM Confidential Compute Architecture¶

This value enables policy-based decisions (e.g., "only accept intel-tdx") and determines how the verifier interprets the measurements claim.¶

New TEE types MAY be registered through the IANA registry defined in Section 7.2.¶

3.3. measurements

The "measurements" claim is REQUIRED when attested_environment is true. It contains a summary of key attestation measurements that enable fast-path policy evaluation without retrieving full evidence. The measurements object provides sufficient information for relying parties to make authorization decisions for common scenarios.¶

The measurements object MUST contain the following members:¶

type:

REQUIRED string identifying the measurement format. This value MUST correspond to the tee_type claim. Valid values are defined in Section 3.5.¶

algorithm:

REQUIRED lowercase string specifying the hash algorithm used for measurements. Valid values are "sha256", "sha384", and "sha512". These identifiers correspond to the IANA Hash Function Textual Names registry. Implementations MUST support "sha384" for TEE measurements; other algorithms MAY be used if specified by the TEE type definition.¶

registers:

REQUIRED object containing TEE-specific measurement registers. The structure of this object depends on the type field and is defined in Section 3.5.¶

summary:

OPTIONAL string containing a hash of all measurements for quick comparison. Format: "algorithm:hex_value" where algorithm is a hash algorithm identifier (e.g., "sha384") and hex_value is the lowercase hexadecimal representation without the "0x" prefix (e.g., "sha384:abc123..."). The algorithm identifier SHOULD match the algorithm used in the measurements claim.¶

Verifiers MUST validate that the type field matches the tee_type claim. Verifiers MAY use the summary field for fast comparison against known-good values before inspecting individual registers.¶

3.4. evidence_ref

The "evidence_ref" claim is an OPTIONAL URI pointing to a resource that contains the full RATS Evidence (e.g., in CWT or EAT format). The resource MUST be accessible over HTTPS with TLS 1.2 or higher, and verifiers MUST validate the server certificate according to their trust policy.¶

This claim enables the deep-path verification tier. When present, relying parties MAY retrieve the full evidence for cryptographic verification of the complete attestation chain. This is RECOMMENDED for high-assurance scenarios or when local policy requires validation beyond the measurements claim.¶

Example: https://kbs.customer.example/evidence/abc123¶

The evidence resource MAY be hosted by a customer-operated Key Broker Service (KBS) or cloud provider attestation service. Verifiers MUST authenticate the evidence source and validate signatures according to their trust policy.¶

Alternatively, full Evidence MAY be embedded directly as a separate claim (e.g., evidence_cwt), but this is NOT RECOMMENDED due to size constraints in HTTP headers. The measurements + evidence_ref approach provides better performance and scalability.¶

3.5. TEE-Specific Measurement Formats

This section defines the structure of the registers object for each supported TEE type. Implementations MUST follow these formats when generating or validating measurements claims.¶

{
  "type": "tdx-rtmr",
  "algorithm": "sha384",
  "registers": {
    "rtmr0": "hex_encoded_48_bytes",
    "rtmr1": "hex_encoded_48_bytes",
    "rtmr2": "hex_encoded_48_bytes",
    "rtmr3": "hex_encoded_48_bytes"
  },
  "summary": "sha384:abc123..."
}

3.6. Example WIT with Measurements

The following figure shows a complete example of a WIT payload containing attestation measurements:¶

{
  "sub": "spiffe://example.com/ns/default/sa/workload-a",
  "iss": "https://wimse-ca.example.com",
  "iat": 1700000000,
  "exp": 1700003600,
  "jti": "a1b2c3d4-e5f6-7890-g1h2-i3j4k5l6m7n8",

  "attested_environment": true,
  "tee_type": "intel-tdx",

  "measurements": {
    "type": "tdx-rtmr",
    "algorithm": "sha384",
    "registers": {
      "rtmr0": "a1b2c3d4e5f6789012345678901234567890abcdef1234567890abcdef123456789012345678901234567890abcd",
      "rtmr1": "f1e2d3c4b5a67890123456789012345678901234567890abcdef1234567890abcdef123456789012345678abcd",
      "rtmr2": "1a2b3c4d5e6f78901234567890123456789012345678901234567890abcdef1234567890abcdef1234567890ab",
      "rtmr3": "9f8e7d6c5b4a321098765432109876543210fedcba9876543210fedcba9876543210fedcba987654321098ab"
    },
    "summary": "sha384:2f5d8c9e1a3b7f4e6d8c2a1b9e7f3d5c8a4b6e1f9d3c7a5b2e8f4d1c6a9b3e7f"
  },

  "evidence_ref": "https://kbs.customer.example/evidence/tdx/abcd1234"
}

This JSON represents the payload (claims set) of a signed WIT JWT. The attestation claims (attested_environment, tee_type, measurements, evidence_ref) are standard top-level members of the JWT payload. The measurements enable fast-path policy evaluation, while evidence_ref provides access to full attestation evidence for deep verification when required.¶

The entire WIT is base64url-encoded and signed (e.g., using RS256), forming the token transmitted in the Workload-Identity-Token header. A typical WIT with embedded measurements is approximately 800-1200 bytes when encoded, suitable for HTTP headers.¶

6.1. Threat Model

This specification assumes the following trust model and threat environment:¶

Trust Assumptions:¶

• The WIT issuer (e.g., workload identity provider) is trusted to correctly issue tokens and validate the TEE attestation evidence before inclusion in the WIT. The relying party trusts that the issuer has performed this verification correctly; this specification does not define mechanisms for cryptographically binding the DPoP key to the TEE measurements.¶
• The TEE hardware root of trust is assumed to be uncompromised for the specific TEE types accepted by the relying party.¶
• The relying party maintains a secure policy configuration that defines acceptable TEE types and measurement values.¶

Future versions of this specification may define mechanisms for cryptographically binding the DPoP key to the TEE measurements, enabling relying parties to verify this binding independently of the issuer.¶

Attacker Model:¶

• Network attacker: Can intercept, modify, or replay network traffic between workloads, but does not possess valid WITs or DPoP keys.¶
• Compromised workload: A workload running outside a TEE attempting to present falsified attestation claims.¶
• Malicious relying party: A service that attempts to harvest or replay attestation evidence for other purposes (mitigated by DPoP binding).¶

Out of Scope: This specification does not address attacks against the TEE hardware itself (e.g., side-channel attacks, physical attacks), nor does it address compromise of the WIT issuer's signing keys. Protection against such threats requires additional operational and architectural measures outside the scope of this document.¶

6.2. Security Properties

The following security considerations apply to implementations of this specification:¶

Replay Protection:

DPoP's use of jti and request binding (htm, htu, ath) prevents replay of WITs containing attestation measurements. The ath claim cryptographically binds the measurements to this specific request, preventing an attacker from reusing measurements from a compromised token.¶

Measurements Integrity:

The measurements claim MUST be protected by the WIT's digital signature. Verifiers MUST validate the WIT signature before trusting measurements. The measurements themselves are not sufficient for security without signature verification.¶

Fast-Path vs. Deep-Path Trade-offs:

Fast-path verification using measurements provides performance benefits but relies on local policy rather than cryptographic verification. Deployments MUST assess the risk level of each operation and choose the appropriate verification tier. High-value operations (e.g., financial transactions, sensitive data access) SHOULD use deep-path verification with evidence_ref.¶

Measurements Freshness:

Measurements represent the state of the workload at WIT issuance time. Verifiers SHOULD enforce short WIT lifetimes (exp claim) to ensure measurements remain fresh. For long-running operations, verifiers MAY require periodic re-attestation.¶

TEE-Specific Vulnerabilities:

Different TEE types have different security properties and known vulnerabilities. Verifiers MUST maintain up-to-date knowledge of TEE security status and update their policies accordingly. The measurements alone do not protect against vulnerabilities in the underlying TEE implementation.¶

Privacy:

Attestation measurements may reveal platform details (firmware versions, configuration, etc.). Deployments SHOULD minimize disclosed information. The measurements claim contains only essential values; full evidence via evidence_ref MAY contain more detailed information that should be protected accordingly.¶

Verifier Policy:

The relying party MUST validate attestation measurements against a well-defined local policy. Simply checking that measurements are present is insufficient. Policies SHOULD specify acceptable TEE types, approved measurement values or ranges, requirements for specific registers, and when deep-path verification is required. Trust in the WIT issuer (e.g., cloud provider CA) is assumed but MUST be explicitly configured.¶

Evidence Source Authentication:

When using evidence_ref for deep-path verification, verifiers MUST authenticate the evidence source and validate that it is authorized to provide evidence for the claimed TEE type. Customer-operated KBS deployments SHOULD use mTLS or equivalent authentication.¶

7.1. JSON Web Token Claims Registration

This document registers new claims in the "JSON Web Token Claims" registry established by [RFC7519].¶

Claim Name:

"attested_environment"¶

Claim Description:

Indicates attested execution environment¶

Change Controller:

IETF¶

Specification Document(s):

[[THIS DOCUMENT]], Section 3.1¶

Claim Name:

"tee_type"¶

Claim Description:

Identifies Trusted Execution Environment type¶

Change Controller:

IETF¶

Specification Document(s):

[[THIS DOCUMENT]], Section 3.2¶

Claim Name:

"measurements"¶

Claim Description:

Contains attestation measurements for fast verification¶

Change Controller:

IETF¶

Specification Document(s):

[[THIS DOCUMENT]], Section 3.3¶

Claim Name:

"evidence_ref"¶

Claim Description:

URI reference to full RATS Evidence¶

Change Controller:

IETF¶

Specification Document(s):

[[THIS DOCUMENT]], Section 3.4¶

7.2. WIMSE TEE Types Registry

IANA is requested to create a new registry titled "WIMSE WIT TEE Types" under the "WIMSE" namespace. This registry maintains identifiers for Trusted Execution Environment types used in the tee_type claim.¶