Hi Dan, Thank you so much for your thorough and thoughtful review. My sincere apologies for not responding sooner!
The editors will be taking this feed back and start work on a PR to update the spec. No need to create issues unless you want to:) We can pull your comments to the PR. I’ll drop a few comments inline focusing on the non-editorial feedback. George Fletcher Identity Standards Architect Practical Identity LLC > On Aug 14, 2025, at 7:55 PM, Dan Moore <[email protected]> > wrote: > > 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. I agree. I think the point of the second sentence is that Txn-Tokens prevent a security issue of intermediate workloads, if compromised, being able to invoke APIs with arbitrary parameter values where the Txn-Token can make those parameter values immutable. We will work on cleaning up the language and whether this secondary point is even necessary. > > 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. We’ll take a look at this. I think the main point we are trying to convey is that obtaining a replacement transaction token happens in a different context and wanted to call that out. > > 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? One of the key tenants of a transaction token is that it is not usable from “outside” its trust domain. So if a Txn-Token is leaked to an attacker, the attacker can not present it to the externally facing APIs. As for the identifier of the “trust domain” it can be an arbitrary string. Our assumption is that requirements around the value are out of scope for the spec. Generally, I agree with your assessment. A deployment would know the value being provided by the Transaction Token Service and the workload can check whether this Txn-Token is valid for the trust domain in which that workload is deployed. > > 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? This is to signify that the value type is a JSON String. > > 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)? This is a great question and one that may need more clarity. The ‘purp’ claim is intended to be a fine-grained purpose for the transaction that is usable (machine understandable) by a workload when making authorization decisions. > > 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. Good point. We can clarify the text. > > 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? Thanks. One possible use case is when the key values that need to be immutable are already present in the Txn-Token such as the only value required is the ’sub’. We will look at cleaning up the language. > > 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. Yes. Since this spec profiles the Token Exchange RFC, we kept the Token Exchange parameters for the request call. As for the value, yes it is the same value as will appear in the `aud` claim. We will clean up the language to make this more clear. > > 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? We will clean up the language. Thanks! > > 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. Generally, the subject is the identity for which the transaction is being invoked. Agree we can make this clearer. > > 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. I agree. This is not clarified and needs to be. Using the ‘iss’ string may be the simplest. > > 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 this point, we weren’t ready to make it a MUST but I agree a SHOULD makes sense. > > 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? The intent is to allow the Transaction Token Service to determine which data from the inbound `request_context` it wants to put into the Txn-Token as there could be PII data that isn’t relevant to the transaction and should not be propagated. > > 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). Yes. I’m not sure how to make this super concrete as authorization within a trust domain is not currently standardized in any way. If you have a suggestions for better wording, we would appreciate that! > > 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… > Great points. The intent is that the value of the header is the Txn-Token without any scheme (since in this spec Txn-Tokens are intentionally bearer tokens) > 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. Yes, all the available parameters need to be described. Good catch! > > 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. Yes, this language needs to be clearer. The intent is that for replacement Txn-Tokens, there are additional validations besides just the TTS signature and correct trust domain identifier. The receiving workload may want to validate if it accepts replacement Txn-Tokens requested by the identified workload (the one that requested the replacement Txn-Token). > > 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? Yes, we need to clean up the language. There was some IETF feedback that not all deployments want to set the `txn` value. > > 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? The trust domain could be geo-graphically distributed and hence there may be a TTS in each region. The requesting software needs to determine which of these logical instances to use for its request. > > 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? The expectation is that read access to the configuration data is available to anyone in the trust domain. Hence mutual authentication is not required. By configuration data, the intent is for .well-known/<config-data> not requesting workload specific configuration data. > > 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] > <mailto:[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] <mailto:[email protected]> >> To unsubscribe send an email to [email protected] >> <mailto:[email protected]> > > > > > > > > > > _______________________________________________ > 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]
