Trustworthy Enrollment of Secure Credentials
draft-bdnr-rats-trustworthy-credentials-02
This document is an Internet-Draft (I-D).
Anyone may submit an I-D to the IETF.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
| Document | Type | Active Internet-Draft (individual) | |
|---|---|---|---|
| Authors | Mark Novak , Michael Richardson , Henk Birkholz | ||
| Last updated | 2026-07-21 | ||
| RFC stream | (None) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-bdnr-rats-trustworthy-credentials-02
RATS Working Group M. Novak
Internet-Draft J.P. Morgan Chase
Intended status: Informational M. Richardson
Expires: 22 January 2027 Sandelman Software Works
H. Birkholz
Franhaufer Inst.
21 July 2026
Trustworthy Enrollment of Secure Credentials
draft-bdnr-rats-trustworthy-credentials-02
Abstract
There is a large class of "RATS-Unaware" Relying Parties (RUPs) that
Attesters nevertheless need to interoperate with. Existing deployed
services, which precede the introduction of Remote Attestation, are
often difficult to change/update in significant ways due to, among
other reasons, organizational friction, technological inertia, and
regulatory policies. Yet there are significant advantages if
workloads can be incrementally updated in the trustworthiness of the
platform, without disrupting their clients and servers.
This document details a protocol by which Remote Attestattion of
Attesters is incorporated into the process of them being provided
with Identity Documents (keys or credentials) to authenticate to
RUPs.
This specification illustrates how the RATS Architecture can be
applied to interoperate with RUPs by providing Attesters with such
Identity Documents.
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-bdnr-rats-trustworthy-
credentials/.
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/.
Source for this draft and an issue tracker can be found at
https://github.com/mcr/twi-rats.
Novak, et al. Expires 22 January 2027 [Page 1]
Internet-Draft ESC July 2026
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 22 January 2027.
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
1.1. Reasons for RATS Unaware Relying Party Immutability . . . 4
2. Conventions and Definitions . . . . . . . . . . . . . . . . . 4
3. Overview of Mechanism . . . . . . . . . . . . . . . . . . . . 6
3.1. Types of Credentials . . . . . . . . . . . . . . . . . . 7
3.2. Deployment of Credentials . . . . . . . . . . . . . . . . 8
4. Details of protocol . . . . . . . . . . . . . . . . . . . . . 8
4.1. Variant 1: Key Broker Mode . . . . . . . . . . . . . . . 10
4.2. Variant 2: Credential Broker Mode . . . . . . . . . . . . 10
4.3. Variant 3: Credential Authority Mode . . . . . . . . . . 10
4.4. Use of Enrollment over Secure Transport (EST) . . . . . . 10
4.4.1. Using EST to Mint New Proof-of-Possession
Credentials . . . . . . . . . . . . . . . . . . . . . 11
4.4.2. Using EST to Obtain Existing Keys, Tokens, or
Proof-of-Possession Credentials . . . . . . . . . . . 11
Novak, et al. Expires 22 January 2027 [Page 2]
Internet-Draft ESC July 2026
4.4.3. Credential Broker as short-term Bearer Token
issuer . . . . . . . . . . . . . . . . . . . . . . . 11
5. Security Considerations . . . . . . . . . . . . . . . . . . . 11
6. Privacy Considerations . . . . . . . . . . . . . . . . . . . 12
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 12
8.1. Normative References . . . . . . . . . . . . . . . . . . 12
8.2. Informative References . . . . . . . . . . . . . . . . . 13
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 14
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14
1. Introduction
Success of a technology is ultimately measured by its adoption. The
RATS Architecture requires that RATS Relying Parties understand
Attestation Results expressed using standards such as EAT and AR4SI,
execute Appraisal Policy for Attestation Results, and have trust in
Verifiers. Additionally, there is an unstated assumption present in
the RATS Architecture that a change in Evidence may lead to a change
in either the Attestation Results or Appraisal Policy for Attestation
Results. This requirement may pose a significant adoption blocker.
One key requirement for successful deployment of Remote Attestation-
capable workloads is minimal blast radius. When a workload is moved
from a legacy to a remotely attestable (e.g. Trusted Execution)
environment, including Intel SGX, AMD SEV-SNP, ARM TrustZone, that
workload can use Remote Attestation to obtain a stable and
trustworthy Identity Document while its clients and servers do not
notice anything different.
For that, a mechanism is required by means of which a Credential
Broker, a Key Broker, or a Credential Authority takes on the role of
RATS Relying Party. This provides an intermediation between
Attestation Results, expressed using formats such as EAT and AR4SI,
and the RATS-Unaware Relying Parties whose authentication and
authorization policies may precede the introduction of Remotely
Attestable Workloads and remain static for long periods of time.
For the RATS-Unaware Relying Parties, these adoption barriers are
eliminated, as these RUPs are capable of authenticating their clients
utilizing appropriate Identity Documents. This includes shared
symmetric keys, bearer tokens, credentials including PKIX
certificates [RFC5280], JWTs [RFC7515], or WIMSE WITs
[I-D.ietf-wimse-workload-creds]. In this world, the Attester uses
Remote Attestation to obtain from the RATS Relying Party a key, token
or credential that is compatible with the RUP.
Novak, et al. Expires 22 January 2027 [Page 3]
Internet-Draft ESC July 2026
This document details an architecture by which legacy Identity
Document issuance mechanisms are replaced with identical Identity
Documents issued, but with the additional prerequisite of successful
Remote Attestation of the workloads in question.
1.1. Reasons for RATS Unaware Relying Party Immutability
The most important and most common scenario addressed here is that of
a workload that employs Remote Attestation but whose Relying Party
has no capacity to process Attestation Results or execute Appraisal
Policy for Attestation Results. This RATS Unaware Relying Party is
typically unable to make the corresponding changes for a number of
reasons:
* It may be a compiled object or container provided by a third
party.
* Or it may be implemented in a language not easily changed or
upgraded with new capabilities.
* Or, as an extreme example, it could be an ancient COBOL program
compiled into a WASM object, perhaps connected to the network via
virtual paper-tape and virtual printer interfaces.
* Further, such a system may require extensive and significant
review by an authority before changes to the core algorithm can be
made.
* Or, finally, the reluctance to change may come from organizational
friction within an enterprise where the remotely attesting
workload is organizationally separate from its Relying Party and
different priorities of different parts of organization prevent
them moving in lockstep.
In all of these cases, it is assumed that the remotely attesting
workload can make the necessary changes to perform remote
attestation, and that interoperability with the RUP will be preserved
so long as the key, token, or credential obtained by the workload
following Remote Attestation matches that expected by the RUP.
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.
Novak, et al. Expires 22 January 2027 [Page 4]
Internet-Draft ESC July 2026
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.ietf-wimse-arch] & [TWISIGDef].
The definitions of terms like Trustworthy Workload Identity and
Workload Credential match those specified by the TWI SIG Definitions
[TWISIGDef].
Broker: an entity that deals out pre-existing keys or credentials.
Constrast to a Credential Authority which mints new credentials.
Identity Document: a catch-all term for any type of key, token, or
credential that is used by the attesting workload to authenticate
to the RATS Unaware Relying party.
Identity Document Service: a catch-all term for a service that acts
as a Key/Token Broker, Credential Broker, or Credential Authority,
that the attesting workload uses to obtain its identity documents
following successful remote attestation.
RUP: The RATS Unaware Relying Party (RUP). A target service that
interacts with many clients based upon credentials provided. This
is sometimes called the Collaborating Party.
Workload: [I-D.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 Duration: the lifespan of the workload. While some
workloads can be very long lived, but many workloads are created
for a brief period of time, often added on demand to support
rising demand, and persisting for only minutes to a small fraction
of a day.
Workload Owner: the entity that manages a workload, arranging to
provision it with appropriate Workload Credentials before Workload
is launched
Workload Credential: an ephemeral identity document containing an
identity and a number of additional claims, that can be short-
lived or long-lived, and that is used to access a service
Proof of possession credential: this is a credential, such as an
Novak, et al. Expires 22 January 2027 [Page 5]
Internet-Draft ESC July 2026
x.509 certificate or a WIMSE WIT, that requires proof of
possession (typically an asymmetric signing key) to us. It is
considered public information -- the secrecy is in the associated
signing key.
Collaborating Party: see RUP.
Verifier: an entity performing the role of Attestation Verification,
as documented in Section 4 of [RFC9334]
3. Overview of Mechanism
A newly created workload connects to the Identity Document Service
(IDS) to obtain a set of Identity Documents to be used to perform its
functions.
The proposed mechanism works equally well with Background Check and
Passport models of RATS. The IDS is acting as a RATS Relying Party,
the workload is the Attester.
Figure Figure 1 extends the [RFC9334] architecture to show how the
workload and IDS take on the roles of Attester and Relying Party.
Note in particular that no changes are made to the RATS Architecture;
the only change is that the RATS Relying Party is now acting as the
IDS, and not the ultimate destination for workload's authentication.
If the Attestation Result is acceptable, then the IDS returns the
Identity Document that the workload needs to accomplish its task.
Novak, et al. Expires 22 January 2027 [Page 6]
Internet-Draft ESC July 2026
.----------. .-----------. .----------. .---------.
| Endorser +. | Reference | | Verifier | | Relying |
'----------' | | Value | | Owner | | Party |
| | Provider | '-+--------' | Owner |
| '-+---------' | '-------+-'
| | | Appraisal |
| | Reference | Policy for |
| | Values | Evidence |
v v v |
.-------------------------. |
.--->| Verifier +------. |
| '-------------------------' | |
| | |
| Evidence Attestation | |
| Results | |
| | |
| v v
.-----+----. .--------------------.
| Attester | | RATS Relying Party |
|----------|<-------Identity Document-------|--------------------|
| workload | | Identity Document |
'-----+----' | Service |
\ '--------------------'
\ authentication .---------------------.
`----work-data---------->| RATS Unaware |
| Relying Party |
| Collaborating Party |
'---------------------'
RATS-Unaware ^
Authentication |
Policy |
.--------------+-.
| RATS-Unaware |
| Relying Party |
| Owner |
'----------------'
Figure 1: Credential Enrollment Architecture
3.1. Types of Credentials
There are three kinds of credentials that can be involved. Some
workloads might use a few of each, possibly with each one being used
with a different RATS Unaware Party.
Novak, et al. Expires 22 January 2027 [Page 7]
Internet-Draft ESC July 2026
1. The IDS is also an Identity Provider (IdP), and acts as an
Registration Authority (possibly including the Certification
Authority). It issues new credentials in the form of PKIX
certificates or WIMSE WITs to each trustworthy workload, based on
attested workload-held private keys.
2. The IDS is a respository for Identity Documents issued by another
Identity Provider (IdP). The IDS has both the private key
(encrypted) and the proof-of-possession credential, and it
discloses these to trustworthy workloads by returning them in a
manner that ensures that only authorized workloads can decrypt
the private key, typically by encrypting them to an attested,
attester-held asymmetric encryption key.
The use of a shared assymetric private keys as identity documents is
unorthodox. This architecture is justified by the need to rapidly
scale the number of workers and to recover from hardware or network
failures. The alternatives is that external Identity Providers would
need to be willing to respond to spikes of hundreds of credential
requests within a small period of time. This would look like a
denial of service attack, and it may also require additional human
authorization for each.
The patterns of communication shown in figure Figure 1 are designed
specifically such that as few modifications are required to the
workload, and no changes to the Collaborating Party are required.
3.2. Deployment of Credentials
Workloads are expected to include a (virtual) Trusted Platform Module
(TPM), a Trusted Execution Environment, or equivalent, by which they
will generate collect and sign Evidence to be used in the Remote
Attestation process. Workloads are also assumed capable of
generating and attesting (including in Evidence) asymmetric
encryption or signing keys, the private portions of which never leave
the workload, and thus guarantee that no other workload can make make
use of these secrets.
4. Details of protocol
As there are three major types of credentials that may be used, it is
not unreasonable that they may get provisioned in different ways,
using different protocols.
However, when time comes for the workload to request the Identity
Documents, one of three possibilities arise:
Novak, et al. Expires 22 January 2027 [Page 8]
Internet-Draft ESC July 2026
1. (Key Broker mode) A cryptographic key encrypted to an attested,
Attester-held asymmetric Key Encryption Key
2. (Credential Broker mode) A proof-of-possession credential and a
corresponding Credential Signing Key encrypted to an attested,
Attester-held asymmetric Key Encryption Key
3. (Identity Provider mode) A freshly minted proof-of-possession
credential matching an attested, Attester-held asymmetric
Credential Signing Key, or a newly minted short-lived bearer
token encrypted to an attested, Attester-held asymmetric Token
Encryption Key
+=====================+============+================================+
| Variant | Workload | IDS Returns |
| | Generates | |
| | and | |
| | Attests | |
+=====================+============+================================+
| 1a: Key Broker for | Asymmetric | Credential Signing Key |
| proof-of-possession | Key | (CSK) matching PPC, |
| Keys (PPC) | Encryption | encyprted with the KEK |
| | Key (KEK) | |
+---------------------+------------+--------------------------------+
| 1b: Key Broker for | Asymmetric | Secret Preshared Key |
| shared keys | Key | (SPK), encrypted with |
| | Encryption | the KEK |
| | Key (KEK) | |
+---------------------+------------+--------------------------------+
| 2: Credential | Asymmetric | Proof-of-Possession |
| Broker for proof- | Key | Credential (PPC) and |
| of-possession | Encryption | Credential Signing Key |
| credentials | Key (KEK) | (CSK) for PPC, |
| | | Encrypted with the KEK |
+---------------------+------------+--------------------------------+
| 3a: Credential | Asymmetric | Newly minted proof-of- |
| Authority for | Credential | possession credential |
| proof-of-possession | Signing | matching the CSK |
| credentials | Key (CSK) | |
+---------------------+------------+--------------------------------+
| 3b: Credential | Asymmetric | Newly minted short- |
| Authority for | Token | lived bearer token |
| short-lived bearer | Encryption | encrypted with the TEK |
| tokens | Key (TEK) | |
+---------------------+------------+--------------------------------+
Table 1
Novak, et al. Expires 22 January 2027 [Page 9]
Internet-Draft ESC July 2026
These are explained in more detail below:
4.1. Variant 1: Key Broker Mode
The Attester generates an asymmetric Key Encryption Key (KEK), and
includes its public portion in Evidence during Remote Attestation.
The Attester receives from the RATS Relying Party a Secret Key
encrypted to the KEK. That Secret Key could be an asymmetric
Credential Signing Key for a proof-of-possession credential, such as
an x.509 certificate, that is pre-provisioned to the Attester
(Variant 1a), or a symmetric key for preshared key scenarios (Variant
1b).
4.2. Variant 2: Credential Broker Mode
The Attester generates an asymmetric Key Encryption Key (KEK), and
includes its public portion in Evidence during Remote Attestation.
The Attester receives from the RATS Relying Party a pre-provisioned
Credential (a WIT or an x.509 certificate) together with its
corresponding Credential Signing Key encrypted to the KEK.
4.3. Variant 3: Credential Authority Mode
In Variant 3a, which is similar to the Attested CSR protocol, the
Attester generates an asymmetric Credential Signing Key (CSK), and
includes its public portion in Evidence during Remote Attestation.
The RATS Relying Party, acting as a Credential Authority, mints a
brand new proof-of-possession credential and returns it to the
Attester.
In Variant 3b, the Attester generates an asymmetric Token Encryption
Key (TEK), and includes its public portion in Evidence during Remote
Attestation. The RATS Relying Party, acting as a Credential
Authority, mints a brand new short-lived bearer token (e.g. a JWT),
encrypts it with the TEK, and returns the encrypted bearer token to
the Attester.
4.4. Use of Enrollment over Secure Transport (EST)
EST ([RFC7030]) describes a mechanism to obtain a credential and/or a
corresponding credential signing key using TLS over HTTP. A few
changes are needed to make EST suitable for handling workloads
capable of Remote Attestation. In all cases below the EST client
hosts the workload, but is not assumed to be inside the workload's
TCB. This EST client might be the workload's hypervisor, a container
orchestrator, or some other workload hosting environment. Use of
authentication by this EST client is OPTIONAL. Even if used, client
authentication MUST NOT be used to establish the identity of the
Novak, et al. Expires 22 January 2027 [Page 10]
Internet-Draft ESC July 2026
workload for purposes of deciding which key, token or credential to
return to it. The EST server acts as a RATS Relying Party in
Background Check mode. The Evidence is submitted by the workload to
the EST server by the EST client acting on its behalf. There are
three ways to submit the Evidence:
1. Via a new, Remote Attestation extension to EST
2. Using [I-D.ietf-lamps-csr-attestation] extensions to the CSR
itself
3. Within TLS itself, using for instance, [I-D.fossati-seat-expat],
or whichever protocol the SEAT WG standardizes (in this case, the
workload becomes the EST client)
This Evidence is passed by the EST server to a Verifier, and
Attestation Results returned by the Verifier are used to establish
the identity of the workload.
4.4.1. Using EST to Mint New Proof-of-Possession Credentials
The EST /simpleenroll mechanism is used.
4.4.2. Using EST to Obtain Existing Keys, Tokens, or Proof-of-
Possession Credentials
The EST /serverkeygen mechanism is used. The server does not
generate a fresh key, but rather retrieves the keypair (private key
and certificate) from the store. This is encrypted back to the
client, however, mechanisms described in RFC7030 need to be modified
as any secrets (keys, bearer tokens) must be returned to an attested,
attester (workload)-held asymmetric encryption key, not to the EST
client directly. (TBD: This needs more detail, particularly for the
mTLS used in the EST)
4.4.3. Credential Broker as short-term Bearer Token issuer
EST is not appropriate for this use case. Another protocol or an
extension to EST will be required.
TBD.
5. 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).
Novak, et al. Expires 22 January 2027 [Page 11]
Internet-Draft ESC July 2026
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).
6. Privacy 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.
7. IANA Considerations
This document has no IANA actions (yet).
8. References
8.1. Normative References
[I-D.ietf-lamps-csr-attestation]
Ounsworth, M., Tschofenig, H., Birkholz, H., Wiseman, M.,
and N. Smith, "Use of Remote Attestation with
Certification Signing Requests", Work in Progress,
Internet-Draft, draft-ietf-lamps-csr-attestation-28, 16
June 2026, <https://datatracker.ietf.org/doc/html/draft-
ietf-lamps-csr-attestation-28>.
[I-D.ietf-wimse-workload-creds]
Campbell, B., Salowey, J. A., Schwenkschuster, A.,
Sheffer, Y., and Y. Rosomakho, "WIMSE Workload
Credentials", Work in Progress, Internet-Draft, draft-
Novak, et al. Expires 22 January 2027 [Page 12]
Internet-Draft ESC July 2026
ietf-wimse-workload-creds-02, 2 July 2026,
<https://datatracker.ietf.org/doc/html/draft-ietf-wimse-
workload-creds-02>.
[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/rfc/rfc2119>.
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
Housley, R., and W. Polk, "Internet X.509 Public Key
Infrastructure Certificate and Certificate Revocation List
(CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008,
<https://www.rfc-editor.org/rfc/rfc5280>.
[RFC7030] Pritikin, M., Ed., Yee, P., Ed., and D. Harkins, Ed.,
"Enrollment over Secure Transport", RFC 7030,
DOI 10.17487/RFC7030, October 2013,
<https://www.rfc-editor.org/rfc/rfc7030>.
[RFC7515] Jones, M., Bradley, J., and N. Sakimura, "JSON Web
Signature (JWS)", RFC 7515, DOI 10.17487/RFC7515, May
2015, <https://www.rfc-editor.org/rfc/rfc7515>.
[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/rfc/rfc8174>.
8.2. Informative References
[I-D.fossati-seat-expat]
Sardar, M. U., Fossati, T., Reddy.K, T., Sheffer, Y.,
Tschofenig, H., and I. Mihalcea, "Remote Attestation with
Exported Authenticators", Work in Progress, Internet-
Draft, draft-fossati-seat-expat-03, 4 July 2026,
<https://datatracker.ietf.org/doc/html/draft-fossati-seat-
expat-03>.
[I-D.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-08, 6 July 2026,
<https://datatracker.ietf.org/doc/html/draft-ietf-wimse-
arch-08>.
Novak, et al. Expires 22 January 2027 [Page 13]
Internet-Draft ESC July 2026
[I-D.ietf-wimse-identifier]
Rosomakho, Y. and J. A. Salowey, "Workload Identifier",
Work in Progress, Internet-Draft, draft-ietf-wimse-
identifier-03, 6 July 2026,
<https://datatracker.ietf.org/doc/html/draft-ietf-wimse-
identifier-03>.
[I-D.mihalcea-seat-use-cases]
Mihalcea, I., Sardar, M. U., Fossati, T., Reddy.K, T.,
Jiang, Y., and M. Chen, "Security Goals and Use Cases for
Integrating Remote Attestation with Secure Channel
Protocols", Work in Progress, Internet-Draft, draft-
mihalcea-seat-use-cases-03, 16 June 2026,
<https://datatracker.ietf.org/doc/html/draft-mihalcea-
seat-use-cases-03>.
[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/rfc/rfc9334>.
[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>.
Acknowledgments
Authors' Addresses
Mark Novak
J.P. Morgan Chase
Email: mark.f.novak@jpmchase.com
Michael Richardson
Sandelman Software Works
Canada
Email: mcr+ietf@sandelman.ca
Henk Birkholz
Franhaufer Inst.
Email: Henk.Birkholz@ietf.contact
Novak, et al. Expires 22 January 2027 [Page 14]