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". 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
