From d4e960bd63d563a7eb38d2b3e54ad67a55581fb3 Mon Sep 17 00:00:00 2001 From: PieterKas <90690777+PieterKas@users.noreply.github.com> Date: Thu, 18 Sep 2025 12:35:00 +0100 Subject: [PATCH 1/5] Allow for alternatives to RFC8693 See #189 --- draft-ietf-oauth-transaction-tokens.md | 9 ++++++--- 1 file changed, 6 insertions(+), 3 deletions(-) diff --git a/draft-ietf-oauth-transaction-tokens.md b/draft-ietf-oauth-transaction-tokens.md index 2bb0a95..2043602 100644 --- a/draft-ietf-oauth-transaction-tokens.md +++ b/draft-ietf-oauth-transaction-tokens.md @@ -151,7 +151,9 @@ Txn-Tokens are short-lived, signed JWTs {{RFC7519}} that assert the identity of ## Creating Txn-Tokens ### Initial Creation -Txn-Tokens are typically created when a workload is invoked using an endpoint that is externally visible, and is authorized using a separate mechanism, such as an OAuth {{RFC6749}} access token. This workload then performs an OAuth 2.0 Token Exchange {{RFC8693}} to obtain a Txn-Token. To do this, it invokes a special Token Service (the Txn-Token Service) and provides context that is sufficient for it to generate a Txn-Token. The context information provided to the Txn-Token Service MAY include: +Txn-Tokens are typically created when a workload is invoked using an endpoint that is externally visible, and is authorized using a separate mechanism, such as an OAuth {{RFC6749}} access token. The externally visible endpoint exchanges the received token for a transaction token before sending it to the workload. The transaction token may be obtained through a local interface, or it may be requested from a remote server. + +If the transaction token request is made via HTTP to a remote server, it SHOULD use RFC8693 as described in this specification. To do this, it invokes a special Token Service (the Txn-Token Service) and provides context that is sufficient for it to generate a Txn-Token. The context information provided to the Txn-Token Service MAY include: * The external authorization token (e.g., the OAuth access token) * An internally generated JWT representing the subject of the request @@ -743,8 +745,9 @@ The authors would like to thank the contributors and the OAuth working group mem ## Since Draft 06 {:numbered="false"} -* Remove definition of Authorization Context [Be more specific on Authorization Context](https://github.com/oauth-wg/oauth-transaction-tokens/issues/192) -* Clarify that workloads should ensure it is communicating with a legitimate instance of a transaction token service (https://github.com/oauth-wg/oauth-transaction-tokens/issues/233) +* Remove definition of Authorization Context [Be more specific on Authorization Context](https://github.com/oauth-wg/oauth-transaction-tokens/issues/192). +* Clarify that workloads should ensure it is communicating with a legitimate instance of a transaction token service (https://github.com/oauth-wg/oauth-transaction-tokens/issues/233). +* Allow other mechanisms for obtaining transaction tokens that does not use RFC8693 (https://github.com/oauth-wg/oauth-transaction-tokens/issues/189). ## Since Draft 05 {:numbered="false"} From dd84b43f042867f129d14d754b527ec3fb6ecbd9 Mon Sep 17 00:00:00 2001 From: PieterKas <90690777+PieterKas@users.noreply.github.com> Date: Thu, 18 Sep 2025 12:50:19 +0100 Subject: [PATCH 2/5] Additional clarifications --- draft-ietf-oauth-transaction-tokens.md | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/draft-ietf-oauth-transaction-tokens.md b/draft-ietf-oauth-transaction-tokens.md index 2043602..5739fc4 100644 --- a/draft-ietf-oauth-transaction-tokens.md +++ b/draft-ietf-oauth-transaction-tokens.md @@ -151,9 +151,9 @@ Txn-Tokens are short-lived, signed JWTs {{RFC7519}} that assert the identity of ## Creating Txn-Tokens ### Initial Creation -Txn-Tokens are typically created when a workload is invoked using an endpoint that is externally visible, and is authorized using a separate mechanism, such as an OAuth {{RFC6749}} access token. The externally visible endpoint exchanges the received token for a transaction token before sending it to the workload. The transaction token may be obtained through a local interface, or it may be requested from a remote server. +Txn-Tokens are typically created when a workload is invoked using an endpoint that is externally visible, and is authorized using a separate mechanism, such as an OAuth {{RFC6749}} access token. The externally visible endpoint exchanges the external authorization token for a transaction token before sending it to the workload. The transaction token may be obtained through a local interface, or it may be requested from a remote server. -If the transaction token request is made via HTTP to a remote server, it SHOULD use RFC8693 as described in this specification. To do this, it invokes a special Token Service (the Txn-Token Service) and provides context that is sufficient for it to generate a Txn-Token. The context information provided to the Txn-Token Service MAY include: +If the transaction token request is made via HTTP to a remote server, it SHOULD use {{RFC8693}} as described in this specification. To do this, it invokes a special Token Service (the Txn-Token Service) and provides context that is sufficient for it to generate a Txn-Token. The context information provided to the Txn-Token Service MAY include: * The external authorization token (e.g., the OAuth access token) * An internally generated JWT representing the subject of the request @@ -437,12 +437,12 @@ The figure below {{figleaftxtokenbody}} shows a non-normative example of the JWT {: #figleaftxtokenbody title="Example: Txn-Token Body"} # Txn-Token Service -A Txn-Token Service implements a profile of the OAuth 2.0 Token Exchange {{RFC8693}} endpoint that can respond to Txn-Token issuance requests. This profile of the OAuth 2.0 Token Exchange {{RFC8693}} specification MUST be used to obtain Txn-Tokens. The unique properties of the Txn-Token requests and responses are described below. The Txn-Token Service MAY optionally support other OAuth 2.0 endpoints and features, but that is not a requirement for it to be a Txn-Token Service. +A Txn-Token Service SHOULD use {{RFC8693}} as described in this specification if it issues transaction tokens in response to HTTP requests. The unique properties of the Txn-Token requests and responses are described below. The Txn-Token Service MAY optionally support other OAuth 2.0 endpoints and features, but that is not a requirement for it to be a Txn-Token Service. Each Trust Domain that uses Txn-Tokens MUST have exactly one logical Txn-Token Service. # Requesting Txn-Tokens -A workload requests a Txn-Token from a Transaction Token Service using a profile of the OAuth 2.0 Token Exchange {{RFC8693}}. Txn-Tokens may be requested for both externally originating or internally originating requests. The profile describes how required and optional context can be provided to the Transaction Token Service in order for the Txn-Token to be issued. The request to obtain a Txn-Token using this method is called a Txn-Token Request, and a successful response is called a Txn-Token Response. The Txn-Token profile of the OAuth 2.0 Token Exchange {{RFC8693}} is described below. +A workload requests a Txn-Token from a Transaction Token Service. If the transaction token request is made via HTTP to a remote server, it SHOULD use {{RFC8693}} as described in this specification. Txn-Tokens may be requested for both externally originating or internally originating requests. The profile describes how required and optional context can be provided to the Transaction Token Service in order for the Txn-Token to be issued. The request to obtain a Txn-Token using this method is called a Txn-Token Request, and a successful response is called a Txn-Token Response. The Txn-Token profile of the OAuth 2.0 Token Exchange {{RFC8693}} is described below. ## Txn-Token Request {#txn-token-request} A workload requesting a Txn-Token must provide the Transaction Token Service with proof of its identity (client authentication), the purpose of the Txn-Token and optionally any additional context relating to the transaction being performed. Most of these elements are provided by the OAuth 2.0 Token Exchange specification and the rest are defined as new parameters. Additionally, this profile defines a new token type URN `urn:ietf:params:oauth:token-type:txn_token` which is used by the requesting workload to identify that it is requesting the Txn-Token Response to contain a Txn-Token. From 88d315d81d3ccf066cbb10d0de227261e85b877d Mon Sep 17 00:00:00 2001 From: PieterKas <90690777+PieterKas@users.noreply.github.com> Date: Mon, 29 Sep 2025 13:21:29 +0100 Subject: [PATCH 3/5] Update draft-ietf-oauth-transaction-tokens.md Co-authored-by: Brian Campbell <71398439+bc-pi@users.noreply.github.com> --- draft-ietf-oauth-transaction-tokens.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/draft-ietf-oauth-transaction-tokens.md b/draft-ietf-oauth-transaction-tokens.md index f731db1..0b4844d 100644 --- a/draft-ietf-oauth-transaction-tokens.md +++ b/draft-ietf-oauth-transaction-tokens.md @@ -154,7 +154,7 @@ Txn-Tokens are short-lived, signed JWTs {{RFC7519}} that assert the identity of ### Initial Creation Txn-Tokens are typically created when a workload is invoked using an endpoint that is externally visible, and is authorized using a separate mechanism, such as an OAuth {{RFC6749}} access token. The externally visible endpoint exchanges the external authorization token for a transaction token before sending it to the workload. The transaction token may be obtained through a local interface, or it may be requested from a remote server. -If the transaction token request is made via HTTP to a remote server, it SHOULD use {{RFC8693}} as described in this specification. To do this, it invokes a special Token Service (the Txn-Token Service) and provides context that is sufficient for it to generate a Txn-Token. The context information provided to the Txn-Token Service MAY include: +If the transaction token request is made via HTTP to a remote server, it MUST use {{RFC8693}} as described in this specification. To do this, it invokes a special Token Service (the Txn-Token Service) and provides context that is sufficient for it to generate a Txn-Token. The context information provided to the Txn-Token Service MAY include: * The external authorization token (e.g., the OAuth access token) * An internally generated JWT representing the subject of the request From 1f919589d55a6fe2b066e80e82119f18969a3b8a Mon Sep 17 00:00:00 2001 From: PieterKas <90690777+PieterKas@users.noreply.github.com> Date: Mon, 29 Sep 2025 13:21:55 +0100 Subject: [PATCH 4/5] Update draft-ietf-oauth-transaction-tokens.md Co-authored-by: Brian Campbell <71398439+bc-pi@users.noreply.github.com> --- draft-ietf-oauth-transaction-tokens.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/draft-ietf-oauth-transaction-tokens.md b/draft-ietf-oauth-transaction-tokens.md index 0b4844d..5d98f63 100644 --- a/draft-ietf-oauth-transaction-tokens.md +++ b/draft-ietf-oauth-transaction-tokens.md @@ -441,7 +441,7 @@ The figure below {{figleaftxtokenbody}} shows a non-normative example of the JWT A Txn-Token from an internal request would look much the same except the rctx and tctx field claims would be populated with information from the initiating workloads request. # Txn-Token Service -A Txn-Token Service SHOULD use {{RFC8693}} as described in this specification if it issues transaction tokens in response to HTTP requests. The unique properties of the Txn-Token requests and responses are described below. The Txn-Token Service MAY optionally support other OAuth 2.0 endpoints and features, but that is not a requirement for it to be a Txn-Token Service. +A Txn-Token Service uses {{RFC8693}} as described in this specification if it issues transaction tokens in response to HTTP requests. The unique properties of the Txn-Token requests and responses are described below. The Txn-Token Service MAY optionally support other OAuth 2.0 endpoints and features, but that is not a requirement for it to be a Txn-Token Service. Each Trust Domain that uses Txn-Tokens MUST have exactly one logical Txn-Token Service. From 98fff35f6b6d1a4a9922c995d7cafd6aecd0673c Mon Sep 17 00:00:00 2001 From: PieterKas <90690777+PieterKas@users.noreply.github.com> Date: Mon, 29 Sep 2025 13:22:12 +0100 Subject: [PATCH 5/5] Update draft-ietf-oauth-transaction-tokens.md Co-authored-by: Brian Campbell <71398439+bc-pi@users.noreply.github.com> --- draft-ietf-oauth-transaction-tokens.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/draft-ietf-oauth-transaction-tokens.md b/draft-ietf-oauth-transaction-tokens.md index 5d98f63..ac49c8a 100644 --- a/draft-ietf-oauth-transaction-tokens.md +++ b/draft-ietf-oauth-transaction-tokens.md @@ -446,7 +446,7 @@ A Txn-Token Service uses {{RFC8693}} as described in this specification if it is Each Trust Domain that uses Txn-Tokens MUST have exactly one logical Txn-Token Service. # Requesting Txn-Tokens -A workload requests a Txn-Token from a Transaction Token Service. If the transaction token request is made via HTTP to a remote server, it SHOULD use {{RFC8693}} as described in this specification. Txn-Tokens may be requested for both externally originating or internally originating requests. The profile describes how required and optional context can be provided to the Transaction Token Service in order for the Txn-Token to be issued. The request to obtain a Txn-Token using this method is called a Txn-Token Request, and a successful response is called a Txn-Token Response. The Txn-Token profile of the OAuth 2.0 Token Exchange {{RFC8693}} is described below. +A workload requests a Txn-Token from a Transaction Token Service. If the transaction token request is made via HTTP to a remote server, it MUST use {{RFC8693}} as described in this specification. Txn-Tokens may be requested for both externally originating or internally originating requests. The profile describes how required and optional context can be provided to the Transaction Token Service in order for the Txn-Token to be issued. The request to obtain a Txn-Token using this method is called a Txn-Token Request, and a successful response is called a Txn-Token Response. The Txn-Token profile of the OAuth 2.0 Token Exchange {{RFC8693}} is described below. ## Txn-Token Request {#txn-token-request} A workload requesting a Txn-Token must provide the Transaction Token Service with proof of its identity (client authentication), the purpose of the Txn-Token and optionally any additional context relating to the transaction being performed. Most of these elements are provided by the OAuth 2.0 Token Exchange specification and the rest are defined as new parameters. Additionally, this profile defines a new token type URN `urn:ietf:params:oauth:token-type:txn_token` which is used by the requesting workload to identify that it is requesting the Txn-Token Response to contain a Txn-Token.