RATS Working Group M. Novak Internet-Draft J.P. Morgan Chase Intended status: Informational Y. Deshpande Expires: 9 May 2026 Arm H. Birkholz Franhaufer Inst. 5 November 2025 Remote Attestation for Trustworthy Workload Identity draft-novak-rats-twi-attestation-00 Abstract Trustworthy Workloads are workloads that operate in environments that provide isolation of data in use. This document describes how Trustworthy Workloads can acquire credentials containing stable identifiers, upon proving the trust in the environments in which they operate via Remote Attestation. About This Document This note is to be removed before publishing as an RFC. Status information for this document may be found at https://datatracker.ietf.org/doc/draft-novak-rats-twi-attestation/. Discussion of this document takes place on the RATS Working Group mailing list (mailto:rats@ietf.org), which is archived at https://mailarchive.ietf.org/arch/browse/rats/. Subscribe at https://www.ietf.org/mailman/listinfo/rats/. 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 9 May 2026. Novak, et al. Expires 9 May 2026 [Page 1] Internet-Draft RATS for TWI November 2025 Copyright Notice Copyright (c) 2025 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 . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Conventions and Definitions . . . . . . . . . . . . . . . . . 3 3. Available Options . . . . . . . . . . . . . . . . . . . . . . 4 3.1. Variant 1 . . . . . . . . . . . . . . . . . . . . . . . . 5 3.2. Variant 2 . . . . . . . . . . . . . . . . . . . . . . . . 6 3.3. Variant 3 . . . . . . . . . . . . . . . . . . . . . . . . 6 4. Claims Mapper . . . . . . . . . . . . . . . . . . . . . . . . 8 5. Credential Acquisition Mechanisms . . . . . . . . . . . . . . 8 5.1. Mechanism A . . . . . . . . . . . . . . . . . . . . . . . 10 5.2. Mechanism B . . . . . . . . . . . . . . . . . . . . . . . 11 5.3. Mechanism C . . . . . . . . . . . . . . . . . . . . . . . 12 5.4. Mechanisms D . . . . . . . . . . . . . . . . . . . . . . 14 5.4.1. Credential Provisioning Phase . . . . . . . . . . . . 14 5.4.2. Credential Acquisition Phase . . . . . . . . . . . . 16 6. Security Considerations . . . . . . . . . . . . . . . . . . . 17 7. Pivacy Considerations . . . . . . . . . . . . . . . . . . . . 17 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 9.1. Normative References . . . . . . . . . . . . . . . . . . 17 9.2. Informative References . . . . . . . . . . . . . . . . . 18 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 19 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19 1. Introduction As organisations move more workloads into untrusted or shared environments, protection of data in use becomes increasingly important. One way of isolating data in use is Confidential Computing: executing a workload (for example an AI model, database process or financial service) inside a hardware-based, remotely attested Trusted Execution Environment (TEE). Workloads operating in such environments need stable and trustworthy identifiers to Novak, et al. Expires 9 May 2026 [Page 2] Internet-Draft RATS for TWI November 2025 communicate over the network to the external world. Often such identifiers are provided to them via Credential Authorities upon ascertaining trust in the environments in which these workloads operate. The standard practice to establish trust in the operating environment is through Remote Attestation. This draft specifies how a Workload operating in Confidential Computing Environment can obtain trustworthy, stable, and workload- bound credentials using Remote Attestation. 2. Conventions and Definitions 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, as shown here. This document uses terms and concepts defined by the WIMSE and RATS architectures, as well as the terms defined by the Trustworthy Workload Identity Special Interest Group at the Confidential Computing Consortium. For a complete glossary, see Section 4 of [RFC9334] , [I-D.draft-ietf-wimse-arch] & [TWISIGDef]. The definitions of terms like Trustworthy Workload Identity and Workload Credential match those specified by the TWI SIG Definitions [TWISIGDef]. Workload: [I-D.draft-ietf-wimse-arch] defines 'Workload' as "an instance of software executing for a specific purpose". Here we restrict that definition to the portions of the deployed software and its configuration that are subject to Remote Attestation. Workload Identifier: a stable construct around which Relying Parties can form long-lived Workload authorization policies. Workload Identity: the definition of Workload Identity is identical to the definition of the same term by [I-D.draft-ietf-wimse-arch]: "a combination of three basic building blocks: trust domain, Workload Identifier and identity credentials. Workload Credential: an ephemeral identity document containing the Workload Identifier and a number of additional claims, that can be short-lived or long-lived, and that is used to represent and prove Workload Identity to a Relying Party. Stable Workload Identity, Stable Authorization Policy: a Workload Novak, et al. Expires 9 May 2026 [Page 3] Internet-Draft RATS for TWI November 2025 Identity or Authorization Policy is considered Stable if it remains constant in the face of software and hardware changes (updates and rollbacks), so long as those updates and rollbacks are authorized, i.e., comply with the policy of what consitutes the allowed version(s) of the software and hardware in question. Credential Authority: an entity trusted to issue Workload Credentials Bound Workload Credential: a Workload Credential is considered Bound if it can only be used in conjunction with a secret Credential Key that only a Workload authorized for the use of that Key can obtain, either by generating and certifying it, or by retrieving it from a secure Key Store. Workload Owner: an entity tasked with specifying policies concerning what Workload composition is considered valid for the purposes of issuing Workload Credentials Verifier: an entity performing the role of Attestation Verification, as documented in Section 4 of [RFC9334] 3. Available Options When dealing with a client Workload that is running inside a remotely attested Trusted Execution Environment, the goal of having a Relying Party having a Stable authorization policy and utilizing industry- standard mechanisms for authorization can be achieved by issuing Credentials in a relying party-friendly format, such as those specified by [I-D.draft-ietf-wimse-arch]. Such Credentials may take the form of x.509 certificates or Workload Identity Tokens (WITs) defined in Section 3.1 of [WIMSES2S]. A Workload can start using the Credential for authentication and authorization once it has two items in its possession: the public portion - the Workload Credential itself, and the secret Credential Key necessary to utilize this Credential. A Stable authorization policy can only be achieved if Workloads can have Stable identities. The decision about what constitutes a trustworthy Workload and a trustworthy configuration is a composition verification, with multiple entities providing Reference Values for the components they vouch for. For the issued Workload Identity to be Stable in addition to Trustworthy, a mapping must be performed between these Reference Values and the issued Identities. In a typical enterprise, Stable authorization policies are expressed in terms of business- rather than technology-oriented concepts, e.g., "Payroll Application", "Located in Germany", "Cleared for handling Personally Identifiable Information", etc. This contrasts with what Novak, et al. Expires 9 May 2026 [Page 4] Internet-Draft RATS for TWI November 2025 RATS has historically thought of as Attestation Results, which may relate to the hardware manufacturer, firmware and software versions, etc. In some implementations, a Credential is precomputed, and the Credential Key is obtained from a Key Store following successful Remote Attestation. In other implementations, the Workload generates its own Credential Key and uses Remote Attestation to certify it. Within the RATS Architecture, either of these options can be accomplished in one of three ways: 1. The Workload supplies Evidence to a Verifier and obtains from it Attestation Results. It then provides these Attestation Results to the Credential Authority in exchange for a Credential. 2. The Verifier contacts the Credential Authority on the Workload's behalf, and the Attestation Results obtained from the Verifier are (or contain) the Credentials for that Workload. 3. The Credential Authority contacts the Verifier on the Workload's behalf, and the Credential Authority constructs the Credential using the Attestation Results received from the Verifier. In either case, the detailed information about the Workload's composition conveyed to the Verifier using RATS "Evidence" is mapped to Stable, technology-agnostic, business-oriented claims about the Workload by invoking a new architectural building block called a Claims Mapper, described below. These three options can be visualised at a high level as shown below. E: Evidence AR: Attestation Results CR: Credential Request C: Credential 3.1. Variant 1 Novak, et al. Expires 9 May 2026 [Page 5] Internet-Draft RATS for TWI November 2025 +----------+ | | | Verifier | | | +--^----+--+ | | 1:E| |2:AR +--+----v--+ 3:CR +------------+ | +---------> Credential | | Workload | 4:C | Authority | | <---------+ | +----+-----+ +------------+ | |5:C +----v-----+ | Relying | | Party | +----------+ 3.2. Variant 2 +------------+ 2:CR +------------+ | +--------> Credential | | Verifier | 3:C | Authority | | <--------+ | +--^------+--+ +------------+ | | 1:E| |4:AR (incl. C) +--+------v--+ | | | Workload | | | +-----+------+ | |5:C +-----v------+ | Relying | | Party | +------------+ 3.3. Variant 3 Novak, et al. Expires 9 May 2026 [Page 6] Internet-Draft RATS for TWI November 2025 +------------+ | Verifier | | | +--^-----+---+ | | 2:E| |3:AR +-----------+ 1:CR +--+-----v---+ | +---------> Credential | | Workload | 4:C | Authority | | <---------+ | +-----+-----+ +------------+ | |5:C +-----v-----+ | Relying | | Party | +-----------+ From the Workload's perspective, Variant 1 carries with it an extra network roundtrip (the first roundtrip being the workload exchanging "Evidence" for "Attestation Results"). It is the only option available to the Workload for using existing Verifier implementations that make no changes associated with this proposal. This option does however introduce additional latency and reliability costs inherent in an extra roundtrip. Variants 2 and 3 do not require the Workload to perform an extra roundtrip, and thus do not carry the additional performance costs or reliability risks. Several distinct options are possible. In all cases, the Credential is generated and signed by a Credential Authority. The difference is in how the Workload obtains these Credentials. The main pivots are: 1. Where the Credential Key is generated (Key Source): 1. Inside the Workload Instance 2. Inside a secure Key Store such as a Hardware Security Module (HSM), by the Workload Owner 2. Where the Workload gets its Credential from (Credential Source): 1. The Verifier 2. The Credential Authority (e.g., a Certificate Authority, a Security Token Service, or similar) Novak, et al. Expires 9 May 2026 [Page 7] Internet-Draft RATS for TWI November 2025 3. The Workload Owner (via the Control Plane) Note that it is safe to receive the Credential from an untrusted source such as the Control Plane, because it is public. The only requirement is that the obtained Credential matches the Credential Key, which MUST always be obtained securely and only by an authorized Workload instance. Further, under pivot 2.i, the order of interactions involved in Credential generation might differ: 1. A Workload invokes the Verifier which collaborates with the Credential Authority to compute and return Credentials, returning these Credentials inside the Attestation Results, or 2. A Workload invokes the Verifier, obtains from it the Attestation Results, and forwards these Attestation Results to the Credential Authority inside a Credential Request to get the Credential. 4. Claims Mapper In order to convert Evidence that the Workload collects about itself into business-centric Claims about the Workload, a new architectural building block is required: a Claims Mapper. The inputs to the Claims Mapper depend on the Credential Issuance Mechanism, several of which are discussed in the following sections. In some cases, the business-centric output claims are generated from the Evidence submitted to the Verifier by the Workload, and in other cases - from the Attestation Results computed by the Verifier upon examining the Evidence. In all cases, the decisions on 1) whether to accept the inputs as valid and 2) which claims to emit based on these inputs are going to be made by the Claims Mapper Policy, which is governed by the Workload Owner. Whenever a new version of the Workload is rolled out, the corresponding updated Claims Mapper Policy must be put in place. 5. Credential Acquisition Mechanisms This set of variants results in several distinct Credential Acquisition Mechanisms (CAMs), some of which are listed in the table below: Novak, et al. Expires 9 May 2026 [Page 8] Internet-Draft RATS for TWI November 2025 +=====+==========+============+====================================+ | CAM | Key | Credential | Description | | | Source | Source | | +=====+==========+============+====================================+ | A | Workload | Verifier | A Proof-of-Possession of the | | | | | Credential Key is included in the | | | | | Evidence submitted by the Workload | | | | | Instance to the Verifier. The | | | | | Verifier first appraises the | | | | | Evidence. It then invokes the | | | | | Claims Mapper to map this Evidence | | | | | to Claims about the Workload. | | | | | Finally, it contacts the | | | | | Credential Authority to compute a | | | | | Credential based on this | | | | | Credential Key, and returns it to | | | | | the Workload Instance as part of | | | | | Attestation Results. | +-----+----------+------------+------------------------------------+ | B | Workload | Credential | A Proof-of-Possession of the | | | | Authority | Credential Key is included in the | | | | | Evidence submitted by the Workload | | | | | Instance to the Verifier, and also | | | | | in the Attestation Results | | | | | returned by the Verifier. The | | | | | Workload Instance sends the | | | | | Attestation Results obtained from | | | | | the Verifier to the Credential | | | | | Authority. Credential Authority | | | | | invokes the Claims Mapper to map | | | | | the Attestation Results to Claims | | | | | about the Workload Instance. It | | | | | then computes and returns to the | | | | | Workload Instance a Credential | | | | | based on these Claims. | +-----+----------+------------+------------------------------------+ | C | Workload | Credential | A Proof-of-Possession of the | | | | Authority | Credential Key is included in a | | | | | Credential Request submitted by | | | | | the Workload to the Credential | | | | | Authority alongside Evidence | | | | | destined for the Verifier. | | | | | Credential Authority handles the | | | | | Credential Request by contacting | | | | | the Verifier on the Workload's | | | | | behalf, supplying the Evidence | | | | | from the Credential Request. The | | | | | Verifier responds with Attestation | Novak, et al. Expires 9 May 2026 [Page 9] Internet-Draft RATS for TWI November 2025 | | | | Results. The Credential Authority | | | | | invokes the Claims Mapper to | | | | | convert the Attestation Results to | | | | | Claims about the Workload. It | | | | | then computes and returns to the | | | | | Workload Instance a Credential | | | | | based on these Claims. | +-----+----------+------------+------------------------------------+ | D | Key | Workload | The Workload Owner uses the Claims | | | Store | Owner | Mapper to create the Claims about | | | | | the Workload and the associated | | | | | Key Release Policy, specifying the | | | | | expected Attestation Results | | | | | needed to obtain the Credential | | | | | Key. The Workload Owner then | | | | | interacts with the Key Store to | | | | | generate the Credential Key, the | | | | | Credential and set the Key Release | | | | | Policy. It then makes the | | | | | Credential available to the | | | | | Workload. The Workload obtains | | | | | the Credential Key from the Key | | | | | Store after completing Remote | | | | | Attestation. | +-----+----------+------------+------------------------------------+ Table 1 These options are illustrated below with sequence diagrams. 5.1. Mechanism A Novak, et al. Expires 9 May 2026 [Page 10] Internet-Draft RATS for TWI November 2025 +--------------+ +--------------+ +------------------------+ | Workload | | Verifier | | Credential Authority | +------+-------+ +-------+------+ +------------+-----------+ | | | .------+------------------------+----------------------------+-----------. | Credential Acquisition Phase | +------+------------------------+----------------------------+-----------+ | Generate Credential | | +-----------+ Key | | +<----------+ | | | Create Credential Req | | |(incl. Credential Key | | +------------+ Pop) | | +<-----------+ | | | Create Evidence | | | (incl. Credential Req) | | +------------+ | | +<-----------+ | | | Request Attestation | | +----------------------->| | | (Evidence) | Appraise Evidence | | +-----------+ | | |<----------+ | | | Invoke Claims Mapper | | +-----------+ to compute Claims | +<----------+ | │ | Request Credential | │ | (Credential Req+ Claims) | │ +--------------------------->+ │ | Create & Sign Credential | | | +-------------+ | | +------------>+ │ | | │ | Return Credential | │ Return Credential +<---------------------------+ | in Attestation Results | | +<-----------------------+ | +------+-------+ +-------+------+ +------------+-----------+ | Workload | | Verifier | | Credential Authority | +--------------+ +--------------+ +------------------------+ 5.2. Mechanism B Novak, et al. Expires 9 May 2026 [Page 11] Internet-Draft RATS for TWI November 2025 +--------------+ +--------------+ +------------------------+ | Workload | | Verifier | | Credential Authority | +------+-------+ +-------+------+ +------------+-----------+ | | | .------+------------------------+----------------------------+-----------. | Credential Acquisition Phase | +------+------------------------+----------------------------+-----------+ │ Generate Credential Key | +------------+ | | +<-----------+ | | │ Create Evidence | | | (incl. Credential Key | | +------------+ PoP) | | +<-----------+ | | │ Request Attestation | | +----------------------->+ | │ (Evidence) Appraise Evidence | | +------------+ | | +<-----------+ | │ | Compute Attestation | | | Results | | +------------+ | | +<-----------+ | | Return | | │ Attestation Results | | +<-----------------------+ | │ Create Credential Req. | | | (incl. Credential Key | | +------------+ Pop & AR) | | +<-----------+ | | │ Request Credential (Cre|dential Request) | | +------------------------+--------------------------->+ | | Invoke Claims Mapper to | │ |convert Attestation Results | │ | to Credential Attributes | | | +-------------+ | | +------------>| │ | Create & Sign Credential | | | +-------------+ | | +------------>| | | Return Credential | │<-----------------------+----------------------------+ +------+-------+ +-------+------+ +------------+-----------+ | Workload | | Verifier | | Credential Authority | +------+-------+ +--------------+ +------------------------+ 5.3. Mechanism C Novak, et al. Expires 9 May 2026 [Page 12] Internet-Draft RATS for TWI November 2025 +--------------+ +------------------------+ +--------------+ | Workload | | Credential Authority | | Verifier | +------+-------+ +------------+-----------+ +-------+------+ | | | .------+-----------------------------+----------------------------+------. | Credential Acquisition Phase | +------+-----------------------------+----------------------------+------+ │ Generate Credential Key | | +------------+ | | +<-----------+ | | │ Create Evidence | | | (incl. Credential Key | | +------------+ PoP) | | +<-----------+ | | │ Create Credential Request | | +------------+(Evidence, | | | |Credential | | +<-----------+Key PoP) | | | | | │ Request Credential | | +---------------------------->+ │ │ (Credential Request) | Request Attestation | | | (Evidence from | | | Credential Request) | │ +--------------------------->+ │ | Appraise Evidence | | | +-------------+ | | +------------>+ │ | Compute Attestation Results| | | +-------------+ | | +------------>+ │ | Return Attestation Results | │ +<---------------------------+ | | Invoke Claims Mapper to | | | compute Claims from AR | | +------------+ | | +<-----------+ | │ | Create & Sign Credential | | +------------+ | | +<-----------+ | │ Return Credential | | +<----------------------------+ | +------+-------+ +------------+-----------+ +-------+------+ | Workload | | Credential Authority | | Verifier | +------+-------+ +------------+-----------+ +-------+------+ Novak, et al. Expires 9 May 2026 [Page 13] Internet-Draft RATS for TWI November 2025 5.4. Mechanisms D Mechanism D consists of a "Credential Provisioning" phase followed by the "Credential Acquisition" phase. 5.4.1. Credential Provisioning Phase Novak, et al. Expires 9 May 2026 [Page 14] Internet-Draft RATS for TWI November 2025 +------------------+ +-------------+ +-------------+ +------------------------+ | Workload Owner | | Workload | | Key Store | | Credential Authority | +---------+--------+ +------+------+ +------+------+ +-----------+------------+ | | | | +--------+----------------------+--------------------+-------------------------+-----------+ | Credential Provisioning Phase | +--------+----------------------+--------------------+-------------------------+-----------+ | Invoke the Claims Mapper to | | │ create Workload Identifier | | | and Associated Credential Claims │ | +------------+ | | | +<-----------+ | | | │ Create Credential Key Release Policy | | | based on anticipated Attestation Results │ | +------------+ | | | +<-----------+ | | | │ Create Credential Key | | | and Set Key Release Policy | │ +------------------------------------------>+ │ │ │ │ Generate and Store Credential Key | | | and Key Release Policy | | | +------------+ | | | +<-----------+ | │ Return Public Portion of Credential Key | | | or Credential Key Identifier | | +<------------------------------------------+ │ │ Create Credential Request │ │ +----------------------+------------------->+ │ │ | │ Create Credential Request and │ | │ Sign with Private Credential Key | | +------------+ | | | +<-----------+ | │ Return Credential Request | │ +<---------------------+--------------------+ │ │ Request Credential (Credential Request, Workload Identity, Credential Attributes) +----------------------+--------------------------------------------->+ │ │ Create and Sign Credential | | │ | +-------------+ | │ | +------------>+ │ │ | Return Credential | +<---------------------+--------------------+-------------------------+ | Provide Workload with Credential | │ +--------------------->+ | | +---------+--------+ +------+------+ +------+------+ +-----------+------------+ | Workload Owner | | Workload │ | Key Store | | Credential Authority | +------------------+ +-------------+ +-------------+ +------------------------+ Novak, et al. Expires 9 May 2026 [Page 15] Internet-Draft RATS for TWI November 2025 5.4.2. Credential Acquisition Phase +--------------+ +--------------+ +-------------------+ | Workload | | Verifier | | Key Store | +------+-------+ +-------+------+ +-------+-----------+ | | | .------+------------------------+-----------------------+-----------. | Credential Acquisition Phase | +------+------------------------+-----------------------+-----------+ │ Generate Asymmetric Encryption Key │ +------------+ | | +<-----------+ | | │ Generate Evidence (incl+. Public Encryption | +------------+ | Key) | |<-----------+ | | │ Request Attestation | | +----------------------->+ │ │ (Evidence) | Appraise Evidence | | +------------+ | | +<-----------+ | │ │ Compute Attestation | | +------------+ Results | | +<-----------+ | │ Return | | | Attestation Results | | | (incl. Encryption Key) | | +<-----------------------+ │ │ Request Credential Key (Attestation Results) | +----------------------------------------------->+ │ Validate Attestation Results | │ against Credential Key Release Policy | | | +-------------+ | | +------------>+ │ Encrypt Credential Key to Encryption Key | | | +-------------+ | | +------------>+ │ Return Encrypted Credential Key │ +<-----------------------+-----------------------+ │ Decrypt Credential Key | | +------------+ | | +<-----------+ | | +------+-------+ +-------+------+ +-------+-----------+ | Workload | | Verifier | | Key Store | +------+-------+ +-------+------+ +-------+-----------+ Novak, et al. Expires 9 May 2026 [Page 16] Internet-Draft RATS for TWI November 2025 6. Security Considerations All communications between entities (Workload to Credential Authority, Workload to Verifier etc) MUST be secured using mutually authenticated, confidential, and integrity-protected channels (e.g., TLS). In addition to the considerations herein, Verifier, which is a central point of anchor for Trustworthy Workload Identifer MUST follow the security guidance detailed in the "Security and Privacy considerations" as detailed in the RATS Architecture Section 11 and Section 12 of [RFC9334]. The credential key MUST always be stored securely at all time, for example in a secure element of the underlying platform running the Workload. There is a risk that a live Workload Migration may render some of the claims about the Workload invalid (e.g., live-migrating a Workload between Germany and France may incorrectly preserve the "Country=Germany" claim, but correctly preserve the "Region=Europe" claim). 7. Pivacy Considerations Remote Attestation of a Workload requires exchange of attestation related messages, for example, Evidence and Attestation Results. This can potentially leak sensitive information about the Workload. Confidentiality: Encryption could be used to prevent unauthorised parties from accessing sensitive information from Evidence or Attestation Results. This is crucial in multi-tenant environments. The Credential Key to be released to a Workload MUST always be encrypted to avoid potential leakage to unauthorised actors. 8. IANA Considerations This document has no IANA actions. 9. References 9.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . Novak, et al. Expires 9 May 2026 [Page 17] Internet-Draft RATS for TWI November 2025 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . 9.2. Informative References [I-D.draft-ietf-wimse-arch] Salowey, J. A., Rosomakho, Y., and H. Tschofenig, "Workload Identity in a Multi System Environment (WIMSE) Architecture", Work in Progress, Internet-Draft, draft- ietf-wimse-arch-06, 30 September 2025, . [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, . [RFC9711] Lundblade, L., Mandyam, G., O'Donoghue, J., and C. Wallace, "The Entity Attestation Token (EAT)", RFC 9711, DOI 10.17487/RFC9711, April 2025, . [TWISIGCharter] Confidential Computing Consortium Trustworthy Workload Identity SIG, "Trustworthy Workload Identity (TWI) Special Interest Group -- Charter", n.d., . [TWISIGDef] Confidential Computing Consortium Trustworthy Workload Identity SIG, "Trustworthy Workload Identity (TWI) Special Interest Group -- Definitions", n.d., . [TWISIGReq] Confidential Computing Consortium Trustworthy Workload Identity SIG, "Trustworthy Workload Identity (TWI) Special Interest Group -- Requirements", n.d., . [WIMSES2S] IETF, "WIMSE Service-to-Service Protocol", n.d., . Novak, et al. Expires 9 May 2026 [Page 18] Internet-Draft RATS for TWI November 2025 Acknowledgments The following persons, in no specific order, contributed to the work directly, participated in design team meetings, or provided valuable comments during the review of this document. Pieter Kasselman (SPIRL), Arieal Feldman (Google), Mateusz Bronk (Intel), Manu Fontaine (Hushmesh Inc.), Benedict Lau (EQTY Lab), Zvonko Kaiser (NVIDIA), David Quigley (Intel), Sal Kimmich (GadflyAI), Alex Dalton (Shielded Technologies), Eric Wolfe (Mainsail Industries), Nicolae Paladi(Canary Bit), Mark Gentry (JPMorgan Chase), Jag Raman (Oracle), Brian Hugenbruch (IBM), Jens Alberts (Fr0ntierX), Mira Spina (MITRE) and John Suykerbuyk. Authors' Addresses Mark Novak J.P. Morgan Chase Email: mark.f.novak@jpmchase.com Yogesh Deshpande Arm Email: Yogesh.Deshpande@arm.com Henk Birkholz Franhaufer Inst. Email: Henk.Birkholz@ietf.contact Novak, et al. Expires 9 May 2026 [Page 19]