draft-das-execution-finality-ai-interoperability-00

Light

Dark

Auto

Internet Engineering Task Force Sangam Das<br>Internet-Draft: draft-das-execution-finality-ai-interoperability-00<br>Intended status: Informational August 19, 2026<br>Expires: February 19, 2027

Breaking the Apple-Siri EU DMA Deadlock Without

Sacrificing Privacy or Security

Author: Sangam Das<br>Affiliation: Independent Inventor<br>Location: Balasore, Odisha, India<br>Email: info@sangamdas.com

Status of This Memo

This Internet-Draft is submitted in full conformance with the<br>provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering<br>Task Force (IETF), its areas, and its working groups. Note that<br>other groups may also distribute working documents as Internet-<br>Drafts.

Internet-Drafts are draft documents valid for a maximum of six months<br>and may be updated, replaced, or obsoleted by other documents at any<br>time. It is inappropriate to use Internet-Drafts as reference<br>material or to cite them other than as "work in progress."

The list of current Internet-Drafts can be accessed at<br>https://www.ietf.org/1id-abstracts.html

The list of Internet-Draft Shadow Directories can be accessed at<br>https://www.ietf.org/shadow.html

Copyright Notice

Copyright (c) 2026 IETF Trust and the persons identified as the<br>document authors. All rights reserved.

This document is subject to BCP 78 and the IETF Trust's Legal<br>Provisions Relating to IETF Documents<br>(https://trustee.ietf.org/license-info) in effect on the date of<br>publication of this document. Please review these documents<br>carefully, as they describe your rights and restrictions with respect<br>to this document. Code Components extracted from this document must<br>include Simplified BSD License text as described in Section 4.e of the<br>Trust Legal Provisions and are provided without warranty as described<br>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<br>2. Security-Focused Layman Explanation of Third-Party AI Interoperability<br>3. Technical Objections and Responses<br>4. Security Considerations<br>5. IANA Considerations<br>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<br>AI Interoperability

Acknowledging Apple's Risk and EU's Operational Reality

The Genuine Problem: Apple's Concern Is Valid<br>Apple's worry about third-party AI interoperability is not bureaucratic obstruction. It is a real<br>technical and business risk.

What Apple Actually Fears<br>Once a third-party AI assistant runs on the iPhone with access equivalent to Siri, Apple<br>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...