Thanks Joe for the detailed review and comments. PRs are most welcome. If you want to raise a PR for Issue 8 in your list (Section 2.5) to start with it would be greatly appreciated.
I will raise issues for the issues raised. With gratitude Pieter On Sat, Aug 23, 2025 at 3:20 AM Joseph Salowey <j...@salowey.net> wrote: > > Here are some comments on the draft. In general, I think this work is very > useful and the spec is in pretty good shape despite the comments. I got > through most of the specification, but still need to review the security > considerations, will try to get that done in the next few days. I also would > like to file issues and PRs for these, but have not had a chance yet. If you > have chance let me know if there are ones I should prioritize (or > deprioritize). > > THanks, > > Joe > > Should section 1 mention information disclosure. One of the issues that > transaction tokens address is that it separates out the external and internal > domains so that externally presented credentials (access tokens) are not used > internally and therefore not vulnerable to disclosure within the internal > domain. > Section 2 perhaps the last sentence should mention a "recent" intentionally > invoked transaction > Section 2.2.1 first paragraph talks about "Txn-Tokens are typically created > when a workload is invoked using an endpoint that is externally visible" . > While I realize that this sentence leaves room for other cases such as when > the request is internal. I think the document could do more to discuss this > use case as it seems it would be important in most systems. Perhaps adding a > short discussion in this section (perhaps in the last paragraph of this > section) and in a few other relevant sections would be good. I'll try to get > a list or PR together, but it will not be this week, > Section 2.2.1 lists a bunch of MAY items in the request. It seems like there > should be some MUSTs somewhere in here? For example, the request MUST > contain some information about the subject of the request which could be one > of several options. I realize that 7.1 contains more normative information, > but this section seems to be a bit out of sync and not very informative. It > might also be useful to list the authentication requirements here at a high > level. > section 2.3 In the following sentence "and as a result MAY be used only for > the expected duration of an external invocation." the "MAY" seems incorrect > as it doesn't add anything to the requirement. It should be "MUST". > Section 2.3 - the length of some transactions may be variable and > unpredictable. Can the replacement workflow be used to extend the life of a > token within certain limits? > Section 2.4 - I find this description a bit hard to parse and perhaps a bit > restricted, for example it talks about externally invoked APIs. I think I > like the text in the last paragraph in section 2 better, > Section 2.5 - I think we should have an internally initiated example. I'll > work on some text to use in a PR, unless that would not be welcome. > Section 4.- Most of the terms in this section overlap with terms we define in > WIMSE arch spec as well (Workload, trust domain, External Endpoint, Call > Chain, etc). I don't think there is a lot of divergence, but it would be > good to make sure there isn't and maybe make them more common where it makes > sense. > Section 7.3 - does the validation of a self signed JWT require any signature > validation or is it treated as a unsigned object by the authorization server? > Section 7.3 the request context probably should undergo some > validation/authorization to make sure the caller is authorized to set > specific values. > Section 7.5.1 Shouldn't the txn-ctx value also be unmodified in a replacement > token? > Section 7.5.1 I can see value in the replacement token allowing for the > lifetime of the JWT to be extended. Sometimes a transaction may take longer > than expected. IF the token lifetime can be refreshed beyond the original > time then the transaction can succeed. THis also seems better than trying to > issue tokens with lifetimes that are longer than necessary for most > transactions. In this case the IAT claim could still reflect the original > token issue time so the token service can enforce a strict lifetime. > Section 7.6 could reference the WIMSE WIT as workload authentication option > > > On Fri, Aug 15, 2025 at 3:50 AM Lombardo, Jeff > <jeffsec=40amazon....@dmarc.ietf.org> wrote: >> >> From my reading, “a common security policy” is singular here to represent a >> functional stance, an authority, a delimited zone of control. >> >> Technically this security policy can be represented by multiple technical >> policies (decentralized, centralized, *BAC) that can apply and not, and if >> it does that could lead to a greenlight to process, a red light to stop, or >> a step up process. >> >> >> >> Which one is the outcome depends on the context of the request: which >> caller, which callee, for which purpose, under which conditions. >> >> >> >> But I respect that I might be too close to it to see an issue. >> >> >> >> Jean-François “Jeff” Lombardo | Amazon Web Services >> >> >> >> Architecte Principal de Solutions, Spécialiste de Sécurité >> Principal Solution Architect, Security Specialist >> Montréal, Canada >> >> ( +1 514 778 5565 >> >> Commentaires à propos de notre échange? Exprimez-vous ici. >> >> >> >> Thoughts on our interaction? Provide feedback here. >> >> >> >> From: Watson Ladd <watsonbl...@gmail.com> >> Sent: August 14, 2025 6:05 PM >> To: Atul Tulshibagwale <a...@sgnl.ai> >> Cc: oauth <oauth@ietf.org> >> Subject: [EXT] [OAUTH-WG] Re: WGLC for Transaction Tokens >> >> >> >> CAUTION: This email originated from outside of the organization. Do not >> click links or open attachments unless you can confirm the sender and know >> the content is safe. >> >> >> >> AVERTISSEMENT: Ce courrier électronique provient d’un expéditeur externe. Ne >> cliquez sur aucun lien et n’ouvrez aucune pièce jointe si vous ne pouvez pas >> confirmer l’identité de l’expéditeur et si vous n’êtes pas certain que le >> contenu ne présente aucun risque. >> >> >> >> >> >> >> >> Astra mortemque praestare gradatim >> >> >> >> On Mon, Aug 11, 2025, 8:21 PM Atul Tulshibagwale <a...@sgnl.ai> wrote: >> >> Hi Watson, >> >> >> >> The spec has the following definition of a Trust Domain in Section 4: >> >> "A collection of systems, applications, or workloads that share a common >> security policy. In practice this may include a virtually or physically >> separated network, which contains two or more workloads. The workloads >> within a Trust Domain may be invoked only through published interfaces." >> >> >> >> The idea is that a service receiving an invocation from another service >> within the same trust domain can verify the transaction token details to >> prevent "unfettered access". >> >> >> >> I think I understand what we want to say here. I just don't think that the >> words in the doc actually say that clearly. In particular a common security >> policy is a pretty nebulous thing; does it mean they all need to authorize >> the same set of operations by the same people? >> >> >> >> Perhaps we should say trust domain is the domain of services that trust a >> transaction token issuer, and explicitly say different services have >> different policies about what is allowed in it. >> >> >> >> >> >> Hope this helps, >> >> Atul >> >> >> >> On Tue, Aug 12, 2025 at 7:42 AM Watson Ladd <watsonbl...@gmail.com> wrote: >> >> >> >> >> >> On Mon, Aug 11, 2025, 3:08 PM Brian Campbell <bcampb...@pingidentity.com> >> wrote: >> >> Note that I hope/plan to do an actual review again (it's been awhile) for >> this WGCL but did want to jump in on one point below. >> >> >> >> On Mon, Aug 11, 2025 at 3:01 PM Watson Ladd <watsonbl...@gmail.com> wrote: >> >> I have some concerns: >> >> - Requiring the requesting service to be in the Trust Domain of the >> token seems backwards to me. Surely we want these tokens to cross >> trust domains. >> >> >> >> No, I believe transaction tokens are, and have been since their inception, >> appropriately scoped to be an "internal" construct for use within a single >> trust domain. >> >> >> >> Maybe the term trust domain has a connotation I'm missing but I would think >> that we're creating these precisely because service A can't be given >> unfettered access to all the things service B has access to, hence different >> trust domain. But maybe what I mean is not what was meant by trust domain. >> >> >> 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 > > _______________________________________________ > 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
