I expressed some reservations about readiness for adoption at IETF 118 but was ultimately supportive of adoption too. In November of 2023 when the call for adoption was run.
I do believe this is useful work and would like to see it progress. Thank you to everyone that has contributed to getting it to this point. What follows is some WGLC feedback. I know this comes after the requested deadline for such and I do apologize. I started the review well within the deadline but have found it more onerous to complete than I'd hoped. And with those pleasantries out of the way, here's are some questions and a couple of suggestions: https://datatracker.ietf.org/doc/html/draft-ietf-oauth-transaction-tokens-06# ! Informational doesn't seem like the appropriate intended status. https://datatracker.ietf.org/doc/html/draft-ietf-oauth-transaction-tokens-06#section-abstract-1 I guess at some level all requests are programmatic but the use of the word here seems unnecessary or limiting depending on one's interpretation of it. https://datatracker.ietf.org/doc/html/draft-ietf-oauth-transaction-tokens-06#section-1 and https://datatracker.ietf.org/doc/html/draft-ietf-oauth-transaction-tokens-06#section-2 There are some pretty bold claims made in these sections that I'd suggest could be tempered a bit. The transaction token construct can help an architecture achieve an improved security posture but to say that they ensure these properties is IMO overstating things. https://datatracker.ietf.org/doc/html/draft-ietf-oauth-transaction-tokens-06#name-initial-creation and 1-3 https://datatracker.ietf.org/doc/html/draft-ietf-oauth-transaction-tokens-06#name-basic-flow and https://datatracker.ietf.org/doc/html/draft-ietf-oauth-transaction-tokens-06#name-txn-token-service and https://datatracker.ietf.org/doc/html/draft-ietf-oauth-transaction-tokens-06#section-7 and maybe elsewhere like https://datatracker.ietf.org/doc/html/draft-ietf-oauth-transaction-tokens-06#section-6 I believe it'd be worthwhile to account/allow for the case where the gateway or external endpoint that handles the invocation from the outside to itself act as the Txn-Token Service and do the "exchange" and issuance of the Txn-Token internally without an RFC8693 Token Exchange call. https://datatracker.ietf.org/doc/html/draft-ietf-oauth-transaction-tokens-06#name-replacement-txn-tokens et al. I'm going to (again maybe?) question whether the replacement concept is really needed? I know, I know, somebody has a use case. There's *always* a use case. But is it worth it? Does it add to or detract from the overall concept and quality of the document? https://datatracker.ietf.org/doc/html/draft-ietf-oauth-transaction-tokens-06#name-txn-token-lifetime "(order of minutes, e.g., 5 minutes)" doesn't read well to my eye. Maybe "(on the order of minutes or less)" or maybe just drop the parenthetical. "Except in the case where the request is made using a self-signed JWT" - why this exception? https://datatracker.ietf.org/doc/html/draft-ietf-oauth-transaction-tokens-06#name-benefits-of-txn-tokens I had a difficult time comprehending this. Consider rewording. Or removing, it seems a bit out of place too. https://datatracker.ietf.org/doc/html/draft-ietf-oauth-transaction-tokens-06#section-4-1.12.1 Authorization Context, to me anyway, seems like too general of a concept/thing to "define" as a "JSON object". https://datatracker.ietf.org/doc/html/draft-ietf-oauth-transaction-tokens-06#section-5.2-2.10.1 If "txn" is going to be required, and probably regardless, I think some more definition or at least rational is needed here. https://datatracker.ietf.org/doc/html/draft-ietf-oauth-transaction-tokens-06#section-5.2-2.12.1 I find it odd to talk about things that this thing is not. I'd suggest dropping the OpenID Connect stuff here. https://datatracker.ietf.org/doc/html/draft-ietf-oauth-transaction-tokens-06#section-5.2-2.14.1 and https://datatracker.ietf.org/doc/html/draft-ietf-oauth-transaction-tokens-06#name-purpose-claim Not sure how to articulate this but the 'purp' claim feels simultaneously too narrow and too general to be meaningfully useful. Particularly for being required. And with the tctx claim also. https://datatracker.ietf.org/doc/html/draft-ietf-oauth-transaction-tokens-06#section-5.2.2 and a few places I'm not sure the StringOrURI data type has proven to be real useful. Just say it's a string. Or a URI, if that's needed. But the conditional must be a URI if it has a colon thing isn't something to propagate IMHO. StringOrURI also isn't properly defined or referenced, which wouldn't be an issue if you stop using it. https://datatracker.ietf.org/doc/html/draft-ietf-oauth-transaction-tokens-06#section-5.2.3-3 TTS is just used out of the blue here. Expand on first use or even just use the name throughout. https://datatracker.ietf.org/doc/html/draft-ietf-oauth-transaction-tokens-06#section-7.1-5.1.1 and https://datatracker.ietf.org/doc/html/draft-ietf-oauth-transaction-tokens-06#section-7.1-5.2.1 and https://datatracker.ietf.org/doc/html/draft-ietf-oauth-transaction-tokens-06#section-7.2.2-1 Is there actual reason to have these parameters base64url/BASE64URL (which is definitely not defined in RFC6848 "Specifying Civic Address Extensions in the Presence Information Data Format Location Object (PIDF-LO)") encoded? Some other work out of this WG, like R[AR]FC9396, has utilized application/x-www-form-urlencoded for JSON without issue (that I'm aware of anyway). https://datatracker.ietf.org/doc/html/draft-ietf-oauth-transaction-tokens-06#section-7.1-5.2.1 The 'MUST remain immutable' here in the request parameter definition is rather odd and could easily be interpreted to mean something that is probably not intended. https://datatracker.ietf.org/doc/html/draft-ietf-oauth-transaction-tokens-06#section-7.1-6 and https://datatracker.ietf.org/doc/html/draft-ietf-oauth-transaction-tokens-06#name-mutual-authentication-of-th I know there's some desire to use OAuth 2.0 Token Exchange [RFC8693] without necessarily pulling in all the other features/baggage of being an full blown authorization server but I find it hard to reconcile that a requesting workload is required to authenticate, the exact client authentication mechanism is out of scope, there are quite a few exact normative requirements about client authentication mechanisms (including a MUST on pre-configured sets?!), and there's no mention or acknowledgement of the existing standardized mechanisms for client authentication to an authorization server. Self-signed subject tokens and actor tokens seem potentially topically relevant as well. https://datatracker.ietf.org/doc/html/draft-ietf-oauth-transaction-tokens-06#section-7.6-4 Some of the bullets suggest authentication of the server via JWT, which is probably not a good idea here (or anywhere?). https://datatracker.ietf.org/doc/html/draft-ietf-oauth-transaction-tokens-06#name-txn-token-http-header The "txn-token" header [field] should maybe also be constrained to a single value and is request only? Maybe some other things too that might be desirable for an HTTP header field definition. YMMV but there will likely be questions with its registration. https://datatracker.ietf.org/doc/html/draft-ietf-oauth-transaction-tokens-06#section-7.2.1-2.1.1 There's a SHALL here towards the content of an optional thing, which is maybe implying more than is intended. https://datatracker.ietf.org/doc/html/draft-ietf-oauth-transaction-tokens-06#section-7.2.2-2.2.1 An expiration time on content that is not integrity protected doesn't seem like a good thing for a whole variety of reasons. https://datatracker.ietf.org/doc/html/draft-ietf-oauth-transaction-tokens-06#section-7.3-7 I would not include text like "This claim MUST be omitted if not set." https://datatracker.ietf.org/doc/html/draft-ietf-oauth-transaction-tokens-06#section-7.3-8 I realize this has (probably) been discussed but the need for the new purp claim is unclear to me. Or not compiling. https://datatracker.ietf.org/doc/html/draft-ietf-oauth-transaction-tokens-06#section-7.4-3 MUST NOT on expires_in and scope here seems unnecessary and limiting, no? With some reconciling of scope and purp, as alluded to previously, scope could be useful to know without digging into the Txn-Token. And expires_in is RECOMMENDED RFC8693 https://datatracker.ietf.org/doc/html/draft-ietf-oauth-transaction-tokens-06#section-9.1-3 As the comment above, I disagree with this. Discussing scope and purp in "Txn-Token Lifetime" is also kinda odd. https://datatracker.ietf.org/doc/html/draft-ietf-oauth-transaction-tokens-06#name-client-authentication The first sentence is redundant with OAuth 2.0 Token Exchange itself. Sometimes restating things is worthwhile but I don't think that's the case here. The second sentence with "the actor_token MUST authenticate the identity of the requesting workload" seems overly restrictive. What if the authentication has happened via other means and the actor_token is there to convey some other notion of delegation or something? There's a lot more to "Client Authentication", the section name, than these two sentences. Consider something different. Or something. https://datatracker.ietf.org/doc/html/draft-ietf-oauth-transaction-tokens-06#name-scope-and-purpose-processin Okay but scope can still be used to convey scope, even if it's inside and/or more granular and/or different. https://datatracker.ietf.org/doc/html/draft-ietf-oauth-transaction-tokens-06#name-identifying-call-chains I would argue that a Txn-token typically does not represent the call-chain and any useful advice about the txn claim that follows that opening is lost (to me anyway) in thinking about the erroneous statement. https://datatracker.ietf.org/doc/html/draft-ietf-oauth-transaction-tokens-06#name-transaction-tokens-are-not- "Transaction tokens represent*s*" typo and "[Mutual Authentication of the Txn-Token Request]{Mutual-Authentication-of-the-Txn-Token-Request}" some kind of tooling mishap. Do you want to include an informational reference to https://datatracker.ietf.org/doc/draft-ietf-wimse-s2s-protocol/ here as a maybe a helpful pointer to an aspiring standard that might be of value in this context? (full disclosure that I'm listed as a co-author on that and one of the co-authors of the draft in question is co-chair of the other WG but I do think it'd be a useful pointer despite the nepotism) https://datatracker.ietf.org/doc/html/draft-ietf-oauth-transaction-tokens-06#section-9.8 and https://datatracker.ietf.org/doc/html/draft-ietf-oauth-transaction-tokens-06#section-9.10 seem like they could maybe be combined? https://datatracker.ietf.org/doc/html/draft-ietf-oauth-transaction-tokens-06#section-11.2-1.3.1 It's not impossible that one of the Designated Experts[sic] for this registry will have thoughts similar to those expressed herein about the purp claim. https://datatracker.ietf.org/doc/html/draft-ietf-oauth-transaction-tokens-06#name-jwt-claims-registry-content One or more of those Designated Experts[sic] might also wonder about a seeming inconsistency in referenced sections in the Specification Document fields. https://datatracker.ietf.org/doc/html/draft-ietf-oauth-transaction-tokens-06#name-acknowledgements I do appreciate the Contributors section below (and being in it) but I suspect it is missing some people that could/should be listed here in the Acknowledgements. But if Acknowledgments is only going to thank "the contributors and the OAuth working group members" then maybe just remove it? https://datatracker.ietf.org/doc/html/draft-ietf-oauth-transaction-tokens-06#name-document-history I know that "Document History" will be "removed from final specification" but the draft revisions do stick around with that content. The very partial history and use of an acronym not used anywhere else in the document here give a kind of off putting vibe. Speaking of partial history, is there reason why the datatracker history doesn't associate with https://datatracker.ietf.org/doc/draft-tulshibagwale-oauth-transaction-tokens/ ? And I see now, from reading the messages below again, that I had the dates wrong and this comes on the deadline rather than after as I'd stated previously (allowing for time zones). So another apology is in order - this time for the erroneous previous apology. On Thu, Aug 7, 2025 at 9:27 PM Atul Tulshibagwale <atul= [email protected]> wrote: > I support adoption. > > On Wed, Aug 6, 2025, 11:00 PM Dag Sneeggen <[email protected]> > wrote: > >> I support adoption. A great initiative which I think will solve real >> world issues. >> >> Sent from Outlook for Android <https://aka.ms/AAb9ysg> >> ------------------------------ >> *From:* Rifaat Shekh-Yusef <[email protected]> >> *Sent:* Wednesday, August 6, 2025 7:03:41 PM >> *To:* oauth <[email protected]> >> *Subject:* [OAUTH-WG] WGLC for Transaction Tokens >> >> You don't often get email from [email protected]. Learn why this >> is important <https://aka.ms/LearnAboutSenderIdentification> >> 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 >> > -- _CONFIDENTIALITY NOTICE: This email may contain confidential and privileged material for the sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited. If you have received this communication in error, please notify the sender immediately by e-mail and delete the message and any file attachments from your computer. Thank you._
_______________________________________________ OAuth mailing list -- [email protected] To unsubscribe send an email to [email protected]
