%% You should probably cite draft-das-interoperable-consequence-authority-01 instead of this revision.
@techreport{das-interoperable-consequence-authority-00,
    number =    {draft-das-interoperable-consequence-authority-00},
    type =      {Internet-Draft},
    institution =   {Internet Engineering Task Force},
    publisher = {Internet Engineering Task Force},
    note =      {Work in Progress},
    url =       {https://datatracker.ietf.org/doc/draft-das-interoperable-consequence-authority/00/},
    author =    {Sangam Das},
    title =     {{Secure AI Execution-Finality for iOS, Android, and Cross-Platform AI Agents, Part 1: Foundational Consequential Authority and Common Workflows}},
    pagetotal = 228,
    year =      2026,
    month =     oct,
    day =       26,
    abstract =  {AI assistants and agents, including Apple Siri acting through App Intents, Google Gemini on Android, Samsung Bixby, Microsoft Copilot, and third-party AI tools, increasingly take real actions on iOS, iPadOS, macOS, Android, Windows, Linux, and cloud platforms: they send messages, export files, call remote APIs, make payments, and operate connected devices. Such an agent can pass sandboxing, authentication, app-permission, and token checks and still cause an effect the user never approved, through prompt injection, credential misuse, a wrong or redirected target, stale authority, replay, or cross-device duplication. This document is the foundational part of a twelve-part series. It defines a common architecture in which an AI tool's proposed action (a Candidate Act) remains non-effective until protected evidence shows that it matches an approved operation, and the component that actually executes it (the Finality Sink) independently reconstructs the real pending operation and fails closed on any mismatch. It specifies the shared terminology, trust model, and security invariants used by Parts 2 through 12, together with three common workflows: protected execution of a consequential action; continuation of a multi-step task only after a verified receipt for the earlier effect; and fresh, bounded re-authorization when an agent deviates from its approved scope. A threat model and a falsifiable reference test plan are included. The document maps these mechanisms onto existing IETF work as reusable building blocks: OAuth 2.0 with Rich Authorization Requests and Demonstrating Proof of Possession (DPoP); Workload Identity in Multi-System Environments (WIMSE); Remote ATtestation procedureS (RATS); CBOR Object Signing and Encryption (COSE); Authentication and Authorization for Constrained Environments (ACE); Supply Chain Integrity, Transparency, and Trust (SCITT); and HTTP conditional requests. It identifies discussion points for these groups and for Security Area dispatch, without claiming working-group adoption or IETF consensus. Industry alignment covers interoperability between the Apple and Google mobile ecosystems, voice and system assistants, enterprise agent gateways and copilots, agent tooling from providers such as OpenAI, Anthropic, Google, and Meta, hardware-backed enforcement, payments, telecommunications, and robotics. Product names are illustrative and imply no endorsement or implementation by any vendor. For the EU Artificial Intelligence Act (Regulation (EU) 2024/1689), the operation-bound evidence and fail-closed enforcement described here can help providers and deployers address risk- management, record-keeping, human-oversight, and robustness and cybersecurity requirements where those obligations apply; this is a technical mapping, not a conformity claim or legal advice.},
}