Thanks Brian for the detailed feedback and comments. I will open GitHub issues to track and address these.
With gratitude Pieter On Fri, Aug 22, 2025 at 10:18 PM Brian Campbell <bcampbell= 40pingidentity....@dmarc.ietf.org> wrote: > 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= > 40sgnl...@dmarc.ietf.org> wrote: > >> I support adoption. >> >> On Wed, Aug 6, 2025, 11:00 PM Dag Sneeggen <dag.sneeg...@signicat.com> >> 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 <rifaat.s.i...@gmail.com> >>> *Sent:* Wednesday, August 6, 2025 7:03:41 PM >>> *To:* oauth <oauth@ietf.org> >>> *Subject:* [OAUTH-WG] WGLC for Transaction Tokens >>> >>> You don't often get email from rifaat.s.i...@gmail.com. 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 -- oauth@ietf.org > To unsubscribe send an email to oauth-le...@ietf.org >
_______________________________________________ OAuth mailing list -- oauth@ietf.org To unsubscribe send an email to oauth-le...@ietf.org
