Breaking the Apple–Siri DMA Deadlock Without Sacrificing Privacy or Security

sangamdas1 pts0 comments

draft-das-execution-finality-ai-interoperability-00 - Breaking the Apple-Siri EU DMA Deadlock Without Sacrificing Privacy or Security

Skip to main content

Javascript disabled? Like other modern websites, the IETF Datatracker relies on Javascript.<br>Please enable Javascript for full functionality.

Breaking the Apple-Siri EU DMA Deadlock Without Sacrificing Privacy or Security

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

Status

Email expansions

History

Versions:

This document is an Internet-Draft (I-D).<br>Anyone may submit an I-D to the IETF.<br>This I-D is not endorsed by the IETF and has no formal standing in the<br>IETF standards process.

Document<br>Type

Active Internet-Draft<br>(individual)

Author

Sangam Das

Last updated

2026-08-19

RFC stream

(None)

Intended RFC status

(None)

Formats

txt

htmlized

bibtex

bibxml

Stream

Stream state

(No stream defined)

Consensus boilerplate

Unknown

RFC Editor Note

(None)

IESG

IESG state

I-D Exists

Telechat date

(None)

Responsible AD

(None)

Send notices to

(None)

Email authors

IPR

References

Referenced by

Nits

Nits v3

Search email archive

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

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<br>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...

internet ietf draft execution security finality

Related Articles