Jia, Meiling, On #6 — on-device agents in the cloud OAuth ecosystem. It reads as a communication question, but I think it sits inside a security one, so let me take it a little wider than communication alone.
Start with what the endpoint itself can see — presence, posture, local standing. This is where Yossif's #11 comes in: a condition-bound key that disappears when the condition is no longer met, so it signs only while those conditions hold. For everything in that set, the endpoint needs no communication at all. The key stops signing in the TLS key agreement and access stops. Nothing to send. For what the endpoint cannot see — the user withdrawing consent, the agent being distrusted — some external entity has to raise the signal. Usually that signal goes to the RP, not the endpoint, and CAEP is the standard way to carry it. There can be cases where the signal has to reach the endpoint instead, and that is what #6 seems to be about. I'm not sure there's an established way. CAEP or a lighter version of it can do it. Or that’s what you are trying to cover? But that path — a signal sent to the endpoint — is rarely needed. The endpoint terminates its mTLS on the conditions it already knows, and the external signals go to the RP. So there is rarely a need for the endpoint to talk back to the OAuth authority at all. I might be wrong though 😊. draft-winmagic-wimse-condition-bounded-credentials carries the detail. Happy to go into it if useful. Thi From: 陈佳 <[email protected]> Sent: Wednesday, July 22, 2026 4:37 AM To: oauth <[email protected]> Subject: [OAUTH-WG] Re: New Version Notification fordraft-chen-oauth-agent-authz-use-cases-01.txt You don't often get email from [email protected]<mailto:[email protected]>. Learn why this is important<https://aka.ms/LearnAboutSenderIdentification> CAUTION:This email originated from outside of the organization. Do not click links, open attachments or respond unless you recognize the sender and know that the content is safe. > Jeff Lombardo wrote on Mon, 13 July 2026 10:50 UTC: > "Here are some comments on the elements listed as Gaps..." > "you identify that OAuth is not capable of understand an intent. > True but is it the purpose of OAuth?" > "Impractical Revocation... write operations could be perform > through the usage of Transaction Tokens" > "If tokens are cryptographically bound to a client key, they > cannot be shared... See DPoP (RFC9449)" > "This is a big misconception. OAuth is perfectly capable of > handling claims... If you are looking for standards, you should > look at OpenID Foundation AuthZEN" > "there is progress in the right direction with ID JAG and > Transaction Token Authorization Grant Profile for OAuth Identity > and Authorization Chaining" Thanks, Blake, Yossi, Jeff, and Thi, for the detailed discussion. Your feedback is very helpful as we refine the draft. I agree with the specific technical points raised — especially the pointers to TXN tokens, DPoP, CIMD, ID-JAG, and AuthZEN. Each of these is moving in the right direction. However, I want to zoom out and look at the overall picture. Even though multiple OAuth-related projects exist, they currently lack a systematic connection. It is hard to see them forming a complete authorization solution for agent security. Let me illustrate with one concrete example: - Transaction Tokens can trace the full operation chain — good. - But what is their relationship with agent identity? - What about the agent's dynamic, per-operation permissions? - Can the existing building blocks answer this core question: an agent inherits permissions from the user, yet those permissions may change dynamically with each operation? I believe we need to answer the following questions systematically, often requiring cross-project collaboration: 1. Binding between agent identity and user identity — whom does the agent represent, and how is this binding expressed and verified during authorization? 2. Binding between agent identity and operation — which agent initiated each operation? How to prevent identity spoofing? 3. Traceability of agent actions — TXN tokens should serve as a post-hoc audit trail forming a complete "agent -> operation" trace tree. That tree does not exist today. 4. Non-repudiation of agent actions — once an operation is completed, can the agent or its principal deny it? We need cryptographic guarantees. 5. Permission inheritance — how does an agent inherit permissions from the user? What are the boundaries? Can inheritance be partial? 6. Local agent integration — how do on-device agents interact with the cloud-based OAuth ecosystem? This remains underexplored. 7. Intent propagation — the user's original intent should travel with each operation, so the executing party can verify consistency. Jeff's references are valuable, but they feel like scattered puzzle pieces. The challenge is not whether each piece exists, but whether they can be assembled into a coherent picture. We need a systematic solution, not isolated fixes for each sub-problem. The goal of this draft should be to identify these systemic gaps and provide a common reference framework for future cross-project collaboration. Looking forward to further discussion. Best regards, Jia Chen E-mail: [email protected]<mailto:[email protected]>
_______________________________________________ OAuth mailing list -- [email protected] To unsubscribe send an email to [email protected]
