



WIMSE                                                             D. Liu
Internet-Draft                                                    H. Zhu
Intended status: Standards Track                                  J. Jin
Expires: 26 September 2026                                 Alibaba Group
                                                           25 March 2026


 Carrying Remote Attestation Evidence in Workload Identity Tokens (WIT)
                   draft-liu-wimse-wit-attestation-00

Abstract

   This document specifies how Remote Attestation evidence, as defined
   by the IETF RATS architecture, can be conveyed within a Workload
   Identity Token (WIT) as used in the WIMSE (Workload Identity for
   Micro-Services Environments) framework.  The WIT includes attestation
   measurements that enable fast-path policy evaluation without
   requiring immediate access to full evidence.  The WIT is bound to the
   HTTP request using OAuth 2.0 Demonstrating Proof-of-Possession
   (DPoP), ensuring that attestation claims are protected against replay
   and token theft.

   This specification defines a two-tier verification model: lightweight
   verification using embedded measurements for common scenarios, and
   deep verification using externalized evidence for high-assurance
   requirements.  This enables secure, cross-domain verification of
   workload integrity without requiring direct access to platform-
   specific reference values, while enabling efficient deployments.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at https://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on 26 September 2026.






Liu, et al.             Expires 26 September 2026               [Page 1]

Internet-Draft   Carrying Remote Attestation Evidence in      March 2026


Copyright Notice

   Copyright (c) 2026 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents (https://trustee.ietf.org/
   license-info) in effect on the date of publication of this document.
   Please review these documents carefully, as they describe your rights
   and restrictions with respect to this document.  Code Components
   extracted from this document must include Revised BSD License text as
   described in Section 4.e of the Trust Legal Provisions and are
   provided without warranty as described in the Revised BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
   2.  Conventions and Terminology . . . . . . . . . . . . . . . . .   3
   3.  Attestation Claims in the WIT . . . . . . . . . . . . . . . .   3
     3.1.  attested_environment  . . . . . . . . . . . . . . . . . .   4
     3.2.  tee_type  . . . . . . . . . . . . . . . . . . . . . . . .   4
     3.3.  measurements  . . . . . . . . . . . . . . . . . . . . . .   4
     3.4.  evidence_ref  . . . . . . . . . . . . . . . . . . . . . .   5
     3.5.  TEE-Specific Measurement Formats  . . . . . . . . . . . .   6
       3.5.1.  Intel TDX Measurements  . . . . . . . . . . . . . . .   6
       3.5.2.  AMD SEV-SNP Measurements  . . . . . . . . . . . . . .   6
       3.5.3.  Intel SGX Measurements  . . . . . . . . . . . . . . .   7
       3.5.4.  Extensibility . . . . . . . . . . . . . . . . . . . .   7
     3.6.  Example WIT with Measurements . . . . . . . . . . . . . .   7
   4.  Integration with OAuth 2.0 DPoP . . . . . . . . . . . . . . .   8
   5.  Cross-Domain Attestation Workflow . . . . . . . . . . . . . .   9
   6.  Security Considerations . . . . . . . . . . . . . . . . . . .  11
     6.1.  Threat Model  . . . . . . . . . . . . . . . . . . . . . .  11
     6.2.  Security Properties . . . . . . . . . . . . . . . . . . .  12
   7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  14
     7.1.  JSON Web Token Claims Registration  . . . . . . . . . . .  14
     7.2.  WIMSE TEE Types Registry  . . . . . . . . . . . . . . . .  15
       7.2.1.  Registration Procedure  . . . . . . . . . . . . . . .  15
       7.2.2.  Initial Registry Contents . . . . . . . . . . . . . .  15
   8.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  16
     8.1.  Normative References  . . . . . . . . . . . . . . . . . .  16
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  17









Liu, et al.             Expires 26 September 2026               [Page 2]

Internet-Draft   Carrying Remote Attestation Evidence in      March 2026


1.  Introduction

   In some scenarios of the security-sensitive environments, workloads
   need to prove not only their identity but also the integrity of their
   execution environment.  The WIMSE framework defines the Workload
   Identity Token (WIT) for conveying identity between workloads.
   However, to support confidential computing and remote attestation
   across administrative domains (e.g., multi-cloud), the WIT need to
   carry verifiable attestation evidence.

   This document extends the WIT specification by defining standard
   claims for attestation and specifying their integration with WIMSE
   and the RATS architecture [RFC9334].

2.  Conventions and Terminology

   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 [RFC2119] [RFC8174] when, and only when, they appear in all
   capitals.

   This document uses terms from the RATS architecture [RFC9334],
   including "Evidence", "Endorsement", and "Reference Value".  It also
   assumes familiarity with WIMSE [I-D.ietf-wimse-s2s-protocol] and
   OAuth 2.0 DPoP [RFC9449].

3.  Attestation Claims in the WIT

   A WIT conveying attestation information MUST include the claims
   defined in this section.  When attested_environment is true, the
   measurements claim MUST be present to enable fast-path policy
   evaluation.  All attestation claims MUST be protected by the WIT's
   digital signature and bound to the request via DPoP.  The WIT
   implementation follows the JWT Best Current Practices [RFC8725].

   This specification defines a two-tier verification model:

   *  *Fast Path*: Relying parties evaluate embedded measurements
      against local policy without fetching external evidence.  This
      covers the majority of requests with sub-millisecond latency.

   *  *Deep Path*: For high-assurance scenarios, relying parties
      retrieve full evidence via evidence_ref and perform cryptographic
      verification of the complete attestation chain.






Liu, et al.             Expires 26 September 2026               [Page 3]

Internet-Draft   Carrying Remote Attestation Evidence in      March 2026


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



Liu, et al.             Expires 26 September 2026               [Page 4]

Internet-Draft   Carrying Remote Attestation Evidence in      March 2026


      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.





Liu, et al.             Expires 26 September 2026               [Page 5]

Internet-Draft   Carrying Remote Attestation Evidence in      March 2026


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.

3.5.1.  Intel TDX Measurements

   For tee_type="intel-tdx", the measurements type MUST be "tdx-rtmr"
   and the registers object MUST contain Runtime Measurement Registers
   (RTMRs):

   {
     "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..."
   }

                                  Figure 1

   RTMR semantics:

   *  rtmr0: Initial boot measurements (BIOS, bootloader)

   *  rtmr1: OS loader and kernel measurements

   *  rtmr2: System configuration measurements

   *  rtmr3: Application and runtime measurements

   All RTMR values MUST be hex-encoded SHA-384 hashes (96 hex
   characters).  The summary field SHOULD be the SHA-384 hash of the
   concatenation of rtmr0||rtmr1||rtmr2||rtmr3.

3.5.2.  AMD SEV-SNP Measurements

   The measurement format for tee_type="amd-sev-snp" is TBD.  Future
   versions of this specification will define the snp-pcr format
   including vTPM PCR values and SNP-specific launch measurements.






Liu, et al.             Expires 26 September 2026               [Page 6]

Internet-Draft   Carrying Remote Attestation Evidence in      March 2026


3.5.3.  Intel SGX Measurements

   The measurement format for tee_type="intel-sgx" is TBD.  Future
   versions of this specification will define the sgx-mr format
   including MRENCLAVE and MRSIGNER values.

3.5.4.  Extensibility

   New TEE types can be supported by defining a new measurement type and
   corresponding registers structure.  Implementations encountering an
   unknown type value MUST either reject the WIT or fall back to
   evidence_ref verification if present.

   To register a new TEE type and measurement format, follow the IANA
   registration process defined in Section 7.2.  The registration MUST
   include:

   *  TEE type identifier (e.g., "arm-cca")

   *  Measurement type identifier (e.g., "cca-rim")

   *  Hash algorithm(s) used

   *  Detailed specification of the registers structure

   *  Semantics of each register field

   *  Reference to authoritative TEE specification

3.6.  Example WIT with Measurements

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


















Liu, et al.             Expires 26 September 2026               [Page 7]

Internet-Draft   Carrying Remote Attestation Evidence in      March 2026


{
  "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"
}

        Figure 2: Example WIT Payload with Attestation Claims

   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.

4.  Integration with OAuth 2.0 DPoP

   As required by [I-D.ietf-wimse-s2s-protocol], the WIT MUST be bound
   to the HTTP request using OAuth 2.0 DPoP [RFC9449].

   Note that the DPoP proof binds to the exact WIT string via the "ath"
   claim, which contains the SHA-256 hash of the WIT presented in the
   Workload-Identity-Token header, ensuring that the attestation claims
   cannot be substituted or replayed.



Liu, et al.             Expires 26 September 2026               [Page 8]

Internet-Draft   Carrying Remote Attestation Evidence in      March 2026


   The DPoP private key is assumed to be securely held by the workload;
   this specification does not define how the relying party verifies
   that the DPoP key was generated within the attested TEE.  This
   verification is delegated to the WIT issuer, which validates the TEE
   evidence before issuing the WIT.

   POST /api/data HTTP/1.1
   Host: service-b.example
   Workload-Identity-Token: eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCJ9.xxxxx
   DPoP: eyJhbGciOiJFUzM4NCIsInR5cCI6ImRwb3AifQ.yyyyy

                   Figure 3: Example HTTP Request Headers

5.  Cross-Domain Attestation Workflow

   The following diagram illustrates how a workload in Domain A (e.g.,
   Cloud Provider X) authenticates to a service in Domain B (e.g., Cloud
   Provider Y) using a WIT that carries attestation measurements.  The
   two-tier verification model enables both fast-path policy evaluation
   and optional deep verification, with DPoP ensuring request binding
   and replay protection.






























Liu, et al.             Expires 26 September 2026               [Page 9]

Internet-Draft   Carrying Remote Attestation Evidence in      March 2026


   +----------------+       +----------------+       +----------------+
   |   Workload A   |       |   Service B    |       | Attestation    |
   | (Domain A)     |       | (Domain B)     |       | Verifier /     |
   |                |       |                |       | Policy Engine  |
   +----------------+       +----------------+       +----------------+
           |                         |                         |
           | 1. Generate WIT with    |                         |
           |    attestation claims   |                         |
           |    (e.g., tee_type,     |                         |
           |     attested_environment)|                        |
           |------------------------>|                         |
           | 2. Create DPoP proof    |                         |
           |    bound to WIT (ath)   |                         |
           |    and HTTP request     |                         |
           |------------------------>|                         |
           |                         | 3. Validate DPoP:       |
           |                         |    - Signature          |
           |                         |    - htu/htm match      |
           |                         |    - jti not replayed   |
           |                         |    - ath == hash(WIT)   |
           |                         |------------------------>|
           |                         | 4. Fetch Evidence (if   |
           |                         |    evidence_ref present)|
           |                         |<------------------------|
           |                         | 5. Evaluate attestation |
           |                         |    against local policy |
           |                         | (e.g., "only intel-tdx")|
           |                         |                         |
           |<------------------------| 6. Accept or reject     |
           |    Request              |    based on result      |
           |                         |                         |
           +-------------------------+-------------------------+

            Figure 4: Cross-Domain WIT + Attestation + DPoP Flow

   Steps in detail:

   1.  *WIT Generation*: Workload A constructs a WIT containing identity
       (e.g., SPIFFE ID) and attestation claims (attested_environment,
       tee_type, measurements, optionally evidence_ref).  The
       measurements claim contains TEE-specific register values that
       enable fast policy evaluation.

   2.  *DPoP Binding*: Workload A generates a DPoP proof that includes
       the SHA-256 hash of the WIT in the ath claim, along with the HTTP
       method (htm) and URL (htu).  This binds the attestation
       measurements to this specific request.




Liu, et al.             Expires 26 September 2026              [Page 10]

Internet-Draft   Carrying Remote Attestation Evidence in      March 2026


   3.  *Request Transmission*: The client sends an HTTP request with
       both Workload-Identity-Token and DPoP headers.

   4.  *DPoP Validation*: Service B validates the DPoP proof per
       [RFC9449], ensuring the WIT is bound to this specific request and
       has not been replayed.

   5.  *Fast-Path Verification*: Service B extracts the measurements
       claim from the WIT and evaluates it against local policy.  For
       most requests, this step is sufficient and completes efficiently.
       Examples include checking if tee_type matches policy, comparing
       measurements.summary against known-good values, verifying
       specific registers match approved configurations, and checking if
       measurements are in a revocation list.  If the measurements
       satisfy policy, Service B grants access immediately.

   6.  *Deep-Path Verification* (optional): For high-assurance scenarios
       or when fast-path policy is inconclusive, Service B MAY fetch the
       full RATS Evidence from evidence_ref (over TLS) and perform
       cryptographic verification of the complete attestation chain.
       This includes validating the TEE hardware signature, verifying
       the certificate chain to root-of-trust, checking TCB (Trusted
       Computing Base) status, and validating measurements match the
       evidence.  Service B MAY cache the evidence verification result
       to avoid repeated fetches for subsequent requests from the same
       workload.

   7.  *Policy Evaluation*: Service B's policy engine makes the final
       authorization decision based on the verification tier used.  The
       policy may specify different requirements based on operation
       sensitivity (e.g., read vs.  write operations).

   *Access Decision*: Based on the evaluation, Service B grants or
   denies access.  The verification tier used (fast-path vs. deep-path)
   MAY be logged for audit purposes.

   Note that no direct trust relationship between the TEE attestation
   root (e.g., Intel TDX root key) and Domain B is required.  Instead,
   Domain B relies on its configured policy about which TEE types it
   accepts.

6.  Security Considerations

6.1.  Threat Model

   This specification assumes the following trust model and threat
   environment:




Liu, et al.             Expires 26 September 2026              [Page 11]

Internet-Draft   Carrying Remote Attestation Evidence in      March 2026


   *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,





Liu, et al.             Expires 26 September 2026              [Page 12]

Internet-Draft   Carrying Remote Attestation Evidence in      March 2026


      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-





Liu, et al.             Expires 26 September 2026              [Page 13]

Internet-Draft   Carrying Remote Attestation Evidence in      March 2026


      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.  IANA Considerations

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







Liu, et al.             Expires 26 September 2026              [Page 14]

Internet-Draft   Carrying Remote Attestation Evidence in      March 2026


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.

7.2.1.  Registration Procedure

   Registration of new TEE type values follows the "Specification
   Required" policy as defined in [RFC8126].  The designated experts are
   appointed by the IETF Security Area Directors.  The designated expert
   SHALL verify that:

   *  The TEE type is documented in a publicly accessible specification

   *  The corresponding measurement format is clearly defined

   *  The TEE type identifier follows the naming convention (lowercase
      ASCII, hyphen-separated, e.g., "vendor-product")

   *  The registration does not duplicate an existing entry

   *  The specification defines security considerations specific to the
      TEE type

   In case of dispute or disagreement with the designated expert's
   decision, the registrant may appeal to the IETF Security Area
   Directors.

   The registration template consists of the following fields:

   TEE Type:  The requested identifier (e.g., "intel-tdx")

   Description:  A brief description of the Trusted Execution
      Environment

   Measurement Type:  The corresponding measurement format identifier

   Reference:  URI to the specification document

   Change Controller:  The entity responsible for the registration
      (e.g., "IETF" or organization name)

7.2.2.  Initial Registry Contents

   The initial registry contains the following entries:




Liu, et al.             Expires 26 September 2026              [Page 15]

Internet-Draft   Carrying Remote Attestation Evidence in      March 2026


   +=============+======================+=============+===============+
   | TEE Type    | Description          | Measurement | Reference     |
   |             |                      | Type        |               |
   +=============+======================+=============+===============+
   | intel-tdx   | Intel Trust Domain   | tdx-rtmr    | [[THIS        |
   |             | Extensions           |             | DOCUMENT]],   |
   |             |                      |             | Section 3.5.1 |
   +-------------+----------------------+-------------+---------------+
   | amd-sev-snp | AMD Secure Encrypted | TBD         | [[THIS        |
   |             | Virtualization - SNP |             | DOCUMENT]],   |
   |             |                      |             | Section 3.5.2 |
   +-------------+----------------------+-------------+---------------+
   | intel-sgx   | Intel Software Guard | TBD         | [[THIS        |
   |             | Extensions           |             | DOCUMENT]],   |
   |             |                      |             | Section 3.5.3 |
   +-------------+----------------------+-------------+---------------+
   | arm-cca     | ARM Confidential     | TBD         | TBD           |
   |             | Compute Architecture |             |               |
   +-------------+----------------------+-------------+---------------+

                                 Table 1

8.  References

8.1.  Normative References

   [I-D.ietf-wimse-s2s-protocol]
              Authors, W., "Service-to-Service Authentication Using
              Workload Identity", Work in Progress, Internet-Draft,
              draft-ietf-wimse-s2s-protocol-07, 2024,
              <https://datatracker.ietf.org/doc/html/draft-ietf-wimse-
              s2s-protocol-07>.

   [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/info/rfc2119>.

   [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/info/rfc7519>.

   [RFC8126]  Cotton, M., Leiba, B., and T. Narten, "Guidelines for
              Writing an IANA Considerations Section in RFCs", BCP 26,
              RFC 8126, DOI 10.17487/RFC8126, June 2017,
              <https://www.rfc-editor.org/info/rfc8126>.





Liu, et al.             Expires 26 September 2026              [Page 16]

Internet-Draft   Carrying Remote Attestation Evidence in      March 2026


   [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/info/rfc8174>.

   [RFC8725]  Sheffer, Y., Hardt, D., and M. Jones, "JSON Web Token Best
              Current Practices", BCP 225, RFC 8725,
              DOI 10.17487/RFC8725, February 2020,
              <https://www.rfc-editor.org/info/rfc8725>.

   [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/info/rfc9334>.

   [RFC9449]  Fett, D., Campbell, B., Bradley, J., Lodderstedt, T.,
              Jones, M., and D. Waite, "OAuth 2.0 Demonstrating Proof of
              Possession (DPoP)", RFC 9449, DOI 10.17487/RFC9449,
              September 2023, <https://www.rfc-editor.org/info/rfc9449>.

Authors' Addresses

   Dapeng Liu
   Alibaba Group
   Email: max.ldp@alibaba-inc.com


   Hongru Zhu
   Alibaba Group
   Email: hongru.zhr@alibaba-inc.com


   Jian Jin
   Alibaba Group
   Email: jinjian.jj@alibaba-inc.com

















Liu, et al.             Expires 26 September 2026              [Page 17]
