Workload Identity in Multi System Environments J. Salowey Internet-Draft Palo Alto Networks Intended status: Informational Y. Rosomakho Expires: 7 January 2027 Zscaler H. Tschofenig UniBw M. 6 July 2026 Workload Identity in a Multi System Environment (WIMSE) Architecture draft-ietf-wimse-arch-08 Abstract The increasing prevalence of cloud computing and micro service architectures has led to the rise of complex software functions being built and deployed as workloads, where a workload is defined as software executing for a specific purpose, potentially comprising one or more running instances. This document discusses an architecture for designing and standardizing protocols and payloads for conveying workload identity and security context information. Discussion Venues This note is to be removed before publishing as an RFC. Discussion of this document takes place on the Workload Identity in Multi System Environments Working Group mailing list (wimse@ietf.org), which is archived at https://mailarchive.ietf.org/arch/browse/wimse/. Source for this draft and an issue tracker can be found at https://github.com/jsalowey/wimse-arch. 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." Salowey, et al. Expires 7 January 2027 [Page 1] Internet-Draft WIMSE Architecture July 2026 This Internet-Draft will expire on 7 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 2. Conventions and Definitions . . . . . . . . . . . . . . . . . 4 3. Architecture . . . . . . . . . . . . . . . . . . . . . . . . 6 3.1. Workload Identity Concepts . . . . . . . . . . . . . . . 6 3.1.1. Trust Domain . . . . . . . . . . . . . . . . . . . . 6 3.1.2. Workload Identifier . . . . . . . . . . . . . . . . . 6 3.1.3. Workload Identity Credentials . . . . . . . . . . . . 7 3.2. Workload Identity System Scenarios . . . . . . . . . . . 8 3.2.1. Basic Workload Identity Scenario . . . . . . . . . . 8 3.2.2. Context and workload Identity . . . . . . . . . . . . 11 3.2.3. Cross-Domain Communication . . . . . . . . . . . . . 13 3.3. Message Flow and Policy Enforcement in the Basic Scenario . . . . . . . . . . . . . . . . . . . . . . . . 15 3.4. Workload Identity Use Cases . . . . . . . . . . . . . . . 17 3.4.1. Bootstrapping Workload Identifiers and Credentials . 17 3.4.2. Workload and Service Authentication . . . . . . . . . 20 3.4.3. Layered Workload Authentication . . . . . . . . . . . 21 3.4.4. Service Authorization . . . . . . . . . . . . . . . . 23 3.4.5. Audit Trails . . . . . . . . . . . . . . . . . . . . 24 3.4.6. Security Context Establishment and Propagation . . . 25 3.4.7. Delegation and Impersonation . . . . . . . . . . . . 25 3.4.8. Accessing Resources in Other Trust Domains . . . . . 26 3.4.9. Asynchronous and Batch Requests . . . . . . . . . . . 26 3.4.10. Cross-boundary Workload Identity . . . . . . . . . . 26 3.4.11. AI and ML-Based Intermediaries . . . . . . . . . . . 28 4. Security Considerations . . . . . . . . . . . . . . . . . . . 29 4.1. Traffic Interception . . . . . . . . . . . . . . . . . . 29 4.2. Information Disclosure . . . . . . . . . . . . . . . . . 29 4.3. Workload Identity Binding to Tokens . . . . . . . . . . . 29 4.4. Credential Theft . . . . . . . . . . . . . . . . . . . . 29 Salowey, et al. Expires 7 January 2027 [Page 2] Internet-Draft WIMSE Architecture July 2026 4.5. Authentication and Authorization . . . . . . . . . . . . 30 4.6. Workload Compromise . . . . . . . . . . . . . . . . . . . 30 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 31 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 31 6.1. Normative References . . . . . . . . . . . . . . . . . . 31 6.2. Informative References . . . . . . . . . . . . . . . . . 31 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 32 Changes since draft -05 . . . . . . . . . . . . . . . . . . . . . 33 Changes since draft -06 . . . . . . . . . . . . . . . . . . . . . 33 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 33 1. Introduction The increasing prevalence of cloud computing and micro service architectures has led to the rise of complex software functions being built and deployed as systems composed of workloads, where a workload is defined as a logical software entity that executes for a specific purpose and may be represented at runtime by one or more workload instances. Workloads need to be provisioned with an identity when they are started. Often, additional information needs to be provided, such as trust anchors and security context details. Workloads make use of identity information and additional context information to perform authentication and authorization. Workload identity credentials are used to authenticate communications between workloads. This architecture considers two ways to express identity information: X.509 certificates, which are often used in the TLS layer, and JSON Web Tokens (JWTs) used at the application layer. The applicability of given token format depends on application and security context and will be explored in later sections. Once the workload is started and has obtained identity information, it can start performing its functions. When the workload is invoked it may require interaction with other workloads. An example of such interaction is shown in [I-D.ietf-oauth-transaction-tokens] where an externally-facing endpoint is invoked using conventional authorization mechanism, such as an OAuth 2.0 access token. The interaction with another workload may require the security context associated with the authorization to be passed along the call chain. In the rest of the document we describe terminology and use cases, discuss details of the architecture, and describe security considerations for this architecture. Salowey, et al. Expires 7 January 2027 [Page 3] Internet-Draft WIMSE Architecture July 2026 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 the following terms: * Workload A workload is an independently addressable and executable software entity. A workload is a logical entity rather than necessarily a single running process. It may be implemented by one or more workload instances and may expose, consume, or participate in one or more services. Examples include microservices, containers, virtual machines, serverless functions, or similar components that initiate or receive network communications. A workload typically interacts with other parts of a larger system. * Workload Instance A workload instance is a single running instantiation of a workload at a point in time such as a container, a VM, or a serverless invocation. Workload instances may exist for a very short duration of time (a fraction of a second) and run for a specific purpose such as to provide a response to an API request. Other kinds of workload instances may execute for a very long duration, such as months or years. Examples include database services and machine learning training jobs. The number of instances for a workload may vary over time due to scaling, failover, or orchestration behavior. * Service A service is a function, API, or capability exposed to other entities. A service may be implemented by a single workload, by multiple workload instances of the same workload, or by multiple workloads acting together. A service can have a stable identity that is distinct from the identity of any particular workload instance. When this document refers to service authentication or service authorization, it refers to authentication or authorization of the workload identity used to represent that service in a particular deployment. * Application System Salowey, et al. Expires 7 January 2027 [Page 4] Internet-Draft WIMSE Architecture July 2026 An application system is a set of workloads, services, gateways, credential services, and related infrastructure that together implement an application or application function. An application system may be contained within a single trust domain or may interact with services in other trust domains. * Security Context A security context provides information needed for a workload to perform its function. This information is often used for authorization, accounting and auditing purposes and often contains information about the request being made. Some examples include user information, software and hardware information or information about what processing has already happened for the request. Different pieces of context information may originate from different sources. * Identity Proxy The identity proxy is an intermediary that can inspect, replace or augment workload identity and security context information. A transparent network service such as a security gateway may act as an identity proxy, or the role can be implemented in a service performing explicit connection processing, such as an ingress gateway or a Content Delivery Network (CDN) service. The identity proxy MAY introduce additional context based on source identifier, communication properties and administrative policy. This context MAY be communicated as a transaction token [I-D.ietf-oauth-transaction-tokens]. * Remote Attestation The term "attestation", as defined in [RFC9683], refers to the process of generating and evaluating remote attestation Evidence. [RFC9334] describes Evidence and the different communication patterns. * Workload Identity Credential A credential that contains a workload identifier ([WIMSE-ID]) used for service to service authentication. The credential may be bound to a cryptographic key and may require that the presenter provide proof of possession of the secret key material. Examples of such credentials include Workload Identity Certificates and the Workload Identity Token defined in [I-D.ietf-wimse-s2s-protocol]. Deployments may also deploy bearer tokens as workload identity credentials to interoperate with legacy systems that do not support credentials bound to keys. Salowey, et al. Expires 7 January 2027 [Page 5] Internet-Draft WIMSE Architecture July 2026 * Trust Domain A trust domain is a logical grouping of systems that share a common set of security controls and policies. As described in [I-D.ietf-wimse-s2s-protocol], trust domains should be identified by a fully qualified domain name associated with the organization defining the trust domain. 3. Architecture 3.1. Workload Identity Concepts The Workload identity architecture consists of three basic building blocks: trust domain, workload identifier and identity credentials. These components are sufficient for establishing authentication, authorization and accounting processes. More complex workload identity constructs can be created from these basic building blocks. 3.1.1. Trust Domain A trust domain is a logical grouping of systems that share a common set of security controls and policies. Workload certificates and tokens are issued under the authority of a trust domain. Trust domains SHOULD be identified by a fully qualified domain name associated with the organization defining the trust domain. The FQDN format of a trust domain helps to ensure global uniqueness of the trust domain identifier. A trust domain maps to one or more trust anchors for validating X.509 certificates and a mechanism to securely obtain a JWK Set [RFC7517] for validating WIMSE WIT tokens. This mapping MUST be obtained through a secure mechanism that ensures the authenticity and integrity of the mapping is fresh and not compromised. This secure mechanism is out of scope for this document. A single organization may define multiple trust domains for different purposes such as different departments or environments. Each trust domain must have a unique domain identifier. Workload identifiers are scoped within a trust domain as specified in Section 4.3 of [WIMSE-ID]. If two identifiers differ only by trust domain they still refer to two different entities. 3.1.2. Workload Identifier A workload identifier uniquely names a workload within a trust domain and is carried in workload identity credentials. The format, syntax, comparison rules, and validation requirements for workload identifiers are defined in [WIMSE-ID]. Salowey, et al. Expires 7 January 2027 [Page 6] Internet-Draft WIMSE Architecture July 2026 In addition the URI MUST include an authority that identifies the trust domain within which the identifier is scoped. The trust domain SHOULD be a fully qualified domain name belonging to the organization defining the trust domain to help provide uniqueness for the trust domain identifier. The scheme and scheme specific part are not defined by this specification. An example of an identifier format that conforms to this definition is [SPIFFE-ID]. Two credentials containing the same workload identifier value represent the same workload only when validated under the same trust domain and issuer trust configuration. A workload identifier MAY represent a logical workload, a service implemented by one or more workloads, or a specific workload instance, depending on deployment policy. Relying parties MUST interpret the identifier according to the identity semantics defined by the issuing trust domain. 3.1.3. Workload Identity Credentials An agent provisions the identity credentials to the workload. These credentials are represented in the form of JWT tokens and/or X.509 certificates. JWT bearer tokens are presented to another party as a proof of identity. They may be signed to prevent forgery, however since these credentials are often not bound to other information it is possible that they could be stolen and reused elsewhere. To mitigate these risks and make the token more generally useful the WIMSE architecture defines a workload identity credential that binds a JWT to a cryptographic key. Both workload identity certificate and workload identity token (WIT) credentials consist of two parts: * a certificate or WIT is a signed data structure that contains a public key and identity information * a corresponding private key The workload identity certificate or WIT is presented during authentication, however the private key is kept secret and only used in cryptographic computation to prove that the presenter has access to the private key corresponding to the public key. The private key associated with a workload identity credential is security-sensitive key material. It may be generated and managed by the workload itself, by an agent, or by the surrounding platform or Salowey, et al. Expires 7 January 2027 [Page 7] Internet-Draft WIMSE Architecture July 2026 infrastructure. In all cases, the key material needs to be generated with sufficient entropy, stored securely, protected from unauthorized access, and rotated according to deployment policy. The appropriate lifetime of a workload identity credential and its associated key pair depends on the deployment model, the sensitivity of the workload, the strength of the key protection mechanism, and the expected lifetime of the workload instance. Generating a new key pair for every request is not generally required and may be impractical. However, deployments SHOULD use bounded credential lifetimes and automated renewal so that workload identity credentials and associated key pairs are periodically replaced and can be retired after suspected compromise. 3.2. Workload Identity System Scenarios 3.2.1. Basic Workload Identity Scenario +--------------------------------Trust Boundary---------------+ | | .---+-. | | .---+-. +--------------+ | | | | | | (3) | | | | +---> Workload 1 +-------------------+ | | | G | | | | | | | | a | | +-------^------+ | | | | t | | | | | +------------+ | | e | | | (1) | | | | (2) | | w | (3) | | | | | App Client +----->| | a +-----+ +-------+-------+ | | | | | | y | | | +-------+------+ | +------------+ | | +-----+ | CA/Credential | (1) | | | | | S | (4) | | Service +----------> Workload 3 | | | | e | | | | | | | | | r | | +-------+-------+ +-------+------+ | | | v | | | | | | | i | | | (1) | | | | c | | | | | | | e | | +-------v------+ | | | | | | | | (4) | | | | | +---> Workload 2 +-------------------+ | '-+ | | | | '-+---' +--------------+ | | | | | | | +-------------------------------------------------------------+ Salowey, et al. Expires 7 January 2027 [Page 8] Internet-Draft WIMSE Architecture July 2026 Figure 1: Basic example workload application system. The above diagram presents a basic workload application system. The large box represents a trust domain within which the workload application is hosted. Within this example there are three workloads, a gateway service, that accepts external clients and a CA/ credential service that issues workload identity credentials for the trust domain. External to the workload application system there is an application client that calls APIs on workloads. Here is a brief summary of each component * Trust Domain The large box represents a trust domain of the application that is composed of several workloads. A trust domain may have a more complex internal structure with more workloads, multiple gateways, internal infrastructure, and other services. * Workload Three workloads are shown. Each workload is an independently addressable software entity that may consist of one or more workload instances at runtime. Workloads obtain their identity credentials from a Credentials Service (1) and use them to authenticate to other workloads and systems in the process of sending and receiving requests to and from external systems or other internal workloads. * Gateway Service A gateway service acts as an intermediary between the internal application trust domain and external systems. By exposing external endpoints, it routes incoming requests to the correct internal workloads while ensuring appropriate isolation between the external and internal domains. To provide high availability, a gateway usually consists of multiple resilient instances. The gateway MAY also implement identity proxy functionality including authentication, token exchange, and token transformation. * CA/Credential Service In this diagram the token/Credential service is a service responsible for issuing workload identities to workloads in the same trust domain. The credentials are often X.509 certificate-based or JWT- based. High level flows within the diagram Salowey, et al. Expires 7 January 2027 [Page 9] Internet-Draft WIMSE Architecture July 2026 * (1) Workload Identity Credential Distribution Workloads typically retrieve their workload identity credentials early in their lifecycle from a credentials service associated with their trust domain. The protocol interaction for obtaining credentials varies with deployment and is not detailed here. * (2) Application client Requests Clients send API requests to the application. In the example above, the gateway routes the request to the correct workload. In addition, the gateway may assist in authenticating the incoming request and provide information resulting from the authentication to the target workload. The authentication exchange is not covered in detail in this example. The client request is typically made over HTTPS, but other protocols may be used in some systems. The gateway usually terminates the TLS session so it has visibility into the request in order to route it correctly. * (3) API request to workload 1 The gateway is configured to forward requests to the correct workload. The gateway often modifies the request to include specific authentication information about the application client and to remove any information that should not be forwarded internally. The gateway authenticates the workload before forwarding the request. This authentication usually uses TLS. The target workload may authenticate the gateway using TLS or some other means. As part of servicing the request the workload must make a request to another workload in the system. In this scenario the workload is making a request to workload 3 over HTTPS. Workload 1 may be able to authenticate the identity of workload 3 through the TLS protocol to ensure it is making a request of the right party. Workload 3 will authenticate workload 1 using its workload identity credentials. If the Workload Identity Credentials are workload identity certificates then this can happen through TLS client authentication (mutual TLS). Alternatively, the workloads can use a JWT based authentication mechanism to authenticate one another. Workload 3 can use the authenticated identity of workload 1 to determine which APIs workload 1 is authorized to invoke, and to associated the authenticated identity with logs and other audit information. * (4) API request to workload 2 Similarly to the previous flow, the gateway may determine that for another API call, the application client's request needs to be handled by workload 2. The case behaves the same as the previous flow except that the gateway may need to authenticate workload 2 Salowey, et al. Expires 7 January 2027 [Page 10] Internet-Draft WIMSE Architecture July 2026 before forwarding traffic to it. Workload 3 will then authorize and audit the request based on the authenticated identity of workload 2. Workload 2 and workload 1 may be authorized to use different APIs on workload 3. If workload 1 or 2 makes an API request that it is not authorized for, then workload 3 will reject the request. 3.2.2. Context and workload Identity +------------------------Trust Boundary---------+ | | .---+-. +----------------+ | | .---+-. | | | | | +------------------>| Context | | | | | (3) | | | | | |<------------------+ Service | | | | | (c) | | | | | G | +----------------+ | | | a | | (1) | | t | | +-------+ | | e | +------------+ +-------------+ | | App | (2) | | w | (4) | | (5) | | | | Client+---->| | a +----->| workload 1 +----->| workload 2 | | +-------+ (a) | | y | (c) | | (c) | | | | | | +------------+ +-------------+ | | | S | | | | e | | | | r | | | | v | | | | i | | | | c | | | | e | | '-+ | | '-+---' | | | | | | | +-----------------------------------------------+ Figure 2: Context example workload application system. In many cases the application system uses other security context information about the request during authorization and auditing. The following is a basic scenario that illustrates the propagation of security context in the workload system. Some of the components and interactions have been removed from the previous scenario for simplicity. Salowey, et al. Expires 7 January 2027 [Page 11] Internet-Draft WIMSE Architecture July 2026 * Context Service This scenario adds a context service component which is responsible for creating security context based on authentication and other calculations. Context can be represented in many ways; it can be a plaintext data structure, a signed data structure such as a JWT or a pointer used to lookup the context as a data structure stored somewhere else. In one common example, creating the context may involve a token exchange converting an OAuth 2.0 access token into a different token format, such as a transaction token, that is understood by internal services. * (1) Initial Authentication In the initial authentication the gateway service obtains credentials it can use with the gateway service. This authentication may involve several steps and may be performed by an external entity such as an identity provider. The authentication process will result in a credential that the gateway service can evaluate. For example, the credential could be an OAuth Access token. If the client already has an access token that it can use to authenticate to the gateway, such as an X.509 certificate, then it may skip this step. * (2) Application Client Request The application client makes a request to the gateway over HTTPS. The client may be authenticated to the gateway through TLS client authentication (mutual TLS) or through a credential such as an access token obtained in step 1. * (3) Establishing the request context The gateway service requests a security context token (c) from a token service. This process may entail sending an access token (a) along with other information to a token exchange endpoint to obtain the context token, which contains information about the entity accessing the system. This context is typically only relevant to the internal system and is not returned to the client. The gateway may use alternative mechanisms to get the internal security context information (c). * (4) Forwarding Request to Workload The gateway forwards the request along with the context information (c) to the appropriate workload. A bearer token, such as an access token (a), is not usually forwarded as it is only meant for external access. The workload uses information in the context token in applying authorization policy to the application client's request. If the workload does not receive a context token, then it will deny requests that rely on information from the token. * (5) Making Additional Workload Originated Requests The workload may need to make requests of other workloads. When making these requests, the workload includes the context information so Salowey, et al. Expires 7 January 2027 [Page 12] Internet-Draft WIMSE Architecture July 2026 Workload 2 can authorize and audit the request. Workload 2 may have a policy requiring Workload 1 to authenticate its service identity and provide valid context information (c) to access certain APIs. 3.2.3. Cross-Domain Communication +---------------------------Trust Boundary------+ | | .---+-. | | .---+-. | | | | | | | G | | | | a | | | | t | | +-------+ | | e | +------------+ +-------------+ | | App | (1) | | w | (2) | | (4) | | | | Client+---->| | a +----->| workload 1 +----->| workload 2 | | +-------+ (a) | | y | (c) | | (c) | | | | | | +-+----------+ +^----^----+--+ | | | S | | | | | | | | e | (3)| (5)(c)|(t) | | | | | r | | | | | | | | v | | +-+--------v+ | | | | | i | | | Token | | | | | | c | | | | | (7)|(a) | | | e | | | Service | | | | '-+ | | +-----------+ | | | '-+---' | | | | | | | | | | | (6)(t)|(a) | | | | | | | +------------+-----------------------+----+-----+ | | | | +-+-------V-+ | | | External | | | | Token | | | | Service | | | +-----------+ | | | +---------v------+ +---------------v-+ | Infrastructure | | External | | | | | | Service | | Service | +----------------+ +-----------------+ Figure 3: External request workload application system. Salowey, et al. Expires 7 January 2027 [Page 13] Internet-Draft WIMSE Architecture July 2026 In many applications workloads must make requests of infrastructure or external services that operate as a different trust domain. Steps 5-7 of Figure 3 involve a generic cross domain pattern as described in [I-D.draft-ietf-oauth-identity-chaining]. This document refers to a token service which performs a similar functions with respect to token issuance as the authorization service in [I-D.draft-ietf-oauth-identity-chaining]. The scenario shows some new components described below. Components and interactions from previous scenarios are still relevant to this example, but are omitted for simplicity. * Token Service - the token service is responsible for exchanging information that is internal to the system such as service identity and/or security context information for a token that can be presented to an external token service in another trust domain to gain access to infrastructure or an external service. * External Token Service - the external token service is part of another trust domain. Workloads in the originating trust domain contact this service to get an access token to authenticate to external services. * Infrastructure Service - this service is often part of the application, but it is managed by an infrastructure provider and may require different information to access it. * External Service - this service is distinct from the application and hosted in a separate trust domain. This trust domain often has different access requirements that workloads in the internal trust domain. Some example interactions in this scenario: * (1) The application client is making requests with authentication information as in the other scenarios * (2) The gateway forwards the request to the appropriate workload with the security context information * (3) The workload needs to access an infrastructure service and, because there is an established trust relationship, it authenticates to the service directly using its workload credentials. * (4) Workload 1 contacts Workload 2 to perform an operation. This request is accompanied by a security context as in the other scenarios. Salowey, et al. Expires 7 January 2027 [Page 14] Internet-Draft WIMSE Architecture July 2026 * (5) Workload 2 determines it needs to communicate with an external service. In order to gain access to this service it must first obtain a token/credential (t) that it can use externally. It authenticates to the token service using its workload identity credential (c) and provides security context information. The token service determines what type of externally usable token to issue to the workload for use with the external token service. * (6) Workload 2 uses this new token/credential (t) to request an access token (a) for the external service from the token service. * (7) Workload 2 uses the access token (a) to access the external service in the other trust domain. There can be variations on cross domain workflows. For example, in step 3 the workload was able to use its Workload Identity Credentials to directly access an infrastructure service. It also may be possible for an workload to request an access token for an external service using its Workload Identity Credentials directly with an external token service. 3.3. Message Flow and Policy Enforcement in the Basic Scenario The basic workload identity scenario described in Section 3.2.1 and illustrated in Figure 1 already sketches a trust domain, a gateway, a CA/credential service, and how an application client reaches multiple workloads. This section takes the same scenario and adds one level of detail for a single workload-to-workload hop: a caller and a callee, identity established with workload identity credentials, and a separate authorization step that may involve policy components. In this view, the component enforcing authorization policy acts as a Policy Enforcement Point (PEP): it allows a request to proceed, blocks it, or applies obligations based on the authenticated peer identity and any relevant security context. A deployment may also use a Policy Decision Point (PDP), to which the enforcing component delegates policy evaluation. Deployments may implement PEP and PDP as separate services, co-locate them with a gateway or sidecar, or embed them in the receiving workload. This document does not define a particular policy language or protocol between PEP and PDP. The diagram below is illustrative rather than normative. It shows one common logical layout for how provisioning, connection setup, application-layer authentication, authorization, and response relate when two workloads communicate. Salowey, et al. Expires 7 January 2027 [Page 15] Internet-Draft WIMSE Architecture July 2026 +------------+ +------------+ | | (2) | | | |<=============>| | | | | | | Workload A | (3) | Workload B | | |==============>| | | | | | | | (5) | +--------+ | |<==============| | PEP | +------------+ +---+--------+ ^ ^ ^ | (1) | | (1) | +----------------------+ | (4) | | | v v v +------------+ +------------+ | | | | | CA/ | | PDP | | Credential| | (optional) | | Service | | | +------------+ +------------+ Figure 4: Logical message flow and policy points (drill-down of the basic scenario). The CA/credential service issues workload identity credentials; workloads obtain them before using those credentials for authentication. Provisioning details vary by deployment. The PEP is shown as a logical function associated with the callee-side request path. It may be implemented inside Workload B, in a sidecar, in a gateway, or in another component on the request path, as in Figure 1. The high-level message flow is as follows: 1. Workload A and Workload B each obtain a workload identity credential from the CA/credential service before using that credential for authentication. The timing, lifetime, and refresh behavior of these credentials are deployment-specific. Normally credentials operate on a slower lifecycle than application requests. 2. A transport connection is set up for the call. It may use mutual TLS and workload identity certificates, or another transport security mechanism. Salowey, et al. Expires 7 January 2027 [Page 16] Internet-Draft WIMSE Architecture July 2026 3. Workload A sends a request to Workload B. This may include application-layer authentication using a Workload Identity Token and proof of possession, as defined in the credentials and protocol documents. Workload B authenticates Workload A. 4. Workload B authorizes the request. The PEP enforces the decision, optionally consulting a PDP. Policy details and message-level authorization formats are out of scope for this architecture. 5. Workload B returns a response to Workload A, which may be an error or success. Depending on the protocol binding, peer authentication may occur during step (2) at the transport layer, during step (3) at the application layer, or both, as in the other scenarios in this section. 3.4. Workload Identity Use Cases 3.4.1. Bootstrapping Workload Identifiers and Credentials Workloads need to obtain credentials before they can fully participate in the WIMSE architecture. The architecture does not specify a particular method for credential provisioning, but this section outlines some concepts involved in this process. WIMSE focuses on credentials that consist of a public token and a private key such as X.509 certificate and Workload Identity Token (WIT). This list is not exhaustive of all the ways provisioning can happen. * Direct Provisioning - A workload may receive its WIMSE credential when it is initially created. This is typically done using a deployment-specific mechanism that configures both the private and public portions of the credential for the workload. In direct provisioning the workload does not need to go through additional processes to obtain credentials and the credentials can be used immediately, whereas in the other cases more interactions are needed to obtain usable credentials. Salowey, et al. Expires 7 January 2027 [Page 17] Internet-Draft WIMSE Architecture July 2026 * Bootstrap Credentials - A workload may receive a set of bootstrap credentials specific to its deployment mechanism, which are then used by the workload through another process to obtain WIMSE credentials. The workload may use the bootstrap credentials to obtain the private and public parts of the WIMSE credentials, or the workload may generate a private key pair and use the bootstrap credential to authorize an enrollment process to obtain the public credential (X.509 certificate or WIT). [I-D.ietf-wimse-workload-identity-practices] describes some ways workloads can be initially providioned with bootstrap credentials. * Attestation - A workload credential provisioning process may use attestation in addition to or instead of bootstrap credentials. Attestation refers to the process of one peer in a communication (known as an "attester") generating attestation evidence, and providing that to a communication peer -- the "relying party", who may request verification of the supplied evidence from a "verifier". The Remote ATtestation procedureS (RATS) Architecture [RFC9334] describes evidence and some of the different communication patterns. Attestation in WIMSE is intentionally defined quite broadly, as it may be implemented in several ways that, while aligned with the definitions and architectures described in [RFC9334], and here, do not rely on any specific implementation, or any specific communication protocol. [SPIRE] provides an example outside of the RATS protocol work where attestation processes result in credentials being provisioned both to workloads, and the nodes that host them. * Agent Assisted Provisioning - In some architectures, several workloads run on the same node that hosts an agent that assists in the credential provisioning process. The example below illustrates one way in which an agent can participate in the process, reflecting some concepts in the SPIFFE architecture. There are other ways an agent may participate. For example, the agent may not receive direct access to the workload private key but it may be the conduit for providing an encrypted private key which the workload can decrypt through a process that may involve attestation. 3.4.1.1. Agent Assisted Provisioning Example Figure 5 illustrates software layering at a host running workloads. During startup, workloads bootstrap their identifiers and credentials with the help of an agent. The agent may be associated with one or more workloads to help ensure that workloads are provisioned with the correct identifiers and credentials. The agent provides attestation evidence and other relevant information to a server. The server validates this information and provides the agent with identifiers Salowey, et al. Expires 7 January 2027 [Page 18] Internet-Draft WIMSE Architecture July 2026 and credentials for the workloads it is associated with. The server can use a variety of internal and external means to validate the request against policy. After obtaining credentials from the server, the agent passes them to the workload. +-----------------+ | Server | | | | +-------------+ | | | Attestation | | | +-------------+ | +---------+-------+ ^ | . . | | Identity | | Workload | | Credentials | | to | | | | Workload | | | | Communication +-------+-+------------------------------+-+-----------+ | | | v V | | | v +----------------+ | | +----+----------+ +-+--------------+ | | | | Agent | | Workloads | | | | | <+--------------+> | | | | | ^ | Identity | ^ +-+ | | +------------+--+ Credentials +--+-------------+ | | | | | | | | Identity | | Attestation | | Credentials | | v v | +------------------------------------------------------+ | Host Operating System and Hardware | +------------------------------------------------------+ Figure 5: Host Software Layering in a Workload Identity Architecture. How the workload obtains its identity credentials and interacts with the agent is subject to different implementations. Some common mechanisms for obtaining this initial identity include: * File System - In this mechanism, the identity credential is provisioned to the workload via the filesystem. * Local API - The identity credential is provided through an API, such as a local domain socket (for example, SPIFFE or QEMU guest agent) or network API (for example, Cloud Provider Metadata Server). Salowey, et al. Expires 7 January 2027 [Page 19] Internet-Draft WIMSE Architecture July 2026 * Environment Variables - Identity credentials may also be injected into workloads using operating system environment variables. 3.4.2. Workload and Service Authentication One of the most basic use cases for workload identity is authentication of one workload to another. In many deployments, this is described operationally as one service making a request to another service as part of a larger, more complex application. The identifier in the credentials may identify a logical service, a workload that implements that service, or a specific workload instance, depending on the identity model chosen by the issuing trust domain. Following authentication, the identity of the peer can be used to enforce fine-grained authorization policies as described in Section 3.4.4 and generate audit trails as described in Section 3.4.5. Authentication mechanisms are used to establish the identity of the peer before secure communication can proceed. The peer identity is carried in a workload identity credential, even when the credential represents a service-level identity rather than a particular workload instance. Workloads often obtain their credentials without relying on pre- provisioned long-lived secrets. Instead, short-lived credentials are established through mechanisms provided by the infrastructure that allow a workload to prove it is running in a given environment. Common delivery patterns are described in Section 3 of [I-D.ietf-wimse-workload-identity-practices]. Once credentials are issued, they are conveyed to peers using common security protocols. Typical mechanisms include: * Mutual TLS authentication using X.509 certificate for both client and server as described in Section 4 of [I-D.ietf-wimse-s2s-protocol]. * Application-layer authentication using cryptographic credentials passed within HTTP message as described in Section 3 of [I-D.ietf-wimse-s2s-protocol]. These mechanisms can also be used together. For example, a workload identity certificate can be used for transport-layer authentication to an intermediary, while an application-layer Workload Identity Token is used to authenticate the caller to the destination workload, as described in Section 3.4.3. Salowey, et al. Expires 7 January 2027 [Page 20] Internet-Draft WIMSE Architecture July 2026 These authentication mechanisms establish a cryptographically verifiable identity for the communicating party, which can then be used for further policy enforcement. Figure 6 illustrates communication between workloads and services. Two aspects are important to highlight: First, there is a need to consider the interaction with workloads that are external to the trust domain (sometimes called cross-domain). Second, the interaction does not only occur between workloads that directly interact with each other but instead may also take place across intermediate workloads (in an end-to-end style). +-----------------+ | Workload | | (external) | | ^ | +-------+---------+ | | +-------+-------------------------Trust Boundary---------------+ | | | | | | | +----+------+ Hop-by- +-----------+ Hop-by- +-----------+ | | | v | Hop | | Hop | | | | | Workload | Security | Workload | Security | Workload | | | | <+----------+> <+----------+> | | | | | | | | | | | | | | | | | | | | O<-----+----------+-----------+----------+---->O | | | +-----------+ E2E +-----------+ E2E +-----------+ | | | | | +--------------------------------------------------------------+ Figure 6: Workload-to-Workload Communication. 3.4.3. Layered Workload Authentication Some deployments use workload identity credentials at more than one layer of the communication stack. For example, a workload might use a workload identity certificate with TLS to authenticate to a proxy, gateway, load balancer, or service mesh sidecar, while also using an application-layer Workload Identity Token (WIT) or similar credential to authenticate to the destination workload. This pattern is common when infrastructure components terminate or originate transport connections on behalf of workloads. In such deployments, the transport-layer credential authenticates the Salowey, et al. Expires 7 January 2027 [Page 21] Internet-Draft WIMSE Architecture July 2026 workload, proxy, gateway, or sidecar for the purpose of establishing a secure channel across a particular network segment. The application-layer credential authenticates the workload identity that is relevant to the receiving application. These two authentication events may involve different peers, different trust anchors, and different authorization policies. Transport-layer Transport-layer authentication authentication +------------+ (e.g., TLS) +---------+ (e.g., TLS) +------------+ | |<---------------->| |<---------------->| | | Workload A | | Proxy | | Workload B | | | | Gateway | | | +-----+------+ +---------+ +------+-----+ ^ ^ | | | Application-layer authentication and context | +=============================================================+ (e.g., WIT with proof of possession) Figure 7: Layered workload authentication through an intermediary. For example, Workload A may establish a mutually authenticated TLS connection to a gateway using a workload identity certificate. The gateway validates that Workload A is permitted to use the gateway and then forwards the request toward Workload B. Because the TLS connection from Workload A is terminated at the gateway, Workload B cannot rely solely on that transport-layer authentication to identify Workload A. Workload A can therefore include an application-layer credential, such as a WIT, allowing Workload B to authenticate the workload identity of the caller at the application layer. The workload identifiers used at different layers do not necessarily need to be identical. The transport-layer credential might identify a workload instance, node-local proxy, sidecar, or gateway, while the application-layer credential might identify the logical workload or service on whose behalf the request is made. Deployments need to define this relationship in policy, including when identifiers are expected to match, when one authenticated entity is allowed to act on behalf of another, and when the identities represent different roles in the request path. If intermediaries are allowed to inspect, replace, or augment workload identity or security context information, that behavior needs to be explicit and auditable. Layered authentication can improve security by allowing infrastructure components to authenticate and authorize use of the network path while allowing destination workloads to authenticate and authorize the application-layer caller. However, it can also Salowey, et al. Expires 7 January 2027 [Page 22] Internet-Draft WIMSE Architecture July 2026 introduce ambiguity if the identities are interpreted incorrectly. In particular, a destination workload MUST NOT assume that a transport-layer identity authenticated by an intermediary is the same as the application-layer caller identity unless that relationship is explicitly established by protocol or deployment policy. Audit records for layered authentication SHOULD record both the transport-layer identity and the application-layer identity when both are available and relevant. This allows operators to distinguish the workload or infrastructure component that established the secure channel from the workload or service identity used for application- layer authorization. 3.4.4. Service Authorization Once authentication has successfully established the identity of a peer, authorization mechanisms determine whether the authenticated identity is permitted to perform the requested action on the target workload or service. The authenticated identity may represent a logical service, a workload, or a specific workload instance, and authorization policy needs to be written with this distinction in mind. Authorization specified by WIMSE is context-aware. It relies on attributes carried in the security context, which may originate from upstream systems such as gateways or identity proxies. This context may be derived from end-user attributes, trust domain policies, or deployment-specific metadata (e.g., environment, service role, workload instance). Authorization decisions typically include: * Validating the integrity and provenance of the security context. * Ensuring the authenticated identity has the correct role and attributes to access the requested API or resource. * Applying fine-grained policy rules, which may include path, method, action type, and contextual constraints (e.g., geographic location, time of day). Authorization checks may also incorporate delegation and impersonation semantics, as described in Section 3.4.7, where upstream workloads are authorized to act on behalf of end-users or other services, within the scope of their issued credentials and policy. Salowey, et al. Expires 7 January 2027 [Page 23] Internet-Draft WIMSE Architecture July 2026 A key architectural consideration is where authorization is evaluated. For most workload-to-workload or service-to-service interactions (e.g., REST APIs, gRPC, or pub/sub flows), authorization is performed by the callee, ensuring that the target workload or service enforces its own access policies. But in some scenarios, such as database access or operations on complex back-end systems, authorization decisions may be too fine-grained or application- specific to be enforced by the subject of the operation. In these cases, authorization MAY be performed by the caller, provided that the caller has sufficient context and policy information to make a correct decision. 3.4.5. Audit Trails Auditability is a critical requirement in systems that rely on workload identities and security context. Each authenticated request MUST leave a verifiable and inspectable trace regardless of authentication and authorization decision. Audit trails are typically generated at multiple points: * Gateway Services: Log incoming client requests, their authenticated identities and relevant context. * Workloads: Log authenticated peer identities, security context attributes, requested resources, and authorization outcomes. * Identity and Token Services: Log issuance and validation events for workload identity credentials and context tokens. Audit records may include: * Timestamp of the request * Source workload identifier * Target workload identifier * Authentication method used * Decision outcome (authorized/denied) * Security context claims * Delegation/impersonation metadata (if present) Salowey, et al. Expires 7 January 2027 [Page 24] Internet-Draft WIMSE Architecture July 2026 To avoid inadvertent disclosure of sensitive information, workloads and services generating audit logs MUST NOT log secrets such as bearer tokens, private keys, or passwords. If logging of credential- related data is necessary for diagnostic or policy purposes, these values MUST be redacted, hashed, or otherwise sanitised to prevent misuse. WIMSE systems SHOULD ensure audit logs are tamper-evident and securely stored. Logs may be forwarded to centralized security information and event management (SIEM) systems to enable compliance, threat detection, and incident response. 3.4.6. Security Context Establishment and Propagation In a typical system of workloads additional information is needed in order for the workload to perform its function. For example, it is common for a workload to require information about a user or other entity that originated the request. Other types of information may include information about the hardware or software that the workload is running or information about what processing and validation has already been done to the request. This type of information is part of the security context that the workload uses during authorization, accounting and auditing. This context is propagated and possibly augmented from workload to workload using tokens. The context may be associated with a specific source or target workload by binding it to a specific workload identifier. This may indicate that the context originated from a specific workload, or that only a specific workload may make use of the context. A workload may also use a workload identity credential to bind a context to one or more transaction so the receiver can verify which workload initiated the transaction and the context that was intended for the transaction. 3.4.7. Delegation and Impersonation Workloads may need to impersonate or act on behalf of another principal in the system. In these scenarios, the workload typically authenticates using its workload identity to a token service, as described in [OAUTH-TOKEN-XCHANGE]. The token service then issues a token that can be used for delegation and impersonation. In many cases, this will not be an identity credential, but rather an authorization or context credential that delegates authority or permits impersonation for specific actions. This token may be bound to a workload identity as described in Section 4.3. Salowey, et al. Expires 7 January 2027 [Page 25] Internet-Draft WIMSE Architecture July 2026 3.4.8. Accessing Resources in Other Trust Domains When source workloads send authenticated requests to destination workloads or services, those destination workloads may rely on upstream dependencies to fulfill such requests. Such access patterns are increasingly common in a microservices architecture. While X.509 certificates can be used for point-to-point authentication, services that rely on upstream workloads for answers may use delegation and/or impersonation semantics as described in [OAUTH-TOKEN-XCHANGE]. WIMSE credentials constrain the subjects and actors identified in delegation and impersonation tokens to be bound by a trust domain, and to follow their issuing authorities' trust configurations. Upstream workloads should consider the security context of delegation and/or impersonation tokens within and across trust domains, when arriving at authorization decisions. 3.4.9. Asynchronous and Batch Requests Source workloads may send authenticated asynchronous and batch requests to destination workloads or services. A destination workload may need to fulfill such requests with requests to authorized upstream protected resources and workloads after the source workload credentials have expired. Credentials identifying the original source workload or service as subject may need to be obtained from the credential issuing authority with appropriately down-scoped context needed to access upstream workloads. These credentials should identify the workload performing the asynchronous computation as the actor in the actor chain, but may also identify other principals that the action is taken on behalf of. To mitigate risks associated with long-duration credentials, these credentials should be bound to the Workload Identity Credential, such as a workload identity certificate or Workload Identity Token (WIT), of the acting workload or service. 3.4.10. Cross-boundary Workload Identity As workloads often need to communicate across trust boundaries, extra care needs to be taken when it comes to identity communication to ensure scalability and privacy. (TODO: align with OAuth cross domain identity and authorization) Salowey, et al. Expires 7 January 2027 [Page 26] Internet-Draft WIMSE Architecture July 2026 3.4.10.1. Egress Identity Generalization A workload communicating with a service or another workload located outside the trust boundary may need to provide modified identity information. The detailed identity of an internal workload instance, or of the internal workload that originated the communication, is often relevant inside the trust boundary but could be excessive for the outside world and expose potentially sensitive internal topology information. For example, in a microservices architecture, an internal service may use workload-specific identities that include fine-grained details such as instance names or deployment-specific attributes. When interacting with external systems, exposing such details may inadvertently provide attackers with insights into the internal deployment structure, scaling strategies, security policies, technologies in use, or failover mechanisms, potentially giving them a tactical advantage. In such cases, an identity proxy at the trust boundary can generalize the Workload Identity by replacing the specific microservice instance name with the name of the overall service. This allows external parties to recognize the service while abstracting internal deployment details. A security gateway implementing Identity Proxy functionality at the edge of a trust boundary can validate identity information of the workload, perform context-specific authorization of the transaction, and replace workload-specific identity with a generalized one for a given trust domain. This approach ensures that external communications adhere to security and privacy requirements while maintaining interoperability across trust boundaries. 3.4.10.2. Inbound Gateway Identity Validation Inbound security gateway is a common design pattern for service protection. This functionality is often found in CDN services, API gateways, load balancers, Web Application Firewalls (WAFs) and other security solutions. Workload identity verification of inbound requests should be performed as a part of these security services. After validation of workload identity, the gateway may either leave it unmodified or replace it with its own identity to be validated by the destination. Salowey, et al. Expires 7 January 2027 [Page 27] Internet-Draft WIMSE Architecture July 2026 3.4.11. AI and ML-Based Intermediaries Emerging agentic AI systems and other ML-based intermediaries introduce new considerations for workload identity and security context propagation. These systems often act as autonomous agents that perform tasks on behalf of an upstream principal (such as a user or service) and then invoke downstream workloads as part of multi- step workflows. From WIMSE perspective, AI intermediaries are a special case of delegated workloads (see Section 3.4.7). They inherit the upstream principal's security context and are expected to operate strictly within the constraints of that delegation. When invoking downstream workloads, the agent SHOULD propagate the upstream security context, unless it has been explicitly authorized to translate or reduce its scope. In some cases, AI systems may generate requests that are not attributable to a specific upstream principal. Such autonomous actions MUST be clearly distinguished from delegated ones, for example by using separate workload identities or token scopes. Because AI intermediaries may chain requests across multiple services, there is an elevated risk of privilege escalation if security context is propagated beyond the intended trust domain. Mechanisms such as cryptographic binding of delegation tokens or attestation of intermediary behavior can help mitigate these risks. A further consideration arises when AI agents interact with other AI agents. In these cases, each agent may act both as a delegated workload and as a delegator, creating multi-hop delegation chains. To avoid ambiguity, each hop in the chain MUST explicitly scope and re-bind the security context so that downstream services can reliably evaluate provenance and authorization boundaries. Without such controls, there is a risk that a chain of AI-to-AI interactions could unintentionally extend authority far beyond what was originally granted. +---------+ +-------------+ +-------------+ +-------------+ | User / +------->| AI Agent +------->| AI Agent +------->| Workload | | Service | | (Agent A) | | (Agent B) | | Downstream | +---------+ +-------------+ +-------------+ +-------------+ | | | | | Initial | Delegated / Scoped | Delegated / Scoped | | Security Context | Security context | Security context | +------------------->+--------------------->+--------------------->| Figure 8: AI agent communication Salowey, et al. Expires 7 January 2027 [Page 28] Internet-Draft WIMSE Architecture July 2026 4. Security Considerations 4.1. Traffic Interception Workloads communicating with applications may face different threats to traffic interception in different deployments. In many deployments security controls are deployed for internal communications at lower layers to reduce the risk of traffic observation and modification for network communications. When a security layer, such as TLS, is deployed in these environments. TLS may be terminated in various places, including the workload itself, and in various middleware devices, such as load balancers, gateways, proxies, and firewalls. Therefore, protection is provided only between each adjacent pair of TLS endpoints. There are no guarantees of confidentiality, integrity and correct identity passthrough in those middleware devices and services. 4.2. Information Disclosure Observation and interception of network traffic is not the only means of disclosure in these systems. Other vectors of information leakage is through disclosure in log files and other observability and troubleshooting mechanisms. For example, an application may log the contents of HTTP headers containing JWT bearer tokens, user names, email addresses and other sensitive information. The information in these logs may be made available to other systems with less stringent access controls, which may result in this information falling into an attackers hands. This creates privacy risks and potential surface for reconnaissance attacks. 4.3. Workload Identity Binding to Tokens Section 3.4.6 describes that one or more workload identities may be incorporated into a security context token to constrain the use of that token. This workload identity binding may restrict which workloads can present the token or which workloads may consume the token. Workload identity binding can also be used with types of tokens other than security context tokens. Workload identity binding reduces the impact of a stolen token or compromised workload. 4.4. Credential Theft When the information disclosed to an attacker is a credential, the attacker may be able to use that credential to escalate their privilege, attack another system via lateral movement within the organization or to impersonate a workload. Bearer credentials are particularly vulnerable to disclosure since they are communicated between systems and may be revealed in communication channels or Salowey, et al. Expires 7 January 2027 [Page 29] Internet-Draft WIMSE Architecture July 2026 application logs. Credentials bound to a cryptographic key are typically less vulnerable because the key is not disclosed in the authentication process. However, care must still be taken to prevent disclosure during key management operations. Private keys associated with workload identity credentials require appropriate lifecycle management. Deployments should protect these keys using platform mechanisms appropriate to the environment, limit the lifetime of credentials associated with the keys, rotate or replace key pairs periodically, and revoke or stop accepting credentials associated with keys that are suspected to be compromised. Long-running workload instances need a renewal mechanism that allows credentials and keys to be replaced without relying on long-lived static secrets. 4.5. Authentication and Authorization Authentication of a workload establishes that the presenter controls the key material associated with the credential and that the credential was issued under the authority of a trusted issuer. This is not sufficient, by itself, to determine whether the workload is permitted to access a resource or perform a requested action. Access control requires a separate authorization decision. That decision needs to take into account the authenticated workload identity, the requested resource or operation, the applicable policy, and any relevant security context. The fact that a workload has a valid credential does not imply that it is authorized for all resources in the trust domain. Issuers, relying parties, gateways, and workloads need to avoid treating successful authentication as implicit authorization. 4.6. Workload Compromise Even the most well-designed and implemented workloads may contain security flaws that allow an attacker to gain limited or full compromise. For example, a server side request forgery may result in the ability for an attacker to force the workload to make requests of other parts of a system even though the rest of the workload functionality may be unaffected. An attacker with this advantage may be able to utilize privileges of the compromised workload to attack other parts of the system. Therefore it is important that communicating workloads apply the principle of least privilege through security controls such as authorization. Salowey, et al. Expires 7 January 2027 [Page 30] Internet-Draft WIMSE Architecture July 2026 5. IANA Considerations This document has no IANA actions. 6. References 6.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, . [RFC7517] Jones, M., "JSON Web Key (JWK)", RFC 7517, DOI 10.17487/RFC7517, May 2015, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [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, . [WIMSE-ID] Rosomakho, Y. and J. A. Salowey, "Workload Identifier", Work in Progress, Internet-Draft, draft-ietf-wimse- identifier-03, 6 July 2026, . 6.2. Informative References [I-D.draft-ietf-oauth-identity-chaining] Schwenkschuster, A., Kasselman, P., Burgin, K., Jenkins, M. J., Campbell, B., and A. Parecki, "OAuth Identity and Authorization Chaining Across Domains", Work in Progress, Internet-Draft, draft-ietf-oauth-identity-chaining-16, 26 June 2026, . [I-D.ietf-oauth-transaction-tokens] Tulshibagwale, A., Fletcher, G., and P. Kasselman, "Transaction Tokens", Work in Progress, Internet-Draft, draft-ietf-oauth-transaction-tokens-09, 6 July 2026, . Salowey, et al. Expires 7 January 2027 [Page 31] Internet-Draft WIMSE Architecture July 2026 [I-D.ietf-wimse-s2s-protocol] Campbell, B., Salowey, J. A., Schwenkschuster, A., and Y. Sheffer, "WIMSE Workload-to-Workload Authentication", Work in Progress, Internet-Draft, draft-ietf-wimse-s2s- protocol-07, 16 October 2025, . [I-D.ietf-wimse-workload-identity-practices] Schwenkschuster, A. and Y. Rosomakho, "Workload Identity Practices", Work in Progress, Internet-Draft, draft-ietf- wimse-workload-identity-practices-05, 30 June 2026, . [OAUTH-TOKEN-XCHANGE] Jones, M., Nadalin, A., Campbell, B., Ed., Bradley, J., and C. Mortimore, "OAuth 2.0 Token Exchange", RFC 8693, DOI 10.17487/RFC8693, January 2020, . [RFC9683] Fedorkow, G. C., Ed., Voit, E., and J. Fitzgerald-McKay, "Remote Integrity Verification of Network Devices Containing Trusted Platform Modules", RFC 9683, DOI 10.17487/RFC9683, December 2024, . [SPIFFE] "Secure Production Identity Framework for Everyone (SPIFFE)", May 2023, . [SPIFFE-ID] "The SPIFFE Identity and Verifiable Identity Document", May 2025, . [SPIRE] "SPIRE Concepts", n.d., . Acknowledgments Todo: Add your name here. Salowey, et al. Expires 7 January 2027 [Page 32] Internet-Draft WIMSE Architecture July 2026 Changes since draft -05 * Update to gateway service definition and diagram * alignment of cross-domain scenario with OAUTH cross-domain chaining * rework of authentication section * added audit section * added AI use case Changes since draft -06 * Separated Workload from Workload Instance * Moved workload identifier definition to a separate draft * Update credential provisioning section * Add Section 3.3: message flow and PEP/PDP drill-down of the basic scenario, before use cases Authors' Addresses Joseph Salowey Palo Alto Networks Email: joe@salowey.net Yaroslav Rosomakho Zscaler Email: yaroslavros@gmail.com Hannes Tschofenig University of the Bundeswehr Munich 85577 Neubiberg Germany Email: hannes.tschofenig@gmx.net Salowey, et al. Expires 7 January 2027 [Page 33]