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
