Hello OAuth, Following discussion around my individual work on execution-finality for AI interoperability, I would appreciate guidance on whether the authorization problem described below is already cleanly representable through existing OAuth mechanisms, or whether there is a narrower protocol gap worth discussing in OAuth.
I am attaching a one-page architectural note: Attachment: Security_privacy_interoperability.pdf Title: Security and Privacy Without Surrendering Interoperability The Internet-Draft remains the technical source: https://datatracker.ietf.org/doc/draft-das-execution-finality-ai-interoperability/ <https://datatracker.ietf.org/doc/draft-das-execution-finality-ai-interoperability/2/> *Problem Space — EU Digital Markets Act and Apple/Siri Interoperability* A concrete example arises under Article 6(7) of the EU Digital Markets Act, where covered gatekeepers may be required to provide effective interoperability with hardware and software features controlled through an operating system or virtual assistant, while still applying measures necessary to protect integrity, security, and privacy. One practical example is interoperability between Apple’s iOS/Siri environment and third-party AI assistants. Meaningful interoperability may require a third-party assistant to reach consequential device functions such as messaging, files, payments, settings, sensors, application functions, or other OS-mediated capabilities. That creates a technical tension. A broad, reusable Siri-equivalent permission may provide meaningful interoperability, but it can also increase confused-deputy, prompt-injection, replay, destination-substitution, argument-manipulation, and scope-escalation risks. Conversely, narrowly pre-approved integrations can reduce exposure but may not provide effective interoperability for dynamically generated AI actions. The problem is therefore not simply whether an AI assistant has permission to use a capability. The narrower question is whether the authority presented at the point of effectuation is bound to the *exact instantiated act that was validated*. For example, an assistant may already be permitted to initiate a payment, send a message, modify a file, or invoke a tool, while the actual amount, recipient, destination, file, arguments, or other consequential details are generated only at runtime. This creates a distinction between: *permission to request an operation* and *authority for one exact instantiated act to become externally effective.* The proposed invariant is: 1. Commit the concrete candidate act, including relevant requester, resource, destination, consequence class, execution sink, epoch, nonce, and other load-bearing action attributes. 2. Protected validation produces authority bound to that specific act rather than a generally reusable permission. 3. At the effectuation boundary, the enforcing Resource Server / Finality Sink independently derives the operation that is actually about to occur and compares it with the committed and authorized candidate act. 4. Substitution, changed arguments, changed destination, replay, stale authorization, or sink mismatch fails closed. 5. Where required, equality and policy satisfaction can be demonstrated without exposing the underlying protected content itself. My question for OAuth is therefore: *Could this invariant already be constructed cleanly using RAR, Transaction Tokens, sender-constrained mechanisms such as DPoP, and normal Resource Server enforcement?* Or is there a remaining semantic gap around binding authorization to the *exact AI-generated candidate act* and requiring verification against the *actual effectuation* at the final enforcement boundary? I am not asking OAuth or IETF to standardize an operating system, hardware enclave, AI model, Apple/Siri implementation, or DMA compliance programme. The possible standards-relevant slice is narrower: interoperable authorization semantics and message objects for act-specific execution authority. If the existing OAuth mechanisms already provide this composition, pointers to the appropriate mechanism or architecture would be very useful. If not, I would appreciate guidance on whether this problem is appropriate for discussion in OAuth or elsewhere in the IETF. The Apple/Siri and DMA example is only one concrete deployment context. The same boundary can arise in Android, cloud agents, MCP/tool-calling systems, payment systems, enterprise agents, and other environments where AI dynamically constructs consequential actions under previously granted authority. Regards, Sangam Das Independent Inventor Balasore, India
Security_privacy_interoperability.pdf
Description: Adobe PDF document
_______________________________________________ OAuth mailing list -- [email protected] To unsubscribe send an email to [email protected]
