[OAUTH-WG] Re: WGLC for Transaction Tokens

[Pieter Kasselman <[e-mail]>]

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 <[e-mail]> 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=[e-mail]> 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
>>
>> ( [phone]
>>
>> Commentaires à propos de notre échange? Exprimez-vous ici.
>>
>>
>>
>> Thoughts on our interaction? Provide feedback here.
>>
>>
>>
>> From: Watson Ladd <[e-mail]>
>> Sent: August 14, 2025 6:05 PM
>> To: Atul Tulshibagwale <[e-mail]>
>> Cc: oauth <[e-mail]>
>> 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 <[e-mail]> 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 <[e-mail]> wrote:
>>
>>
>>
>>
>>
>> On Mon, Aug 11, 2025, 3:08 PM Brian Campbell <[e-mail]> 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 <[e-mail]> 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 -- [e-mail]
>> To unsubscribe send an email to [e-mail]
>>
>> _______________________________________________
>> OAuth mailing list -- [e-mail]
>> To unsubscribe send an email to [e-mail]
>
> _______________________________________________
> OAuth mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]