In-app reader
**
Internet Engineering Task Force Sangam Das
Internet-Draft: draft-das-execution-finality-ai-interoperability-00
Intended status: Informational August 19, 2026
Expires: February 19, 2027
Breaking the Apple-Siri EU DMA Deadlock Without
Sacrificing Privacy or Security
Author: Sangam Das
Affiliation: Independent Inventor
Location: Balasore, Odisha, India
Email: info@sangamdas.com
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
https://www.ietf.org/1id-abstracts.html
The list of Internet-Draft Shadow Directories can be accessed at
https://www.ietf.org/shadow.html
Copyright Notice
Copyright (c) 2026 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of the
Trust Legal Provisions and are provided without warranty as described
in the Simplified BSD License.
Abstract
The Apple-Siri interoperability debate under the EU Digital Markets Act exposes a difficult technical question: how can third-party AI assistants gain meaningful access to device functions without forcing the platform to surrender privacy, security, or control over consequential actions?
This paper proposes an execution-finality architecture in which an AI assistant may request an action, but the request itself has no power to make that action effective. Each consequential operation remains in a Non-Effective State until protected infrastructure validates the requester, resource, destination, user intent where required, freshness, revocation state, and policy conditions.
Only then is narrowly scoped, non-bearer execution authority created. At the Finality Sink - the first boundary where the action can become externally effective - the system independently verifies that the real operation still matches what was authorized. Any mismatch, replay, substitution, expiry, or revocation causes fail-closed denial.
The key principle is simple:
Interoperability should grant participation, not uncontrolled execution authority.
This offers a possible technical path through the DMA deadlock: third-party assistants could participate meaningfully without requiring broad reusable permissions, while platforms retain strong privacy, security, revocation, anti-replay, and final-effect controls.
Execution-Finality Governance therefore reframes the problem from closed versus open to open participation with bounded, verifiable authority.
Table of Contents
1. Combined Technical Disclosure and Anticipatory Technical Objections
2. Security-Focused Layman Explanation of Third-Party AI Interoperability
3. Technical Objections and Responses
4. Security Considerations
5. IANA Considerations
6. Author's Address
EXECUTION-FINALITY ARCHITECTURE FOR AI INTEROPERABILITY
Combined Technical Disclosure and Anticipatory Technical Objections and Responses
========================================================================
PART I - TECHNICAL DISCLOSURE
========================================================================
Security-Focused Layman Explanation of Third-Party
AI Interoperability
Acknowledging Apple's Risk and EU's Operational Reality
The Genuine Problem: Apple's Concern Is Valid
Apple's worry about third-party AI interoperability is not bureaucratic obstruction. It is a real
technical and business risk.
What Apple Actually Fears
Once a third-party AI assistant runs on the iPhone with access equivalent to Siri, Apple
faces a true dilemma:
The assistant legitimately needs power to:
read a selected message
attach a selected file
send a message to one person
open an application
use the microphone for one task
initiate a payment
upload one document
change one device setting
But the moment Apple grants this power, several realistic attack surfaces open:
1. The assistant itself could be compromised. Not by user mistake-by actual breach,
supply-chain attack, or code injection.
2. The assistant's cloud infrastructure could be weaponized. Even if the on-device
code is honest, a compromised backend could send malicious instructions.
3. Prompt injection is a real, reproducible vulnerability. A malicious website or attacker-
controlled input can override the user's intent and redirect the assistant to exfiltrate
data.
4. Accessibility abuse is well-documented. Malware has repeatedly exploited
accessibility services to manipulate device functions without direct permission.
5. The permissions model has always leaked scope. An app granted file access can
attempt to read many files. An assistant allowed to send messages can attempt to send
others. This is not theoretical-it has happened.
6. Recovery is expensive or impossible. If a third-party assistant silently uploads the
user's message archive, medical records, or financial data to an attacker-controlled
server, Apple is liable. The user and regulators will hold Apple responsible, not the third
party.
7. Apple's own reputation is at stake. Even one high-profile compromise of user data via
third-party assistant access would damage iPhone trust globally.
This is not paranoia. This is the actual operating environment.
The Genuine Constraint: EU's Conditions Are Real
The EU is not blocking interoperability out of protectionism. It is enforcing real compliance
obligations:
Article 6(7) of the Digital Markets Act
The DMA requires gatekeepers to provide "effective interoperability" for digital assistants.
But "effective" does not mean "uncontrolled." The DMA text itself embeds constraints:
Interoperability must not "put at risk" the security and integrity of the gatekeeper's
services.
The gatekeeper may impose "proportionate, non-discriminatory conditions."
Risk mitigation is not optional-it is a legal requirement.
The EU is telling Apple: "You must interoperate, but you do not have to bet the
platform on third-party execution authority."
GDPR Article 32 (Security)
GDPR requires controllers and processors to implement:
encryption and pseudonymization of personal data
ability to restore availability and access upon data incident
ongoing integrity and confidentiality testing
If a third-party assistant accesses EU user data, Apple-as the platform controller-
has a non-delegable obligation to ensure that data remains secure. Apple cannot hand
off responsibility.
EU AI Act Article 14 (Oversight)
For high-risk AI systems, Article 14 requires:
"effective human oversight" proportionate to the risk
ability to intervene or override decisions
sufficient information for oversight personnel to understand the AI's basis
This is not asking for human review of every message send. It is asking: can the
system be monitored and interrupted if something goes wrong?
If a third-party assistant operates with uncontrolled execution authori
Discussion
Sign in to join the discussion.
Keep reading
Optional: create a free account to save items, track programs, and sync across web + app. Reading stays free.