]> Zscaler

yaroslavros@gmail.com

Palo Alto Networks

joe@salowey.net

Workload Identity in Multi System Environments workload identifier This document defines a canonical identifier for workloads, referred to as the Workload Identifier. A Workload Identifier is a URI that uniquely identifies a workload within the context of a specific trust domain. This identifier can be embedded in Workload Identity Credentials, including X.509 certificates and JWT-based tokens, to support authentication, authorization, and policy enforcement across diverse systems. The Workload Identifier format ensures interoperability, facilitates secure identity federation, and enables consistent identity semantics. About This Document The latest revision of this draft can be found at . Status information for this document may be found at . Discussion of this document takes place on the Workload Identity in Multi System Environments mailing list (), which is archived at . Subscribe at . Source for this draft and an issue tracker can be found at .

Introduction In modern distributed systems, workloads such as services, applications, or containerized tasks require cryptographically verifiable identities to support secure communication, access control, and auditability. As systems scale across trust domains, administrative boundaries, and heterogeneous platforms, the need for a consistent and interoperable identifier format becomes critical. This document defines the Workload Identifier, a URI-based identifier intended to uniquely represent a workload within the context of an issuing authority. The identifier is designed to be stable, unique within a given trust domain, and suitable for use in digital credentials such as X.509 certificates, JSON Web Tokens (JWTs ), and other security artifacts. The Workload Identifier format is simple yet expressive. It enables organizations to define trust boundaries, delegate identity management, and identify workload instances and logical workloads in a uniform way across service meshes, cloud environments, and on-premises infrastructure. This specification defines the Workload Identifier used by the Workload Identity in Multi-System Environments (WIMSE) architecture . The format is defined in a general manner so that it can also be used by other systems that require stable, URI-based workload identifiers. The primary goals of this specification are:

• To define the syntax and semantics of a Workload Identifier.
• To establish requirements for issuers and consumers of such identifiers.
• To promote interoperability across different identity systems and domains.

This document does not prescribe how identifiers are issued or verified. Instead, it focuses on the identifier's format, uniqueness guarantees, and its relationship to trust domains.

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 when, and only when, they appear in all capitals, as shown here.

Terminology The following terms are used throughout this document:

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 Identifier:

A URI-based identifier assigned to a workload. A Workload Identifier can refer to a logical workload consisting of multiple instances, or to a specific workload instance, depending on the policy of the trust domain. The identifier is intended to be included in Workload Identity Credentials () and interpreted as a complete URI according to the applicable URI scheme and policy of the trust domain.

Trust Domain:

A logical grouping of systems that share a common set of security controls and policies. A trust domain establishes its own rules for identity issuance, validation, and policy enforcement.

Issuer:

An entity authorized by a trust domain to assign Workload Identifiers.

Consumer:

An entity that evaluates, verifies or uses a Workload Identifier for authentication, authorization, or auditing purposes, typically after obtaining it from a validated Workload Identity Credential. This includes relying parties, verifiers, and policy enforcement points.

Workload Identifier Specification A Workload Identifier is a URI that uniquely identifies a workload. It encodes both the trust domain and a workload-specific path, enabling unambiguous identification of workloads across administrative and organizational boundaries. Since there is no global authority for trust domains, trust domains must be validated as described in . The identifier is designed to be stable and suitable for inclusion in digital credentials such as X.509 certificates and security tokens. This section defines the format, structure, and associated requirements for Workload Identifiers.

 URI Requirements A Workload Identifier MUST be an absolute URI, as defined in . In addition, the URI MUST include a non-empty authority component that identifies the trust domain within which the identifier is scoped. A Workload Identifier MUST contain a non-empty path component. A Workload Identifier MUST NOT contain a path segment that is "." or "..", either literally or after decoding percent-encoded unreserved characters. Consumers MUST reject such identifiers before performing dot-segment removal. The URI format allows different schemes (e.g., spiffe as defined in , wimse defined in ) depending on deployment requirements. Example identifiers: A Workload Identifier URI MUST NOT contain a query component, a fragment component, user information, or a port component. Implementations that generate, parse, or otherwise process Workload Identifiers MUST support identifiers with a total length of at least 2048 bytes. Workload Identifiers SHOULD NOT exceed 2048 bytes in length. Individual Workload Identifier schemes MAY define additional syntax or processing requirements, provided they do not conflict with the requirements defined in this document.

Scheme Specific Portion This specification defines common requirements for Workload Identifiers and the wimse URI scheme (). Trust domains are opaque strings formatted according to , subject to the URI syntax and normalization rules defined in this document. A particular scheme may define additional semantics and constraints for the trust domain. The same trust domain may have different meaning within different schemes. The structure of the path component can be constrained by the scheme. Its contents are deployment-specific and are interpreted according to the scheme and the policy of the trust domain, as implemented by the issuer or issuers authorized for that trust domain. The issuer defines the granularity at which identifiers are assigned. A Workload Identifier MAY represent a specific workload instance, or a logical workload consisting of multiple instances that share the same identity within the trust domain. Multiple instances MAY share the same Workload Identifier when they are intended to be treated as the same workload for the purpose of authentication, authorization, and auditing. The path component of the URI MAY be an opaque value that is only meaningful to the issuing authority, or it MAY encode structured information used within the trust domain. Some examples of these concepts are given below:

• Opaque identifier

• Application role

• Specific instance of application role

• Opaque identifier of a specific workload instance within an application role

Other concepts may be represented in the Workload Identifier depending on what is important in the system and what information is available when the identity is issued. The path component is interpreted according to the policy of the trust domain, subject to any syntax or semantic constraints defined by the URI scheme.

Trust Domain Association The authority component of the URI defines the trust domain which is responsible for issuing, validating, and managing Workload Identifiers within its scope. 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. While IP addresses are allowed as host names in the URI encoding rules, they SHOULD NOT be used to represent trust domains except in the case where they are needed for compatibility with legacy naming schemes. When a trust domain is an internationalized domain name, its internationalized labels MUST be represented as A-labels as defined in . U-labels and their percent-encoded UTF-8 representations MUST NOT be used. Workload Identifiers are interpreted as URIs, including the trust domain carried in the authority component. The identifier denotes the workload identity at the granularity assigned by the issuing trust domain, which may correspond to a service, workload class, deployment, individual workload instance, or another deployment-defined concept. Consumers MUST compare and authorize Workload Identifiers using the complete URI, rather than relying only on individual components such as the path. For identifier comparison, consumers MUST apply the syntax-based normalization specified in and then compare the complete normalized URIs byte-for-byte. Percent-encoded unreserved characters MUST be decoded before case normalization. No additional scheme-specific or protocol-based normalization is performed for this comparison. Identifiers with different schemes after normalization are distinct. These rules also define equivalence for issuer uniqueness requirements and authorization decisions. Individual schemes MAY further restrict valid identifier syntax. Normalization MUST NOT be used to make an otherwise invalid identifier acceptable. Comparison alone does not establish validity under a particular scheme. Each trust domain MUST coordinate Workload Identifier assignment across all of its issuers to ensure that different workloads are assigned distinct Workload Identifiers.

The "wimse" URI Scheme A Workload Identifier using the wimse scheme has the generic form: / ]]> The URI MUST satisfy all requirements defined in . The structure of the path component is deployment-specific and is not interpreted by this specification. Examples:

Stability and Uniqueness Workload Identifiers are intended to be stable over time. An identifier assigned to a workload SHOULD NOT be reassigned to a different workload unless explicitly intended by the policies of the trust domain. Multiple workload instances MAY share the same Workload Identifier when they represent the same logical workload within the trust domain.

Workload Identifier Origin A Workload Identifier Origin is a specification of a namespace under which a Workload Identifier is meaningful for a given use case. An origin consists of the URI scheme and trust domain components of a Workload Identifier, omitting the path component. A Workload Identifier Origin has no path component and is therefore not itself a valid Workload Identifier. A Workload Identifier Origin is distinct from the Web Origin concept defined in . It identifies a workload namespace and does not imply the same-origin policy or origin-processing rules defined for the Web. Workload Identifier Origins serve as hints about the set of identifiers an entity may present in a particular protocol instance or usage context without revealing a specific identifier. Examples of Workload Identifier Origins:

Identifier Interpretation and Mapping Workload Identifiers are carried in credentials and tokens and are used for authentication, authorization, and auditing. However, the identifier itself does not define how a workload is reached over the network. In many deployments, workloads are accessed using external handles such as DNS names, service names, load balancer addresses, or routing paths. These handles are deployment-specific and do not necessarily match the Workload Identifier presented in credentials. To enable correct authentication decisions, WIMSE credentials MUST be validated and WIMSE identifiers MUST be processed according to the deployment policy. In some cases a system may use a mapping function to derive the WIMSE identifier for a peer using various pieces of information such as a service name and a trust domain. In this case the correctness of the mapping function and the integrity of the mapping information is critical. Failure to ensure the integrity and correctness can result in spoofing of workloads. Consumers MUST NOT assume that the Workload Identifier can be derived from network-layer information such as IP address, DNS name, or request path without such mapping. This mapping is outside the scope of this specification and may be provided by configuration, service discovery systems, orchestration platforms, or other local policy mechanisms. The mapping MAY also be conveyed within a Workload Identity Credential, where supported by the credential format and deployment policy. For example, a Workload Identity Certificate can contain both a DNS name and a Workload Identifier in its SubjectAltName extension (). WIMSE consumers relying on such a mapping MUST validate the credential and check that the WIMSE identifier matches the identifier of the system they intended to connect to. It is assumed that the issuer validates the binding between the external handle and the Workload Identifier so the consumer SHOULD also validate the external handle in the credential matches the corresponding external handle arrived at in the mapping function. Deployments using Workload Identifiers with the WIMSE credential formats defined in MUST ensure that a consistent mapping exists between workload access handles and the Workload Identifiers contained in credentials.

Usage in Credentials and Tokens Workload Identifiers are designed to be embedded in cryptographic credentials and security tokens that are used to assert the identity of workloads during authentication, authorization, and auditing. The representation of Workload Identifiers in WIMSE credential formats is defined in .

Security Considerations A Workload Identifier is intended to be used as a stable identifier for a workload identity. It is not, by itself, verifiable; instead, it can be carried in cryptographic credentials, such as X.509 Workload Identity Certificates () or Workload Identity Tokens (), that bind the identifier to key material. Because such credentials rely on correct interpretation of the Workload Identifier, identifiers need to be protected against spoofing, ambiguity, and misinterpretation. This section outlines security considerations for issuers, consumers, and system designers.

URI Parsing and Processing Considerations Workload Identifiers are encoded as URIs and therefore rely on correct and secure URI parsing. Implementations MUST parse URIs according to . Incorrect URI parsing can result in misinterpretation of identifier components, security policy bypass, or inconsistent trust domain evaluation across implementations. Implementations MUST enforce the URI requirements defined in this document, including the absence of query, fragment, user information, and port components. Failure to validate these constraints may allow identifiers to carry unintended or ambiguous semantics. Implementations MUST validate the received URI before normalization can remove evidence of prohibited syntax. Percent-decoding for comparison MUST be limited to unreserved characters and MUST NOT be applied repeatedly. Percent-encoded reserved characters, such as %2F (slash), MUST remain encoded during identifier comparison. All components involved in identifier validation and authorization MUST apply the comparison rules consistently; inconsistent processing can allow authorization checks to be bypassed. Implementations MUST also take care to handle Workload Identifiers of the maximum supported length without causing excessive memory allocation, resource exhaustion, or denial-of-service conditions. Implementations MUST NOT reject an otherwise valid Workload Identifier on the basis of length if its total length is at most 2048 bytes. Implementations MAY reject Workload Identifiers longer than 2048 bytes according to implementation-defined limits.

Identifier Authenticity Workload Identifiers MUST only be considered authenticated when presented in a credential or token that has been cryptographically verified. An identifier received outside such a context, such as a plaintext string in a request, MUST NOT be treated as authenticated. Consumers MUST treat a Workload Identifier as authenticated only when it is obtained from a credential or token that has been successfully validated according to the rules of the credential format and the deployment policy. Validation requirements for credentials carrying Workload Identifiers are defined in and in the protocols that use those credentials.

Trust Domain Validation Consumers MUST validate that the trust domain in the Workload Identifier matches an expected or explicitly trusted domain. Failure to do so may allow identifiers from unauthorized domains to be accepted as legitimate. Using an FQDN as a trust domain does not itself prove domain ownership or authority to issue credentials for that domain. Consumers MUST validate credentials using trust anchors associated with authorized issuers for that trust domain, as described in . Where appropriate, consumers SHOULD maintain an allowlist of trusted domains or trusted issuing authorities. Trust-domain allowlist matching MUST use the ASCII representation and the comparison rules defined in this document. Displaying internationalized names as Unicode can introduce confusion between visually similar names; such visual similarity does not establish trust-domain equivalence.

Identifier Reuse and Collision Issuers SHOULD ensure that Workload Identifiers are not reused across different workloads unless such reuse is intentional and well-scoped. Reassignment of identifiers to unrelated entities can result in privilege escalation or confusion in audit trails. Consumers SHOULD assume that identifiers are permanent within their domain of interpretation and treat unexpected reuse with suspicion.

Information Disclosure Because Workload Identifiers may encode topological or semantic information, they may inadvertently reveal deployment details. Issuers and system designers SHOULD take care not to expose sensitive naming conventions in externally visible identifiers. Descriptive identifier paths are allowed and may be useful for auditing, authorization, and operations. However, deployments that use descriptive paths SHOULD evaluate the information disclosure trade-offs and avoid exposing details that are not intended to be visible to consumers.

Wildcard and Prefix Matching Consumers SHOULD NOT interpret Workload Identifiers using wildcard or prefix matching unless explicitly specified by policy. For example, treating all identifiers under prefix of spiffe://example.org/ns/db/ as equivalent may lead to incorrect authorization.

IANA Considerations

URI Scheme Registration IANA is requested to register the "wimse" scheme to the "URI Schemes" registry :

Scheme name:

wimse

Status:

permanent

Applications/protocols that use this scheme name:

any application and protocol interacting with Workload Identifiers.

Contact:

IETF Chair chair@ietf.org

Change controller:

IETF

CRI Scheme Number:

TBA from the First Come First Served range

References: of this document.

References Normative References A Uniform Resource Identifier (URI) is a compact sequence of characters that identifies an abstract or physical resource. This specification defines the generic URI syntax and a process for resolving URI references that might be in relative form, along with guidelines and security considerations for the use of URIs on the Internet. The URI syntax defines a grammar that is a superset of all valid URIs, allowing an implementation to parse the common components of a URI reference without knowing the scheme-specific requirements of every possible identifier. This specification does not define a generative grammar for URIs; that task is performed by the individual specifications of each URI scheme. [STANDARDS-TRACK] In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. Ping Identity CyberArk Defakto Security Intuit Zscaler The WIMSE architecture defines authentication and authorization for software workloads in a variety of runtime environments, from the most basic ones up to complex multi-service, multi-cloud, multi- tenant deployments. This document defines the credentials that workloads use to represent their identity. They can be used in various protocols to authenticate workloads to each other. To use these credentials, workloads must provide proof of possession of the associated private key material, which is covered in other documents. This document focuses on the credentials alone, independent of the proof-of- possession mechanism. This document is one of a collection that, together, describe the protocol and usage context for a revision of Internationalized Domain Names for Applications (IDNA), superseding the earlier version. It describes the document collection and provides definitions and other material that are common to the set. [STANDARDS-TRACK] Informative References JSON Web Token (JWT) is a compact, URL-safe means of representing claims to be transferred between two parties. The claims in a JWT are encoded as a JSON object that is used as the payload of a JSON Web Signature (JWS) structure or as the plaintext of a JSON Web Encryption (JWE) structure, enabling the claims to be digitally signed or integrity protected with a Message Authentication Code (MAC) and/or encrypted. Palo Alto Networks Zscaler University of the Bundeswehr Munich 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. This document defines the concept of an "origin", which is often used as the scope of authority or privilege by user agents. Typically, user agents isolate content retrieved from different origins to prevent malicious web site operators from interfering with the operation of benign web sites. In addition to outlining the principles that underlie the concept of origin, this document details how to determine the origin of a URI and how to serialize an origin into a string. It also defines an HTTP header field, named "Origin", that indicates which origins are associated with an HTTP request. [STANDARDS-TRACK] IANA

Acknowledgments Authors would like to thank Evan Gilman for his review of the initial text of this document and his guidance.

Changelog RFC Editor's Note: Please remove this section prior to publication of a final version of this document.

since draft-ietf-wimse-identifier-00

• Defined Workload Identifier Scope
• Replaced specifics of usage in credentials and tokens with a reference to s2s-creds draft
• Added URI requirements

since draft-ietf-wimse-identifier-01

• Changed the term "Scope" to "Origin"
• Added wimse URI scheme definition
• Added more alignement and reduced overlap with draft-ietf-wimse-workload-creds
• Clarified separation of specific workload instances and logical workloads

since draft-ietf-wimse-identifier-02

• Soften Information Disclosure considerations
• Clarified various definitions
• Synced up terminology with other documents

since draft-ietf-wimse-identifier-03

• Editorial: consistent capitalization of the defined terms "Workload Identifier" and "Workload Identity Certificate", aligning with draft-ietf-wimse-workload-creds and the WIMSE protocol drafts
• Fixed stale section references into draft-ietf-wimse-workload-creds
• Updated Identity Mapping section
• Workload uniqueness clarifications