Hi folks, I have some feedback, below. Happy to file it as GH issues if that is helpful.
Cheers, Dan At https://www.ietf.org/archive/id/draft-ietf-oauth-transaction-tokens-06.html#section-2-3 I would change: --- Cryptographically protected Txn-Tokens ensure that downstream workloads cannot make unauthorized modifications to such information, and cannot make spurious calls without the presence of an intentionally invoked transaction. -> Cryptographically protected Txn-Tokens ensure that downstream workloads cannot make unauthorized modifications to such information, and cannot make spurious calls. --- seems that you can either have a spurious call or have an "intentionally invoked transaction", not both, so the "without" clause is not needed. At https://www.ietf.org/archive/id/draft-ietf-oauth-transaction-tokens-06.html#section-2.2.1-2.1.1 I'd suggest combining these two bullet points: --- - The external authorization token (e.g., the OAuth access token) - An internally generated JWT representing the subject of the request -> - The external authorization token (e.g., the OAuth access token) or an internally generated JWT representing the subject of the request --- Because it seems like these are mutually exclusive ( per https://www.ietf.org/archive/id/draft-ietf-oauth-transaction-tokens-06.html#section-2.2.1-4 ) At https://www.ietf.org/archive/id/draft-ietf-oauth-transaction-tokens-06.html#section-2.2.2-2 I would link to the relevant security section? https://www.ietf.org/archive/id/draft-ietf-oauth-transaction-tokens-06.html#name-replacement-tokens At https://www.ietf.org/archive/id/draft-ietf-oauth-transaction-tokens-06.html#section-2.3 would change the wording slightly for readability. --- "order of minutes, e.g., 5 minutes" -> "on the order of minutes, e.g., 5 minutes" --- In the second chart, https://www.ietf.org/archive/id/draft-ietf-oauth-transaction-tokens-06.html#section-2.5.2-3 wouldn't it be clearer to just repeat the same steps? Or is the "same as above" pattern better/typical? I couldn't find examples of RFCs that have closely related charts. At https://www.ietf.org/archive/id/draft-ietf-oauth-transaction-tokens-06.html#section-5.2-2.2.1 I think this is cleare: --- "The iss claim MUST be used in cases where the signing keys are not predetermined or it is desired that the Txn-Token Service signs with unique keys." -> "The iss claim MUST be used in cases where the signing keys are not predetermined. The iss claim MUST be used when the Txn-Token Service signs each Txn-Token with a unique key." --- At https://www.ietf.org/archive/id/draft-ietf-oauth-transaction-tokens-06.html#section-5.2-2.6.1 I'm confused about the aud claim, particularly the second sentence. --- "This identifier MUST uniquely identify the Trust Domain to prevent the Txn-Token from being accepted outside it's current Trust Domain." --- This seems confusing to me. Who is making sure that this uniquely identifies the Trust Domain? This implies a larger coordinating entity (presumably a company but maybe not) that is an implicit assumption. What is an example of a unique identifier that would meet this requirement? At https://www.ietf.org/archive/id/draft-ietf-oauth-transaction-tokens-06.html#section-5.2-2.12.1 you could link to the OpenID Connect spec, as you do further below. At https://www.ietf.org/archive/id/draft-ietf-oauth-transaction-tokens-06.html#section-5.2-2.14.1 - why is String capitalized? At https://www.ietf.org/archive/id/draft-ietf-oauth-transaction-tokens-06.html#name-purpose-claim is purp designed to be human readable, machine parseable or both (or left undefined and we can use any value)? At https://www.ietf.org/archive/id/draft-ietf-oauth-transaction-tokens-06.html#name-requester-context --- this MAY include the IP address information of the originating user" -> this MAY include the IP address information of the originating request" --- At https://www.ietf.org/archive/id/draft-ietf-oauth-transaction-tokens-06.html#section-5.2.2-3.1.1 the req_ip description needs a period for consistency At https://www.ietf.org/archive/id/draft-ietf-oauth-transaction-tokens-06.html#section-5.2.2-3.1.1 I would remove "robotic". Not sure what it adds. At https://www.ietf.org/archive/id/draft-ietf-oauth-transaction-tokens-06.html#section-5.2.2-3.3.1 I'm confused about the difference between sub and req_wl, especially for jobs that are kicked off internally. Is it tied to the end user (as is typical with JWTs)? If so, may be worth calling out when it is first mentioned. Would change call-chain to Call Chain and call chain to Call Chain, since you define that term. saw this multiple times. https://www.ietf.org/archive/id/draft-ietf-oauth-transaction-tokens-06.html#section-5.2.3-1 https://www.ietf.org/archive/id/draft-ietf-oauth-transaction-tokens-06.html#section-9.1-1 https://www.ietf.org/archive/id/draft-ietf-oauth-transaction-tokens-06.html#name-creating-replacement-txn-to At https://www.ietf.org/archive/id/draft-ietf-oauth-transaction-tokens-06.html#section-5.2.3-3 "the tctx field contains the actual authorizaton details that are determined by the TTS. " Weird to me that this is so crucial, but is not a MUST in the request, (per https://www.ietf.org/archive/id/draft-ietf-oauth-transaction-tokens-06.html#section-5.2-2.16.1 ) . What are the scenarios where the TTS would not provide a tctx field? Section 5.2.3.1 applies to the rctx claim, not the tctx, and should be numbered 5.2.2.1 At https://www.ietf.org/archive/id/draft-ietf-oauth-transaction-tokens-06.html#section-7.1-3.2.1 is the `audience` parameter the same as the `aud` claim in section 5.2? It appears related but different based on the non-normative examples? This is the only mention of the term "Trust Domain name" in the entire document so I'm confused as to what goes there. At https://www.ietf.org/archive/id/draft-ietf-oauth-transaction-tokens-06.html#section-7.1-3.5.2.4.1 I thought we were always promised an access token or a self-signed JWT. per https://www.ietf.org/archive/id/draft-ietf-oauth-transaction-tokens-06.html#section-2.2.1-4 . Maybe 2.2.1 needs to be updated? At https://www.ietf.org/archive/id/draft-ietf-oauth-transaction-tokens-06.html#section-7.1-3.5.2.1.1 would change: --- An inbound token received by an API Gateway -> A token received by an external endpoint --- Seems more in keeping with the nomenclature used elsewhere in the doc. At https://www.ietf.org/archive/id/draft-ietf-oauth-transaction-tokens-06.html#section-7.1-3.5.1 it is unclear to me what the subject of the transaction is? That didn't get defined above, would be nice to have it defined. At https://www.ietf.org/archive/id/draft-ietf-oauth-transaction-tokens-06.html#section-7.2.1-2.1.1 The draft says "The Txn-Token Service SHALL use this value in determining the req_wl value in the Txn-Token issued in response to this request." *determining* is doing a lot of work here. Is it the exact value or some derivative? If a derivative, what is the process? Same comment for sub claim just below. At https://www.ietf.org/archive/id/draft-ietf-oauth-transaction-tokens-06.html#section-7.2.1-2.5.1 The draft says "This should be a very short duration (order of seconds) in order to prevent any abuse of the JWT." should "this should" be "this SHOULD" or "this MUST"? (capitalized) At https://www.ietf.org/archive/id/draft-ietf-oauth-transaction-tokens-06.html#section-7.1-5.1.1 the draft says how the Transaction Token Service uses the "request_context" claim is out of scope, but in https://www.ietf.org/archive/id/draft-ietf-oauth-transaction-tokens-06.html#section-7.3-9 it says to add it to the rctx claim. I'm confused, isn't that specifying how the claim is used? At https://www.ietf.org/archive/id/draft-ietf-oauth-transaction-tokens-06.html#section-7.4-2.2.1 I would change: --- The following values defined in [RFC8693] MUST be included in the Txn-Token Response: -> The following values defined in [RFC8693] MUST be included in a successful Txn-Token Response: --- I got confused by the error sentence before this sentence, so adding a clarifying "successful" phrase would be helpful. At https://www.ietf.org/archive/id/draft-ietf-oauth-transaction-tokens-06.html#name-creating-replacement-txn-to The draft says "A workload within a call chain may request the Transaction Token Service to replace a Txn-Token." awkward phrasing. Maybe "When part of a Call Chain needs a new transaction token, it can make a request to the Transaction Token Service to replace the current one." At https://www.ietf.org/archive/id/draft-ietf-oauth-transaction-tokens-06.html#section-7.5.1-2.6.1 there's a missing 'a': --- "MUST NOT issue replacement Txn-token with lifetime exceeding the lifetime of the originally presented token" -> "MUST NOT issue a replacement Txn-Token with lifetime exceeding the lifetime of the originally presented token" --- Also should check for proper casing of Txn-Token throughout the doc. At https://www.ietf.org/archive/id/draft-ietf-oauth-transaction-tokens-06.html#section-7.5.2-1 The draft says "The scope value in the replacement request, if different from that in the original Txn-Token, MUST NOT increase the authorization surface beyond that of the original Txn-Token." "authorization surface" is kinda vague, but I suppose it leaves some flexibility up to the Transaction Token Service (to determine that a different read-only scope is decreasing the surface when a read-write scope was requested, for example). At https://www.ietf.org/archive/id/draft-ietf-oauth-transaction-tokens-06.html#section-8-1 I would change: --- Note that the standard HTTP Authorization header MUST NOT be used because that may be used by the workloads to communicate channel authorization. -> The Authorization HTTP header MUST NOT be used because that may be used by the workloads for other purposes. --- I have no idea what channel authorization is, but I think it is enough for implementers to know they MUST NOT use that header. At https://www.ietf.org/archive/id/draft-ietf-oauth-transaction-tokens-06.html#section-8.1 The value of this header MUST be the JWT that represents the Txn-Token. this was a bit vague, because I didn't think the JWT represented the Txn-Token, I thought it *was* the Txn-Token. I suppose this means there's no 'Bearer' or other prefix? Also, can we get a sample call here:: POST /internal-microservice/endpoint HTTP 1.1 Txn-Token: ey... At https://www.ietf.org/archive/id/draft-ietf-oauth-transaction-tokens-06.html#section-9.1-1 should we uppercase the SHOULD? --- Even for long-running "batch" jobs, a longer-lived access token should be used to initiate the request to the batch endpoint. -> Even for long-running "batch" jobs, a longer-lived access token SHOULD be used to initiate the request to the batch endpoint. --- At https://www.ietf.org/archive/id/draft-ietf-oauth-transaction-tokens-06.html#name-client-authentication the draft adds new parameters to the request that are not outlined in the request section which is here: https://www.ietf.org/archive/id/draft-ietf-oauth-transaction-tokens-06.html#section-5.2 Should the actor params be included in section 5.2? Or a note that all parameters available to the exchange token endpoint are part of txn tokens (if true)? The former seems clearer to me. At https://www.ietf.org/archive/id/draft-ietf-oauth-transaction-tokens-06.html#name-replacement-tokens it is unclear to me whether these sentences are related to the workload or the TTS or both? Seems like the first is the workload and the latter two tasks are for the TTS, but I'm not sure. I would either use TTS everywhere or I'd expand it. There's a mix of TTS, Transaction Token Service, and Txn-Token Service. I'm confused about the txn claim https://www.ietf.org/archive/id/draft-ietf-oauth-transaction-tokens-06.html#section-7.3-6 says it MUST be set. https://www.ietf.org/archive/id/draft-ietf-oauth-transaction-tokens-06.html#name-identifying-call-chains says setting it is RECOMMENDED. which is correct or am I missing some context? At https://www.ietf.org/archive/id/draft-ietf-oauth-transaction-tokens-06.html#name-transaction-token-service-d it references workloads need to figure out "which Transaction Token Service" to use. But I thought there was only one logical TTS, so why would a workload have to choose between these? https://www.ietf.org/archive/id/draft-ietf-oauth-transaction-tokens-06.html#section-6-2 and it is implied that workloads live in one trust domain here: https://www.ietf.org/archive/id/draft-ietf-oauth-transaction-tokens-06.html#section-4-1.2.1 What am I missing? At https://www.ietf.org/archive/id/draft-ietf-oauth-transaction-tokens-06.html#section-9.8-2 says workloads should authenticate to a config service, but https://www.ietf.org/archive/id/draft-ietf-oauth-transaction-tokens-06.html#section-7.6-1 says client MUST perform mutual authetication with the TTS. Why not require it for the configuration that leads the workload to the TTS? At https://www.ietf.org/archive/id/draft-ietf-oauth-transaction-tokens-06.html#section-9.10-1 would change: --- the workload must ensure that it authenticates -> the workload MUST ensure that it authenticates --- At https://www.ietf.org/archive/id/draft-ietf-oauth-transaction-tokens-06.html#section-9.12 there is a busted link: "Mutual Authentication of the Txn-Token Request" At https://www.ietf.org/archive/id/draft-ietf-oauth-transaction-tokens-06.html#section-10.2 would clarify/use MUST: --- Complete Txn-Tokens must not be logged verbatim. -> Complete Txn-Tokens MUST not be logged verbatim. --- At https://www.ietf.org/archive/id/draft-ietf-oauth-transaction-tokens-06.html#section-11.4-2.2.1 there is no value for the 'type' Thanks, Dan On Wed, Aug 6, 2025 at 11:04 AM Rifaat Shekh-Yusef <[email protected]> wrote: > All, > > As per the discussion in Madrid, this is a *WG Last Call *for the *Transaction > Tokens *document. > https://www.ietf.org/archive/id/draft-ietf-oauth-transaction-tokens-06.html > > Please, review this document and reply on the mailing list if you have any > comments or concerns, by August 22nd. > > Regards, > Rifaat & Hannes > > _______________________________________________ > OAuth mailing list -- [email protected] > To unsubscribe send an email to [email protected] >
_______________________________________________ OAuth mailing list -- [email protected] To unsubscribe send an email to [email protected]
