]> Ping Identity

bcampbell@pingidentity.com

CyberArk

joe@salowey.net

SPIRL

arndts.ietf@gmail.com

Intuit

yaronf.ietf@gmail.com

Applications and Real-Time Workload Identity in Multi System Environments workload identity 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 simplest, atomic unit of this architecture: the protocol between two workloads that need to verify each other's identity in order to communicate securely. The scope of this protocol is a single HTTP request-and-response pair. To address the needs of different setups, we propose two protocols, one at the application level and one that makes use of trusted TLS transport. These two protocols are compatible, in the sense that a single call chain can have some calls use one protocol and some use the other. Workload A can call Workload B with mutual TLS authentication, while the next call from Workload B to Workload C would be authenticated at the application level. 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 Working Group mailing list (), which is archived at . Subscribe at . Source for this draft and an issue tracker can be found at .

Introduction This document defines authentication and authorization in the context of interaction between two workloads. This is the core component of the WIMSE architecture . For simplicity, this document focuses on HTTP-based services, and the workload-to-workload call consists of a single HTTP request and its response. We define the credentials that both workloads should possess and how they are used to protect the HTTP exchange. There are multiple deployment styles in use today, and they result in different security properties. We propose to address them differently.

• Many use cases have various middleboxes inserted between pairs of workloads, resulting in a transport layer that is not end-to-end encrypted. We propose to address these use cases by protecting the HTTP messages at the application level ().
• The other commonly deployed architecture has a mutual-TLS connection between each pair of workloads. This setup can be addressed by a simpler solution ().

It is an explicit goal of this protocol that a workload deployment can include both architectures across a multi-chain call. In other words, Workload A can call Workload B with mutual TLS protection, while the next call to Workload C is protected at the application level. For application-level protection we currently propose two alternative solutions, one inspired by DPoP in and one which is a profile of HTTP Message Signatures in . The design team believes that we need to pick one of these two alternatives for standardization, once we have understood their pros and cons.

Extending This Protocol to Other Use Cases The protocol defined here is narrowly scoped, targeting only HTTP-based request/response services. To secure workloads communicating over other transports, new protocol bindings will need to be defined. We note though that this protocol is designed to allow some level of reuse. In particular, we expect that the Workload Identity Token (WIT) construct will be reusable in other settings. The Workload Proof Token (WPT) may be adaptable with some changes to different environments.

Deployment Architecture and Message Flow Regardless of the transport between the workloads, we assume the following logical architecture (numbers refer to the sequence of steps listed below):

Sequence of Operations | | | | | | | Workload A | (3) | Workload B | | |==============>| | | | | | | | (5) | +--------+ | |<==============| | PEP | +------------+ +---+--------+ ^ ^ ^ | (2) | | (2) | +----------------------+ | (4) | | | v v v +------------+ +------------+ | | | | | Identity | | PDP | | Server | | (optional) | | | | | +------------+ +------------+ ]]>

The Identity Server provisions credentials to each of the workloads. At least Workload A (and possibly both) must be provisioned with a credential before the call can proceed. Details of communication with the Identity Server are out of scope of this document, however we do describe the credential received by the workload. PEP is a Policy Enforcement Point, the component that allows the call to go through or blocks it. PDP is an optional Policy Decision Point, which may be deployed in architectures where policy management is centralized. All details of policy management and message authorization are out of scope of this document. The high-level message flow is as follows:

1. A transport connection is set up. In the case of mutual TLS, this includes authentication of both workloads to one another. In the case of application-level security, the TLS connection is typically one-way authenticated, and workload-level authentication does not yet take place.
2. Workload A (and similarly, Workload B) obtains a credential from the Identity Server. This happens periodically, e.g. once every 24 hours.
3. Workload A makes an HTTP call into Workload B. This is a regular HTTP request, with the additional protection mechanisms defined below.
4. In the case of application-level security, Workload B authenticates Workload A (when using mutual TLS, this happened in step 1). In either case, Workload B decides whether to authorize the call. In certain architectures, Workload B may need to consult with an external server when making this decision.
5. Workload B returns a response to Workload A, which may be an error response or a regular one.

Workload Identifiers and Authentication Granularity The specific format of workload identifiers (see ) is set by local policy for each deployment, and this choice has several implications. Prior to WIMSE, many use cases did not allow for fully granular authentication in containerized runtime platforms. For instance, with mutual TLS, there's often no clear way to map the request's external access reference (e.g., Kubernetes Ingress path, service name, or host header) to the SubjectAltName value in the server certificate. This means that the client could only verify if the server certificate is valid within a trust domain, not if it's tied to a specific workload. To enable mutual and granular authentication between workloads, two things must be in place:

• Each workload must know its own identifier.
• There needs to be an explicit mapping from the external handle used to access a workload (such as an Ingress path or service DNS name) to its workload identifier.

Once these conditions are met, the methods described in this document can be used for the caller and callee to mutually authenticate. Implementations MUST allow for defining this mapping between the workload's access path and the workload identifier (e.g., through callback functions). Deployments SHOULD use these features to establish a consistent set of identifiers within their environment.

Conventions and Definitions All terminology in this document follows . 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.

Application Level Workload-to-Workload Authentication As noted in the Introduction, for many deployments communication between workloads cannot use end-to-end TLS. For these deployment styles, this document proposes application-level protections. The current version of the document includes two alternatives, both using the newly introduced Workload Identity Token (). The first alternative () is inspired by the OAuth DPoP specification. The second () is based on the HTTP Message Signatures RFC. We present both alternatives and expect the working group to select one of them as this document progresses towards IETF consensus. A comparison of the two alternatives is attempted in .

The Workload Identity Token The Workload Identity Token (WIT) is a JWS signed JWT that represents the identity of a workload. It is issued by the Identity Server and binds a public key to the workload identity. See for security considerations. A WIT MUST contain the following claims, except where noted:

• in the JOSE header:
  • alg: An identifier for a JWS asymmetric digital signature algorithm (registered algorithm identifiers are listed in the IANA JOSE Algorithms registry ). The value none MUST NOT be used.
  • typ: the WIT is explicitly typed, as recommended in , using the wit+jwt media type.
• in the JWT claims:
  • iss: The issuer of the token, which is the Identity Server, represented by a URI. The iss claim is RECOMMENDED but optional, see for more.
  • sub: The subject of the token, which is the identity of the workload, represented by a URI. See for details of the Workload Identifier. And see for security implications of these identifiers.
  • exp: The expiration time of the token (as defined in ). WITs should be refreshed regularly, e.g. on the order of hours.
  • jti: A unique identifier for the token. This claim is OPTIONAL. The jti claim is frequently useful for auditing issuance of individual WITs or to revoke them, but some token generation environments do not support it.
  • cnf: A confirmation claim referencing the public key of the workload.
    • jwk: Within the cnf claim, a jwk key MUST be present that contains the public key of the workload as defined in . The workload MUST prove possession of the corresponding private key when presenting the WIT to another party, which can be accomplished by using it in conjunction with one of the methods in or . As such, it MUST NOT be used as a bearer token and is not intended for use in the Authorization header.
      • alg: Within the jwk object, an alg field MUST be present. Allowed values are listed in the IANA "JSON Web Signature and Encryption Algorithms" registry established by . The presented proof (WPT or http-sig) MUST be produced with the algorithm specified in this field. The value none MUST NOT be used. Algorithms used in combination with symmetric keys MUST NOT be used. Also encryption algorithms MUST NOT be used as this would require additional key distribution outside of the WIT. To promote interoperability, the ES256 signing algorithm MUST be supported by general purpose implementations of this document.

As noted in , a workload identifier is a URI with a trust domain component. The runtime environment often determines which URI scheme is used, e.g. if SPIFFE is used to authenticate workloads, it mandates "spiffe" URIs. However for those deployments where this is not the case, this document () defines the "wimse" URI scheme which can be used by any deployment that implements this protocol. An example WIT might look like this:

An example Workload Identity Token (WIT)

The decoded JOSE header of the WIT from the example above is shown here:

Example WIT JOSE Header

The decoded JWT claims of the WIT from the example above are shown here:

Example WIT Claims

The claims indicate that the example WIT:

• is valid until Thu Apr 24 2025 16:35:10 GMT (represented as NumericDate value 1745512510).
• identifies the workload to which the token was issued as wimse://example.com/specific-workload.
• has a unique identifier of x-_1CTL2cca3CSE4cwb_l.
• binds the public key represented by the jwk confirmation method to the workload wimse://example.com/specific-workload.
• requires the proof to be produced with the EdDSA signature algorithm.

For elucidative purposes only, the workload's key, including the private part, is shown below in JWK format:

Example Workload's Key

The afore-exampled WIT is signed with the private key of the Identity Server. The public key(s) of the Identity Server need to be known to all workloads in order to verify the signature of the WIT. The Identity Server's public key from this example is shown below in JWK format:

Example Identity Server Key

The WIT HTTP Header A WIT is conveyed in an HTTP header field named Workload-Identity-Token. ABNF for the value of Workload-Identity-Token header field is provided in :

Workload-Identity-Token Header Field ABNF

The following shows the WIT from in an example of a Workload-Identity-Token header field:

An example Workload Identity Token HTTP Header Field

Note that per , header field names are case insensitive; thus, Workload-Identity-Token, workload-identity-token, WORKLOAD-IDENTITY-TOKEN, etc., are all valid and equivalent header field names. However, case is significant in the header field value.

Including Additional Claims The WIT contains JSON structures and therefore can be trivially extended by adding more claims beyond those defined in the current specification. This, however, could result in interoperability issues, which the following rules are addressing.

• To ensure interoperability in WIMSE environments, the use of Private claim names (Sec. 4.3 of ) is NOT RECOMMENDED.
• In closed environments, deployers MAY freely add claims to the WIT. Such claims SHOULD be collision-resistant, such as example.com/myclaim.
• A recipient that does not understand such claims MUST ignore them, as per Sec. 4 of .
• Outside of closed environments, new claims MUST be registered with IANA before they can be used.

A note on iss claim and key distribution It is RECOMMENDED that the WIT carries an iss claim. This specification itself does not make use of a potential iss claim but also carries the trust domain in the workload identifier (see for a definition of the identifier and related rules). Implementations MAY include the iss claim in the form of a https URL to facilitate key distribution via mechanisms like the jwks_uri from but alternative key distribution methods may make use of the trust domain included in the workload identifier which is carried in the mandatory sub claim.

Option 1: DPoP-Inspired Authentication This option, inspired by the OAuth DPoP specification , uses a DPoP-like mechanism to authenticate the calling workload in the context of the request. The Workload Identity Token () is sent in the request as described in . An additional JWT, the Workload Proof Token (WPT), is signed by the private key corresponding to the public key in the WIT. The WPT is sent in the Workload-Proof-Token header field of the request. The ABNF syntax of the Workload-Proof-Token header field is:

Workload-Proof-Token Header Field ABNF

where the JWT projection is defined in . A WPT MUST contain the following:

• in the JOSE header:
  • alg: An identifier for an appropriate JWS asymmetric digital signature algorithm corresponding to the confirmation key in the associated WIT. The value MUST match the alg value of the jwk in the cnf claim of the WIT. See for valid values and restrictions.
  • typ: the WPT is explicitly typed, as recommended in , using the application/wpt+jwt media type.
• in the JWT claims:
  • aud: The audience SHOULD contain the HTTP target URI () of the request to which the WPT is attached, without query or fragment parts. However, there may be some normalization, rewriting or other process that requires the audience to be set to a deployment-specific value. See also for more details.
  • exp: The expiration time of the WPT (as defined in ). WPT lifetimes MUST be short, e.g., on the order of minutes or seconds.
  • jti: An identifier for the token. The value MUST be unique, at least within the scope of the sender.
  • wth: Hash of the Workload Identity Token, defined in . The value is the base64url encoding of the SHA-256 hash of the ASCII encoding of the WIT's value.
  • ath: Hash of the OAuth access token, if present in the request, which might convey end-user identity and/or authorization context of the request. The value, as per , is the base64url encoding of the SHA-256 hash of the ASCII encoding of the access token's value.
  • tth: Hash of the Txn-Token , if present in the request, which might convey end-user identity and/or authorization context of the request. The value MUST be the result of a base64url encoding (as defined in ) of the SHA-256 hash of the ASCII encoding of the associated token's value.
  • oth: Hash(es) of other token(s) in the request that convey end-user identity and/or authorization context of the request. The value is a JSON object with a key-value pair for each such token. For each, in the absence of an application profile specifying details, the key corresponds to the header field name containing the token, and the value is the base64url encoding of the SHA-256 hash of the ASCII bytes of the header field value with any leading or trailing spaces removed. The header field name MUST be normalized by converting it to all lower case. Header fields occurring multiple times in the request are not supported by default. An application profile may specify different behavior for a key, such as using a different hash algorithm or means of locating the token in the request.

To clarify: the ath, tth and oth claims are each mandatory if the respective tokens are included in the request. The rules for using non-standard claims in WPTs are similar to the rules for WITs, . An example WPT might look like the following:

Example Workload Proof Token (WPT)

The decoded JOSE header of the WPT from the example above is shown here:

Example WPT JOSE Header

The decoded JWT claims of the WPT from the example above are shown here:

Example WPT Claims

An example of an HTTP request with both the WIT and WPT from prior examples is shown below:

Example HTTP Request with WIT and WPT

To validate the WPT in the request, the recipient MUST ensure the following:

• There is exactly one Workload-Proof-Token header field in the request.
• The Workload-Proof-Token header field value is a single and well-formed JWT.
• The signature algorithm in the alg JOSE header string-equal matches the alg attribute of the jwk in the cnf claim of the WIT.
• The WPT signature is valid using the public key from the confirmation claim of the WIT.
• The typ JOSE header parameter of the WPT conveys a media type of wpt+jwt.
• The aud claim of the WPT matches the target URI, or an acceptable alias or normalization thereof, of the HTTP request in which the WPT was received, ignoring any query and fragment parts. See also for implementation advice on this verification check.
• The exp claim is present and conveys a time that has not passed. WPTs with an expiration time unreasonably far in the future SHOULD be rejected.
• The wth claim is present and matches the hash of the token value conveyed in the Workload-Identity-Token header.
• It is RECOMMENDED to check that the value of the jti claim has not been used before in the time window in which the respective WPT would be considered valid.
• If presented in conjunction with an OAuth access token, the value of the ath claim matches the hash of that token's value.
• If presented in conjunction with a Txn-Token, the value of the tth claim matches the hash of that token's value.
• If presented in conjunction with a token conveying end-user identity or authorization context, the value of the oth claim matches the hash of that token's value.
• If the oth claim is present, verify the hashes of all tokens listed in the oth claim per the default behavior defined in or as specified by an application specific profile. If the oth claim contains entries that are not understood by the recipient, the WPT MUST be rejected. Conversely, additional tokens not covered by the oth claim MUST NOT be used by the recipient to make authorization decisions.

Option 2: Authentication Based on HTTP Message Signatures This option uses the Workload Identity Token () and the private key associated with its public key, to sign the request and optionally, the response. See for security considerations. This section defines a profile of the Message Signatures specification . The request is signed as per . The following derived components MUST be signed:

• @method
• @request-target

In addition, the following request headers MUST be signed when they exist:

• Content-Type
• Content-Digest
• Authorization
• Txn-Token
• Workload-Identity-Token

If the response is signed, the following components MUST be signed:

• @status
• @method;req
• @request-target;req
• Content-Type if it exists
• Content-Digest if it exists
• Workload-Identity-Token

To ensure the message is fully integrity-protected, if the request or response includes a message body, the sender MUST include (and the receiver MUST verify) a Content-Digest header. For both requests and responses, the following signature parameters MUST be included:

• created
• expires - expiration MUST be short, e.g. on the order of minutes. The WIMSE architecture will provide separate mechanisms in support of long-lived compute processes.
• nonce
• tag - the value for implementations of this specification is wimse-workload-to-workload

The following signature parameters in the Signature-Input header MUST NOT be used:

• keyid - The signing key is sent along with the message in the WIT. Additionally specifying the key identity would add confusion.
• alg - The signature algorithm is specified in the jwk section of the cnf claim in the WIT. See and Sec. 3.3.7 of for details.

It is RECOMMENDED to include only one signature with the HTTP message. If multiple ones are included, then the signature label included in both the Signature-Input and Signature headers SHOULD be wimse. A sender MUST ensure that each nonce it generates is unique, at least among messages sent to the same recipient. To detect message replays, a recipient SHOULD reject a message (request or response) if a nonce generated by a certain peer is seen more than once. Implementors need to be aware that the WIT is extracted from the message before the message signature is validated. Recipients of signed HTTP messages MUST validate the signature and content of the WIT before validating the HTTP message signature. They MUST ensure that the message is not processed further before it has been fully validated. Either client or server MAY send an Accept-Signature header, but is not required to do so. When this header is sent, it MUST include the header components listed above. Following is a non-normative example of a signed request and a signed response, where the caller is using the keys specified in (TODO: it is actually using a different key but that'll need to be fixed later).

Signed Request

Assuming that the workload being called has the following keypair:

Callee Private Key

A signed response would be:

Signed Response

Comparing the DPoP Inspired Option with Message Signatures The two workload protection options have different strengths and weaknesses regarding implementation complexity, extensibility, and security. Here is a summary of the main differences between and .

• The DPoP-inspired solution is less HTTP-specific, making it easier to adapt for other protocols beyond HTTP. This flexibility is particularly valuable for asynchronous communication scenarios, such as event-driven systems.
• Message Signatures, on the other hand, benefit from an existing HTTP-specific RFC with some established implementations. This existing groundwork means that this option could be simpler to deploy, to the extent such implementations are available and easily integrated.
• Given that the WIT (Workload Identity Token) is a type of JWT, the DPoP-inspired approach that also uses JWT is less complex and technology-intensive than Message Signatures. In contrast, Message Signatures introduce an additional layer of technology, potentially increasing the complexity of the overall system.
• Message Signatures offer superior integrity protection, particularly by mitigating message modification by middleboxes. See also .
• A key advantage of Message Signatures is that they support response signing. This opens up the possibility for future decisions about whether to make response signing mandatory, allowing for flexibility in the specification and/or in specific deployment scenarios.
• In general, Message Signatures provide greater flexibility compared to the DPoP-inspired approach. Future versions of this draft (and subsequent implementations) can decide whether specific aspects of message signing, such as coverage of particular fields, should be mandatory or optional. Covering more fields will constrain the proof so it cannot be easily reused in another context, which is often a security improvement. The DPoP inspired approach could be designed to include extensibility to sign other fields, but this would make it closer to trying to reinvent Message Signatures.

Error Conditions Errors may occur during the processing of the message signature or WPT. If the signature verification fails for any reason, such as an invalid signature, an expired validity time window, or a malformed data structure, an error is returned. Typically, this will be in response to an API call, so an HTTP status code such as 400 (Bad Request) is appropriate. This response could include more details as per , such as an indicator that the wrong key material or algorithm was used. The use of HTTP status code 401 is NOT RECOMMENDED for this purpose because it requires a WWW-Authenticate with acceptable http auth mechanisms in the error response and an associated Authorization header in the subsequent request. The use of these headers for the WIT or WPT is not compatible with this specification.

Coexistence with JWT Bearer Tokens The WIT and WPT define new HTTP headers. They can therefore be presented along with existing headers used for JWT bearer tokens. This property allows for transition from mechanisms using identity tokens based on bearer JWTs to proof of possession based WITs. A workload may implement a policy that accepts both bearer tokens and WITs during a transition period. This policy may be configurable per-caller to allow the workload to reject bearer tokens from callers that support WITs. Once a deployment fully supports WITs, then the use of bearer tokens for identity can be disabled through policy. Implementations should be careful when implementing such a transition strategy, since the decision which token to prefer is made when the caller's identity has still not been authenticated, and needs to be revalidated following the authentication step. The WIT can also coexist with tokens used to establish security context, such as transaction tokens . In this case a workload's authorization policy may take into account both the sending workload's identity and the information in the context token. For example, the identity in the WIT may be used to establish which API calls can be made and information in the context token may be used to determine which specific resources can be accessed.

Using Mutual TLS for Workload-to-Workload Authentication As noted in the introduction, for many deployments, transport-level protection of application traffic using TLS is ideal.

The Workload Identity Certificate The Workload Identity Certificate is an X.509 certificate. The workload identity MUST be encoded in a SubjectAltName extension of type URI. There MUST be only one SubjectAltName extension of type URI in a Workload Identity Certificate. If the workload will act as a TLS server for clients that do not understand workload identities it is RECOMMENDED that the Workload Identity Certificate contain a SubjectAltName of type DNSName with the appropriate DNS names for the server. The certificate MAY contain SubjectAltName extensions of other types.

Workload Identity Certificate Validation Workload Identity Certificates may be used to authenticate both the server and client side of the connections. When validating a Workload Identity Certificate, the relying party MUST use the trust anchors configured for the trust domain in the workload identity to validate the peer's certificate. Other PKIX path validation rules apply. Workloads acting as TLS clients and servers MUST validate that the trust domain portion of the Workload Identity Certificate matches the expected trust domain for the other side of the connection. Servers wishing to use the Workload Identity Certificate for authorizing the client MUST require client certificate authentication in the TLS handshake. Other methods of post handshake authentication are not specified by this document. Workload Identity Certificates used by TLS servers SHOULD have the id-kp-serverAuth extended key usage field set and Workload Identity Certificates used by TLS clients SHOULD have the id-kp-clientAuth extended key usage field set. A certificate that is used for both client and server connections may have both fields set. This specification does not make any other requirements beyond on the contents of Workload Identity Certificates or on the certification authorities that issue workload certificates.

Server Name Validation If the WIMSE client uses a hostname to connect to the server and the server certificate contain a DNS SAN the client MUST perform standard host name validation () unless it is configured with the additional information necessary to perform alternate validation of the peer's workload identity. If the client did not perform standard host name validation then the WIMSE client SHOULD further use the workload identifier to validate the server. The host portion of the workload identifier is NOT treated as a host name as specified in section 6.4 of but rather as a trust domain. The server identity is encoded in the path portion of the workload identifier in a deployment specific way. Validating the workload identity could be a simple match on the trust domain and path portions of the identifier or validation may be based on the specific details on how the identifier is constructed. The path portion of the WIMSE identifier MUST always be considered in the scope of the trust domain. In most cases it is preferable to validate the entire workload identifier, see for additional implementation advice.

Client Authorization Using the Workload Identity The server application retrieves the workload identifier from the client certificate subjectAltName, which in turn is obtained from the TLS layer. The identifier is used in authorization, accounting and auditing. For example, the full workload identifier may be matched against ACLs to authorize actions requested by the peer and the identifier may be included in log messages to associate actions to the client workload for audit purposes. A deployment may specify other authorization policies based on the specific details of how the workload identifier is constructed. The path portion of the workload identifier MUST always be considered in the scope of the trust domain. See on additional security implications of workload identifiers.

Implementation Status Note to RFC Editor: please remove this section, as well as the reference to RFC 7942, before publication. This section records the status of known implementations of the protocol defined by this specification at the time of posting of this Internet-Draft, and is based on a proposal described in . The description of implementations in this section is intended to assist the IETF in its decision processes in progressing drafts to RFCs. Please note that the listing of any individual implementation here does not imply endorsement by the IETF. Furthermore, no effort has been spent to verify the information presented here that was supplied by IETF contributors. This is not intended as, and must not be construed to be, a catalog of available implementations or their features. Readers are advised to note that other implementations may exist. According to RFC 7942, "this will allow reviewers and working groups to assign due consideration to documents that have the benefit of running code, which may serve as evidence of valuable experimentation and feedback that have made the implemented protocols more mature. It is up to the individual working groups to use this information as they see fit". SPIFFE (Standard)

• Organization: CNCF
• Maturity:
  • Workload Identity Certificate: fully compatible with the X509-SVID and widely used.
  • Workload Identity Token: beta
• Coverage: Workload Identity Certificate, WIT
• Contact: SPIFFE sig-spec community

SPIRL

• Organization: SPIRL
• Maturity:
  • Workload Identity Certificate: production
  • Workload Identity Token/Workload Proof Token: alpha
• Coverage: Workload Identity Certificate, WIT, WPT
• Contact: arndt@spirl.com

Teleport - Machine & Workload Identity

• Organization: Teleport
• Maturity:
  • Workload Identity Certificate: production
  • Workload Identity Token/Workload Proof Token: research
• Coverage: Workload Identity Certificate
• Contact: noah@goteleport.com

Security Considerations

Workload Identity The Workload Identifier is scoped within an issuer and therefore any sub-components (path portion of Identifier) are only unique within a trust domain defined by the issuer. Using a Workload Identifier without taking into account the trust domain could allow one domain to issue tokens to spoof identities in another domain. Additionally, the trust domain must be tied to an authorized issuer cryptographic trust anchor through some mechanism such as a JWKS or X.509 certificate chain. The association of an issuer, trust domain and a cryptographic trust anchor MUST be communicated securely out of band.

Workload Identity Token and Proof of Possession The Workload Identity Token (WIT) is bound to a secret cryptographic key and is always presented with a proof of possession as described in . The WIT is a general purpose token that can be presented in multiple contexts. The WIT and its PoP are only used in the application-level options, and both are not used in MTLS. The WIT MUST NOT be used as a bearer token. While this helps reduce the sensitivity of the token it is still possible that a token and its proof of possession may be captured and replayed within the PoP's lifetime. The following are some mitigations for the capture and reuse of the proof of possession (PoP):

• Preventing Eavesdropping and Interception with TLS

An attacker observing or intercepting the communication channel can view the token and its proof of possession and attempt to replay it to gain an advantage. In order to prevent this the token and proof of possession MUST be sent over a secure, server authenticated TLS connection unless a secure channel is provided by some other mechanisms. Host name validation according to MUST be performed by the client.

• Limiting Proof of Possession Lifespan

The proof of possession MUST be time limited. A PoP should only be valid over the time necessary for it to be successfully used for the purpose it is needed. This will typically be on the order of minutes. PoPs received outside their validity time MUST be rejected.

• Limiting Proof of Possession Scope

In order to reduce the risk of theft and replay the PoP should have a limited scope. For example, a PoP may be targeted for use with a specific workload and even a specific transaction to reduce the impact of a stolen PoP. In some cases a workload may wish to reuse a PoP for a period of time or have it accepted by multiple target workloads. A careful analysis is warranted to understand the impacts to the system if a PoP is disclosed allowing it to be presented by an attacker along with a captured WIT.

• Replay Protection

A proof of possession includes the jti claim that MUST uniquely identify it, within the scope of a particular sender. This claim SHOULD be used by the receiver to perform basic replay protection against tokens it has already seen. Depending upon the design of the system it may be difficult to synchronize the replay cache across all token validators. If an attacker can somehow influence the identity of the validator (e.g. which cluster member receives the message) then replay protection would not be effective.

• Binding to TLS Endpoint

The POP MAY be bound to a transport layer sender such as the client identity of a TLS session or TLS channel binding parameters. The mechanisms for binding are outside the scope of this specification.

Workload Identity Key Management Both the Workload Identity Token and the Workload Identity Certificate carry a public key. The corresponding private key:

• MUST be kept private
• MUST be individual for each Workload Identifier (see )
• MUST NOT be used once the credential is expired
• SHOULD be re-generated for each new Workload Identity Token or Certificate.

Middle Boxes In some deployments the Workload Identity Token and proof of possession may pass through multiple systems. The communication between the systems is over TLS, but the token and PoP are available in the clear at each intermediary. While the intermediary cannot modify the token or the information within the PoP they can attempt to capture and replay the token or modify the data not protected by the PoP. Mitigations listed in can be used to provide some protection from middle boxes. However we note that the DPoP-inspired solution () does not protect major portions of the request and response and therefore does not provide protection from an actively malicious middle box. Deployments should perform analysis on their situation to determine if it is appropriate to trust and allow traffic to pass through a middle box.

Privacy Considerations WITs and the proofs of possession may contain private information such as user names or other identities. Care should be taken to prevent the disclosure of this information. The use of TLS helps protect the privacy of WITs and proofs of possession. WITs and certificates with workload identifiers are typically associated with a workload and not a specific user, however in some deployments the workload may be associated directly to a user. While these are exceptional cases a deployment should evaluate if the disclosure of WITs or certificates can be used to track a user.

IANA Considerations

JSON Web Token Claims IANA is requested to add the following entries to the "JSON Web Token Claims" registry :

Claim Name	Claim Description	Change Controller	Reference
tth	Transaction Token hash	IETF	RFC XXX,
wth	Workload Identity Token hash	IETF	RFC XXX,
oth	Other Tokens hashes	IETF	RFC XXX,

Media Type Registration IANA is requested to register the following entries to the "Media Types" registry :

• application/wit+jwt, per .
• application/wpt+jwt, per .

application/wit+jwt Type name: application Subtype name: wit+jwt Required parameters: N/A Optional parameters: N/A Encoding considerations: Encoding considerations are identical to those specified for the "application/jwt" media type. See . Security considerations: See the Security Considerations section of RFC XXX. Interoperability considerations: N/A Published specification: RFC XXX, . Applications that use this media type: Identity servers that vend Workload Identity Tokens, and Workloads that use these tokens to authenticate to each other. Fragment identifier considerations: N/A Additional information: Deprecated alias names for this type: N/A Magic number(s): N/A File extension(s): None Macintosh file type code(s): N/A Person & email address to contact for further information: See the Authors' Addresses section of RFC XXX. Intended usage: COMMON Restrictions on usage: N/A Author: See the Authors' Addresses section of RFC XXX. Change controller: Internet Engineering Task Force (iesg@ietf.org).

application/wpt+jwt Type name: application Subtype name: wpt+jwt Required parameters: N/A Optional parameters: N/A Encoding considerations: Encoding considerations are identical to those specified for the "application/jwt" media type. See . Security considerations: See the Security Considerations section of RFC XXX. Interoperability considerations: N/A Published specification: RFC XXX, . Applications that use this media type: Workloads that use these tokens to integrity-protect messages in the WIMSE workload-to-workload protocol. Fragment identifier considerations: N/A Additional information: Deprecated alias names for this type: N/A Magic number(s): N/A File extension(s): None Macintosh file type code(s): N/A Person & email address to contact for further information: See the Authors' Addresses section of RFC XXX. Intended usage: COMMON Restrictions on usage: N/A Author: See the Authors' Addresses section of RFC XXX. Change controller: Internet Engineering Task Force (iesg@ietf.org).

Hypertext Transfer Protocol (HTTP) Field Name Registration IANA is requested to register the following entries to the "Hypertext Transfer Protocol (HTTP) Field Name Registry" :

• Workload-Identity-Token, per .
• Workload-Proof-Token, per .

Workload-Identity-Token

• Field Name: Workload-Identity-Token
• Status: permanent
• Structured Type: N/A
• Specification Document: RFC XXX,
• Comments: see reference above for an ABNF syntax of this field

Workload-Proof-Token

• Field Name: Workload-Proof-Token
• Status: permanent
• Structured Type: N/A
• Specification Document: RFC XXX,
• Comments: see reference above for an ABNF syntax of this field

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: the WIMSE workload-to-workload authentication protocol.
• Contact: IETF Chair chair@ietf.org
• Change controller: IESG iesg@ietf.org
• References: of this document (RFC XXX).

References Normative References Internet technical specifications often need to define a formal syntax. Over the years, a modified version of Backus-Naur Form (BNF), called Augmented BNF (ABNF), has been popular among many Internet specifications. The current specification documents ABNF. It balances compactness and simplicity with reasonable representational power. The differences between standard BNF and ABNF involve naming rules, repetition, alternatives, order-independence, and value ranges. This specification also supplies additional rule definitions and encoding for a core lexical analyzer of the type common to several Internet specifications. [STANDARDS-TRACK] JSON Web Signature (JWS) represents content secured with digital signatures or Message Authentication Codes (MACs) using JSON-based data structures. Cryptographic algorithms and identifiers for use with this specification are described in the separate JSON Web Algorithms (JWA) specification and an IANA registry defined by that specification. Related encryption capabilities are described in the separate JSON Web Encryption (JWE) specification. A JSON Web Key (JWK) is a JavaScript Object Notation (JSON) data structure that represents a cryptographic key. This specification also defines a JWK Set JSON data structure that represents a set of JWKs. Cryptographic algorithms and identifiers for use with this specification are described in the separate JSON Web Algorithms (JWA) specification and IANA registries established by that specification. This specification registers cryptographic algorithms and identifiers to be used with the JSON Web Signature (JWS), JSON Web Encryption (JWE), and JSON Web Key (JWK) specifications. It defines several IANA registries for these identifiers. 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. This specification describes how to declare in a JSON Web Token (JWT) that the presenter of the JWT possesses a particular proof-of- possession key and how the recipient can cryptographically confirm proof of possession of the key by the presenter. Being able to prove possession of a key is also sometimes described as the presenter being a holder-of-key. JSON Web Tokens, also known as JWTs, are URL-safe JSON-based security tokens that contain a set of claims that can be signed and/or encrypted. JWTs are being widely used and deployed as a simple security token format in numerous protocols and applications, both in the area of digital identity and in other application areas. This Best Current Practices document updates RFC 7519 to provide actionable guidance leading to secure implementation and deployment of JWTs. The Hypertext Transfer Protocol (HTTP) is a stateless application-level protocol for distributed, collaborative, hypertext information systems. This document describes the overall architecture of HTTP, establishes common terminology, and defines aspects of the protocol that are shared by all versions. In this definition are core protocol elements, extensibility mechanisms, and the "http" and "https" Uniform Resource Identifier (URI) schemes. This document updates RFC 3864 and obsoletes RFCs 2818, 7231, 7232, 7233, 7235, 7538, 7615, 7694, and portions of 7230. This document describes a mechanism for creating, encoding, and verifying digital signatures or message authentication codes over components of an HTTP message. This mechanism supports use cases where the full HTTP message may not be known to the signer and where the message may be transformed (e.g., by intermediaries) before reaching the verifier. This document also describes a means for requesting that a signature be applied to a subsequent HTTP message in an ongoing HTTP exchange. 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. This specification defines a metadata format that an OAuth 2.0 client can use to obtain the information needed to interact with an OAuth 2.0 authorization server, including its endpoint locations and authorization server capabilities. This memo profiles the X.509 v3 certificate and X.509 v2 certificate revocation list (CRL) for use in the Internet. An overview of this approach and model is provided as an introduction. The X.509 v3 certificate format is described in detail, with additional information regarding the format and semantics of Internet name forms. Standard certificate extensions are described and two Internet-specific extensions are defined. A set of required certificate extensions is specified. The X.509 v2 CRL format is described in detail along with standard and Internet-specific extensions. An algorithm for X.509 certification path validation is described. An ASN.1 module and examples are provided in the appendices. [STANDARDS-TRACK] Many application technologies enable secure communication between two entities by means of Transport Layer Security (TLS) with Internet Public Key Infrastructure using X.509 (PKIX) certificates. This document specifies procedures for representing and verifying the identity of application services in such interactions. This document obsoletes RFC 6125. This document describes a simple process that allows authors of Internet-Drafts to record the status of known implementations by including an Implementation Status section. This will allow reviewers and working groups to assign due consideration to documents that have the benefit of running code, which may serve as evidence of valuable experimentation and feedback that have made the implemented protocols more mature. This process is not mandatory. Authors of Internet-Drafts are encouraged to consider using the process for their documents, and working groups are invited to think about applying the process to all of their protocol specifications. This document obsoletes RFC 6982, advancing it to a Best Current Practice. Informative References IANA IANA IANA IANA IANA This document defines a "problem detail" to carry machine-readable details of errors in HTTP response content to avoid the need to define new error response formats for HTTP APIs. This document obsoletes RFC 7807. CyberArk Zscaler University of Applied Sciences Bonn-Rhein-Sieg 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 a running instance of software executing for a specific purpose. This document discusses an architecture for designing and standardizing protocols and payloads for conveying workload identity and security context information. This document describes a mechanism for sender-constraining OAuth 2.0 tokens via a proof-of-possession mechanism on the application level. This mechanism allows for the detection of replay attacks with access and refresh tokens. SGNL Practical Identity LLC SPIRL Transaction Tokens (Txn-Tokens) are designed to maintain and propagate user identity and authorization context across workloads within a trusted domain during the processing of external programmatic requests, such as API calls. They ensure that this context is preserved throughout the call chain, even when new transactions are initiated internally, thereby enhancing security and consistency in complex, multi-service architectures.

Document History RFC Editor: please remove before publication.

draft-ietf-wimse-s2s-protocol-07

• Rework the WPT's oth claim.
• update the media types.
• Discuss extensibility of WIT and WPT.
• Clarify error handling, specifically why not HTTP 401.
• Correct the code examples.
• Add registration request content for a wimse URI scheme.
• New section on key management.
• Use of the Accept-Signature header.

draft-ietf-wimse-s2s-protocol-06

• Explicit definition of the Workload Identity Certificate.
• Definition of the validation of workload identifiers as part of workload authentication. Still work in progress.

draft-ietf-wimse-s2s-protocol-05

• Removed the entire Workload Identity section which is now covered in the Architecture document.
• Content-Digest is mandatory with HTTP-Sig.
• Some wording on extending the protocol beyond HTTP.
• IANA considerations.

draft-ietf-wimse-s2s-protocol-04

• Require cnf.jwk.alg in WIT which restricts signature algorithm of WPT or HTTP-Sig.
• Replay protection as a SHOULD for both WPT and HTTP-Sig.
• Consolidate terminology with the Architecture draft.

draft-ietf-wimse-s2s-protocol-03

• Consistently use "workload".
• Implement comments from the SPIFFE community.
• Make iss claim in WIT optional and add wording about its relation to key distribution.
• Remove iss claim from WPT.
• Make jti claim in WIT optional.
• Error handling for the application level methods.

draft-ietf-wimse-s2s-protocol-02

• Coexistence with bearer tokens.
• Improve the architecture diagram.
• Some more ABNF.
• Clarified identifiers and URIs.
• Moved an author to acknowledgments.

draft-ietf-wimse-s2s-protocol-01

• Addressed multiple comments from Pieter.
• Clarified WIMSE identity concepts, specifically "trust domain" and "workload identifier".
• Much more detail around mTLS, including some normative language.
• WIT (the identity token) is now included in the WPT proof of possession.
• Added a section comparing the DPoP-inspired app-level security option to the Message Signature-based alternative.

draft-ietf-wimse-s2s-protocol-00

• Initial WG draft, an exact copy of draft-sheffer-wimse-s2s-protocol-00
• Added this document history section

Acknowledgments The authors would like to thank Pieter Kasselman for his detailed comments. We thank Daniel Feldman for his contributions to earlier versions of this document.