



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,
              <https://doi.org/10.17487/RFC2119>.




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, <https://doi.org/10.17487/RFC8174>.

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,
              <https://datatracker.ietf.org/doc/html/draft-ietf-wimse-
              arch-06>.

   [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://doi.org/10.17487/RFC9334>.

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

   [TWISIGCharter]
              Confidential Computing Consortium Trustworthy Workload
              Identity SIG, "Trustworthy Workload Identity (TWI) Special
              Interest Group -- Charter", n.d., <https://github.com/
              confidential-computing/governance/blob/main/SIGs/TWI/
              TWI_Charter.md>.

   [TWISIGDef]
              Confidential Computing Consortium Trustworthy Workload
              Identity SIG, "Trustworthy Workload Identity (TWI) Special
              Interest Group -- Definitions", n.d., <https://github.com/
              confidential-computing/twi/blob/main/TWI_Definitions.md>.

   [TWISIGReq]
              Confidential Computing Consortium Trustworthy Workload
              Identity SIG, "Trustworthy Workload Identity (TWI) Special
              Interest Group -- Requirements", n.d.,
              <https://github.com/confidential-computing/twi/blob/main/
              TWI_Requirements.md>.

   [WIMSES2S] IETF, "WIMSE Service-to-Service Protocol", n.d.,
              <https://datatracker.ietf.org/doc/draft-ietf-wimse-s2s-
              protocol/>.




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]
