tbd R. Jesske Internet-Draft M. Kreipl Obsoletes: none (if approved) Deutsche Telekom Updates: none (if approved) 2 November 2026 Intended status: Informational Expires: 6 May 2027 AI enablement interface for multimedia services platforms draft-jesske-ai-enablement-interface-01.txt Abstract This document complements emerging AI agent communication protocols by defining a generic enablement interface between multimedia communication platforms and AI applications, agents, LLM, or other AI-based services. It describes how communication capabilities, including voice, video, messaging, media streams, and media processing, can be exposed to AI entities without defining a new agent-to-agent communication protocol. The interface is particularly applicable where an AI service is not itself a communication endpoint, but is invoked by a communication platform to process or enhance an existing communication service. Examples include live translation, call summarization, contextual assistance, fraud detection, and media enhancement. The interface is platform-agnostic and extensible. SIP-based networks and the 3GPP IP Multimedia Subsystem (IMS) are examples of communication platforms to which this approach can be applied. 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). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. 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." This Internet-Draft will expire on 6 May 2027. Jesske & Kreipl Expires 6 May 2027 [Page 1] Internet-Draft AI enablement interface for multimedia s November 2026 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 Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Scope and Non-Goals . . . . . . . . . . . . . . . . . . . . . 5 3.1. Relationship to AI Agent Protocols . . . . . . . . . . . 5 3.2. Relationship to Communication Protocols . . . . . . . . . 5 4. Architecture . . . . . . . . . . . . . . . . . . . . . . . . 6 4.1. Communication Platform . . . . . . . . . . . . . . . . . 7 4.2. AI Service / AI Agent . . . . . . . . . . . . . . . . . . 7 4.3. AI Enablement Interface . . . . . . . . . . . . . . . . . 7 4.4. Control Plane . . . . . . . . . . . . . . . . . . . . . . 8 4.5. Media Plane . . . . . . . . . . . . . . . . . . . . . . . 8 5. Communication Session Binding . . . . . . . . . . . . . . . . 9 5.1. Session Identification . . . . . . . . . . . . . . . . . 9 5.2. Participant Identification . . . . . . . . . . . . . . . 9 5.3. Media Stream Identification . . . . . . . . . . . . . . . 10 5.4. Request and Result Correlation . . . . . . . . . . . . . 10 6. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 10 6.1. Introduction . . . . . . . . . . . . . . . . . . . . . . 10 6.2. Bidirectional Communication Support . . . . . . . . . . . 10 6.3. Standardized Message Formats . . . . . . . . . . . . . . 10 6.4. Multi-Modal Data Handling . . . . . . . . . . . . . . . . 11 6.5. Compatibility with Existing AI Services . . . . . . . . . 11 6.6. Authentication and Authorization . . . . . . . . . . . . 12 6.7. Interaction Models . . . . . . . . . . . . . . . . . . . 12 6.8. Error Handling and Fallback Procedures . . . . . . . . . 12 7. Authorization . . . . . . . . . . . . . . . . . . . . . . . . 12 7.1. Service Authentication and Authorization . . . . . . . . 13 7.2. Authorization of AI-Assisted Actions . . . . . . . . . . 13 7.3. Authorization Evidence . . . . . . . . . . . . . . . . . 13 8. Operational Considerations . . . . . . . . . . . . . . . . . 14 8.1. AI Service Selection . . . . . . . . . . . . . . . . . . 14 8.2. AI Service Discovery and Capability Negotiation . . . . . 14 Jesske & Kreipl Expires 6 May 2027 [Page 2] Internet-Draft AI enablement interface for multimedia s November 2026 8.3. Failure Handling . . . . . . . . . . . . . . . . . . . . 14 8.4. Session Continuity . . . . . . . . . . . . . . . . . . . 14 9. Protocol Realization Considerations . . . . . . . . . . . . . 15 10. Message Formats . . . . . . . . . . . . . . . . . . . . . . . 15 11. Communication Context . . . . . . . . . . . . . . . . . . . . 16 12. Security Considerations . . . . . . . . . . . . . . . . . . . 17 12.1. Data Confidentiality and Integrity . . . . . . . . . . . 17 12.2. Authentication . . . . . . . . . . . . . . . . . . . . . 17 12.3. Access Control . . . . . . . . . . . . . . . . . . . . . 17 12.4. Authorization of AI-Assisted Actions . . . . . . . . . . 18 12.5. Replay and Reuse of Authorization Evidence . . . . . . . 18 12.6. Separation of Communication Content and Control . . . . 18 12.7. Untrusted Communication Content . . . . . . . . . . . . 18 12.8. Cross-Session Isolation . . . . . . . . . . . . . . . . 19 12.9. AI-Generated or Modified Media . . . . . . . . . . . . . 19 12.10. Security Considerations for Failure Handling . . . . . . 19 13. Privacy Considerations . . . . . . . . . . . . . . . . . . . 20 13.1. Data Minimization . . . . . . . . . . . . . . . . . . . 20 13.2. Purpose Limitation . . . . . . . . . . . . . . . . . . . 20 13.3. Participant Authorization and Consent . . . . . . . . . 20 13.4. Data Retention and Deletion . . . . . . . . . . . . . . 21 13.5. External AI Services . . . . . . . . . . . . . . . . . . 21 14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 15. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 21 16. References . . . . . . . . . . . . . . . . . . . . . . . . . 22 16.1. Normative References . . . . . . . . . . . . . . . . . . 22 16.2. Informative References . . . . . . . . . . . . . . . . . 22 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22 1. Introduction This draft is inspired by the IP Multimedia Subsystem (IMS) which employs voice, video, messaging as well as Data Channels (DC) to enable real-time, bidirectional data communication between various entities. Different Application Servers play a central role in managing and processing these data streams and the related services. The world of Artificial Intelligence (AI), particularly Large Language Models (LLMs), offers significant opportunities to enhance communication services by enabling intelligent message processing, semantic analysis and contextual understanding. Jesske & Kreipl Expires 6 May 2027 [Page 3] Internet-Draft AI enablement interface for multimedia s November 2026 This document defines a generic, platform-agnostic interface between a genreric application layer and AI-based services, facilitating a seamless integration of AI capabilities. This may be provided for a 3GPP IMS or any other equivalent multimedia platform. Future AI services enabled through this interface are not limited to automated translation, speech transcription, and personalized concierge functionalities. By standardizing this interface, a multimedia platform as the IMS can flexibly adopt AI technologies to enrich user experience and provide advanced multimedia services. Emerging AI agent protocols provide mechanisms for communication between AI agents, tools, and other AI-aware endpoints. This document does not replace such protocols. Instead, it describes a communication service profile defining the capabilities and information required when an existing communication platform exposes communication services to an AI application or agent. Existing or emerging agent communication and transport protocols MAY be used to realize the interface where applicable. 2. Terminology Communication Platform (CP) A system establishing or controlling multimedia communication sessions. AI Service (AIS) A service performing AI-assisted processing on communication data. AI Agent An autonomous or semi-autonomous entity capable of reasoning and performing actions. AI Enablement Interface (AEI) The interface defined by this document between a Communication Platform and an AI Service or Agent. Communication Session An existing or requested voice, video, messaging, or multimedia interaction. AI-assisted Action An operation performed on or affecting a Communication Session, such as transcription, translation, media generation, summarization or modification. Authorization Evidence Evidence indicating that an entity is authorized to request a particular AI-assisted action. Communication Context Information describing the communication session relevant for AI processing. Jesske & Kreipl Expires 6 May 2027 [Page 4] Internet-Draft AI enablement interface for multimedia s November 2026 3. Scope and Non-Goals The scope of this document is the interaction between an existing multimedia Communication Platform and an AI Service or AI Agent includign services based on Large Language Models (LLMs). The document defines semantics for: * communication session identification and binding; * media and participant identification; * AI capability discovery and selection; * AI-assisted actions; * communication context; * synchronous, asynchronous, and streaming interactions; * authorization associated with AI-assisted actions; and * error and operational handling. The document does not define AI reasoning, model execution, Agent-to- Agent communication, tool invocation protocols, or new media transport mechanisms. 3.1. Relationship to AI Agent Protocols Agent-to-Agent and agent-to-tool protocols MAY be used in conjunction with the AI Enablement Interface. There are used for the direct communication between agents or angent and tool. The AI Enablement Interface addresses a different relationship: the interaction between a Communication Platform and an AI Service or AI Agent in the context of a multimedia communication service. 3.2. Relationship to Communication Protocols The AI Enablement Interface is independent of the underlying communication technology. SIP/IMS, WebRTC, and other multimedia communication architectures are possible examples. The use of a particular communication architecture does not define the AI Enablement Interface itself. Such architectures represent possible deployments in which the interface described by this document can be applied. Jesske & Kreipl Expires 6 May 2027 [Page 5] Internet-Draft AI enablement interface for multimedia s November 2026 4. Architecture This section describes the logical architecture of the AI Enablement Interface (AEI). The AEI enables a Communication Platform to expose communication capabilities, communication context, and media to an AI Service or AI Agent, and provides semantics for requesting and performing authorized AI-assisted actions associated with a Communication Session. The architecture separates control information from media exchanged for AI-assisted processing. This separation allows implementations to select appropriate protocols and transports according to the characteristics of the information being exchanged. The architecture is independent of the underlying communication technology. SIP/IMS, WebRTC, and other multimedia communication technologies are examples of environments in which the architecture can be applied. +--------------------------+ | AI Service / AI Agent | +------------+-------------+ | AI Enablement Interface | +-----------+-----------+ | | Control Plane Media Plane | | +-----------+-----------+ | +------------+-------------+ | Communication Platform | +------------+-------------+ | Session / Participant / Media Binding | +------------+-------------+ | Communication Session | | | | Participant A B | | Audio / Video / Data | +---------------------------+ Figure 1: AI Enablement Interface Architecture Jesske & Kreipl Expires 6 May 2027 [Page 6] Internet-Draft AI enablement interface for multimedia s November 2026 4.1. Communication Platform The Communication Platform (CP) provides or controls multimedia communication services and maintains the relationship between communication sessions, participants, media streams, and communication capabilities. The Communication Platform acts as the communication-side endpoint of the AI Enablement Interface. It determines which communication resources and capabilities are exposed to an AI Service or AI Agent according to applicable authorization and policy. A Communication Platform can be based on SIP/IMS, WebRTC, or other multimedia communication technologies. The internal architecture and protocols of the Communication Platform are outside the scope of this document. 4.2. AI Service / AI Agent An AI Service or AI Agent provides AI-assisted processing associated with a communication service. Such processing can include transcription, translation, summarization, contextual analysis, media generation, media modification, or other AI-assisted functions. The AI entity can be a specialized AI service, a Large Language Model (LLM)-based service, an AI Agent, or another system capable of performing AI-assisted processing. This document does not define the internal architecture, reasoning mechanisms, model implementation, or Agent-to-Agent communication of the AI entity. 4.3. AI Enablement Interface The AI Enablement Interface (AEI) is the logical interface between a Communication Platform and an AI Service or AI Agent. The AEI enables information and capabilities associated with a Communication Session to be exposed for AI-assisted processing and enables results or permitted AI-assisted actions to be returned to the Communication Platform. Jesske & Kreipl Expires 6 May 2027 [Page 7] Internet-Draft AI enablement interface for multimedia s November 2026 The AEI provides semantics for identifying communication sessions, participants, and media streams; describing AI capabilities and requested actions; conveying communication context; associating authorization information with AI-assisted actions; and reporting processing results and status. The AEI is a logical interface. This document does not require all information exchanged across the AEI to use a single protocol or transport. 4.4. Control Plane For the purpose of this document, the AEI Control Plane refers to information used to request, coordinate, authorize, and manage AI- assisted processing. It does not refer to the control plane of the underlying communication network. Control information can include: * AI-assisted action requests; * communication session and participant references; * media stream references; * communication context; * capability discovery and negotiation; * authorization information or authorization evidence; * processing requirements; * status information; and * errors and notifications. The Control Plane does not itself define how multimedia content is transported. 4.5. Media Plane The AEI Media Plane represents media or other communication data made available to, or generated by, an AI Service as part of an AI- assisted operation. Such data can include audio, video, text, images, messaging content, or other application data. Jesske & Kreipl Expires 6 May 2027 [Page 8] Internet-Draft AI enablement interface for multimedia s November 2026 Media can be transferred directly across a transport associated with the AEI or can be referenced through control information and transferred using an existing media transport mechanism. This document does not define a new media transport protocol. This document does not require control information and media to use the same protocol, transport connection, or network path. 5. Communication Session Binding AI-assisted processing is performed in the context of a Communication Session. The AI Enablement Interface therefore needs to provide sufficient information to associate an AI-assisted request with the communication session, participant, and media resources to which the request applies. The identifiers used by the AI Enablement Interface are logical identifiers. This document does not require them to correspond directly to identifiers used by the underlying communication protocol. 5.1. Session Identification A request associated with an existing Communication Session should contain or reference a session identifier that allows the Communication Platform to correlate the AI-assisted processing with the corresponding Communication Session. The session identifier is independent of the protocol-specific identifiers used by the underlying communication system. Implementations may map such identifiers to SIP, IMS, WebRTC, or other communication-specific session identifiers. 5.2. Participant Identification Where AI-assisted processing applies to a specific participant, the request should provide a participant identifier or another reference that allows the Communication Platform to determine the affected participant. Participant information exposed to an AI Service should be limited to the information required for the requested processing. Jesske & Kreipl Expires 6 May 2027 [Page 9] Internet-Draft AI enablement interface for multimedia s November 2026 5.3. Media Stream Identification Where an AI-assisted operation applies to a specific media stream, the request should identify or reference that media stream. Examples include audio, video, text, image, messaging, or data streams. Media stream identification allows AI-assisted processing to be applied selectively without requiring access to all media associated with a Communication Session. 5.4. Request and Result Correlation Each request should contain a unique request identifier that allows requests, intermediate results, final results, errors, and notifications to be correlated. For asynchronous or streaming processing, the same correlation information can be used to associate partial or delayed results with the original request. 6. Requirements 6.1. Introduction This section outlines the necessary capabilities and design principles for the interface between the Communication Platform and an AI Service or AI Agent, including LLM-based services. The interface must be flexible enough to allow connecting existing and future AI services and AI Agents. It also needs to support various payload types of data, including text, audio, image, and video streams. 6.2. Bidirectional Communication Support The interface shall support bidirectional data exchange between the Communication Platform and an AI Service. This enables real-time interaction required for conversational AI, continuous context synchronization, and feedback mechanisms. Suitable transport protocols can include WebSocket for low-latency, full-duplex communication, or HTTP-based APIs for request-response workflows. 6.3. Standardized Message Formats Messages exchanged should apply commonly accepted formats such as JSON [RFC8259]. Jesske & Kreipl Expires 6 May 2027 [Page 10] Internet-Draft AI enablement interface for multimedia s November 2026 The message structure must distinguish clearly between text, audio, image, and video data payloads, including metadata such as encoding, language, and context information. To support future AI service features and media types, the format should be extensible. 6.4. Multi-Modal Data Handling The interface must enable the transfer or referencing of multiple media types relevant to AI processing. Text: Raw or structured text for natural language understanding and generation. Audio: Audio streams or voice data requiring transcription, recognition, speaker identification, translation, or other processing. Image: Images in different formats requiring analysis, recognition, pattern analysis, or translation to descriptive output. Video: Multimedia streams potentially requiring analysis for context, recognition, or other AI-assisted processing. Support for efficient streaming protocols or wrappers to encapsulate real-time media streams is needed, aligned with the transport protocols used by the AI Service. For communication systems such as 3GPP IMS, using codecs that are already used by the communication domain can reduce transcoding and the related delay for real-time applications. 6.5. Compatibility with Existing AI Services The interface should be agnostic and flexible enough to integrate with different AI Services and AI Agents, including cloud-hosted and on-premises AI deployments. The interface should not depend on a specific AI provider, model architecture, or model implementation. Common authentication and authorization mechanisms can be used where applicable. Jesske & Kreipl Expires 6 May 2027 [Page 11] Internet-Draft AI enablement interface for multimedia s November 2026 6.6. Authentication and Authorization The AI Enablement Interface must support authentication and authorization between the Communication Platform and AI Services. Authorization to access the AI Enablement Interface does not imply authorization to perform a specific AI-assisted action. The authorization model for AI-assisted actions is described in Section 7. 6.7. Interaction Models The interface should support synchronous, asynchronous, and streaming interaction modes. Synchronous interaction can be used for real-time communication and session-related processing where immediate AI responses are required. Asynchronous interaction can be used for AI tasks such as bulk transcription, translation, summarization, or offline content analysis which can be longer running. The ability to notify the Communication Platform of task completion, intermediate results, or partial results is required where applicable. For long-running, asynchronous, or streaming operations, the Communication Platform should be able to request cancellation of ongoing AI-assisted processing where supported by the AI Service. 6.8. Error Handling and Fallback Procedures The interface must provide a standardized way to report errors, timeouts, and exceptional conditions. The Communication Platform should provide fallback and retry mechanisms where applicable. This assumes that fallback triggers and thresholds can be recognized and that alternative processing paths or retries can be selected. Robustness against transient network or service failures must be considered. 7. Authorization Jesske & Kreipl Expires 6 May 2027 [Page 12] Internet-Draft AI enablement interface for multimedia s November 2026 7.1. Service Authentication and Authorization Authentication and authorization are required to determine whether an AI Service is permitted to access the AI Enablement Interface and the capabilities exposed through it. Authorization to access the interface does not by itself establish authorization to perform a particular AI-assisted action affecting a user, participant, media stream, or Communication Session. 7.2. Authorization of AI-Assisted Actions AI-assisted operations such as recording, transcription, translation, summarization, contextual processing, or media analysis can require additional authorization depending on the service and deployment. Authorization for such an operation can be associated with the specific requested action and the communication resources affected by that action. 7.3. Authorization Evidence An AI Enablement Interface request MAY carry authorization evidence associated with the requested operation. Such evidence can be used to demonstrate that an affected user, application, or other authorized entity has authorized the requested AI-assisted processing. Authorization evidence SHOULD be bound to the specific requested action rather than only to the overall Communication Session. Depending on the operation and applicable authorization model, this may include constraints related to participants, purpose, destination, media, or time interval. The AI Enablement Interface treats authorization evidence as opaque data. This document does not define the format, generation, verification, trust model, or legal interpretation of such evidence. These aspects are determined by the authorization system and the relying party's applicable trust and authorization policy. Implementations SHOULD consider protection against replay or reuse of authorization evidence where such reuse could result in an unauthorized operation. Jesske & Kreipl Expires 6 May 2027 [Page 13] Internet-Draft AI enablement interface for multimedia s November 2026 8. Operational Considerations Deployments of the AI Enablement Interface need to consider the availability, capabilities, performance, and continuity of AI Services, in particular for real-time communication services. 8.1. AI Service Selection A Communication Platform can have access to multiple AI Services. Service selection can consider the requested AI functionality, supported media types, language, processing mode, authorization policy, availability, and performance requirements. 8.2. AI Service Discovery and Capability Negotiation The Communication Platform may need to discover AI Services available for a requested AI-assisted operation. Discovery can consider the type of processing, supported media, deployment environment, and applicable policy. The Communication Platform should be able to determine whether an AI Service supports the capabilities required for the requested processing. Such capabilities can include supported media types, codecs, languages, processing functions, and synchronous, asynchronous, or streaming interaction modes. 8.3. Failure Handling If an AI Service becomes unavailable or cannot complete a requested operation, the Communication Platform can retry the request, select an alternative AI Service, or continue the Communication Session without the AI-assisted functionality. Failure of an AI-assisted function should not unnecessarily terminate the underlying Communication Session. 8.4. Session Continuity For long-running or real-time AI-assisted processing, implementations should maintain the relationship between the AI processing context and the associated Communication Session when connections are re- established or processing is moved to another AI Service. Jesske & Kreipl Expires 6 May 2027 [Page 14] Internet-Draft AI enablement interface for multimedia s November 2026 9. Protocol Realization Considerations The AI Enablement Interface is a logical interface and does not mandate a single transport protocol. Different protocol realizations can be used depending on the interaction model, media characteristics, and deployment environment. WebSocket [RFC6455] can be used for low-latency, full-duplex, bidirectional communication, including conversational AI and streaming interactions. HTTP-based APIs can be used for request-response, management, batch, or asynchronous interactions. HTTP/2 [RFC9113] is one possible realization. Different protocol realizations can be used independently or in combination according to the requirements of the AI-assisted operation. 10. Message Formats Encoding Messages exchanged between the Communication Platform and AI Services shall be encoded in JSON [RFC8259] due to its ubiquity and ease of integration. For performance-sensitive applications, Protocol Buffers may also be supported to reduce payload size and parsing overhead. The interface shall clearly specify the content type of each message (e.g., "application/json" or "application/protobuf") in message headers or associated metadata. Request Message Structure (Communication Platform to AI Service) Each request message must include: A request should contain or reference the identifiers required to associate the requested processing with the applicable Communication Session, participants, and media resources as described in Section 5. A unique request identifier for correlation. User and session metadata such as user ID, session ID, language, and service context. Jesske & Kreipl Expires 6 May 2027 [Page 15] Internet-Draft AI enablement interface for multimedia s November 2026 Payloadtype containing the input data, text, audio data (as encoded audio or stream references), images (in diffrent formats) or video data with a clear specification of format and encoding. the payload itself is provided by an sparated stram itself where the reference to it is within the request. Optional contextual parameters such as task type (e.g., transcription, translation), priority, or custom AI service options. The request should identify the AI-assisted action to be performed, such as transcription, translation, summarization, media analysis, media generation, or another capability supported by the AI Service. Authorization evidence may be included where applicable as described in Section 7.3. Response Message Structure (AI Service to Communication Platform) Response messages must return: The original request identifier for matching responses to requests. Status fields indicating success, partial success, or errors. The processed output data which can include generated text, classification labels, transcribed speech, semantic analysis results, or multimedia annotations. Confidence scores or quality metrics, where applicable. For asynchronous operations, the response may include job IDs and estimated completion times. Extensibility Both request and response formats must allow for future extensions, such as new data types, enhanced metadata, or experimental AI features, by permitting custom fields or versioning. 11. Communication Context A request can include or reference communication context required for the requested AI-assisted processing. Such context can include language, service information, communication state, participant context, or media-related information. Communication context should be limited to the information required for the requested AI-assisted operation as described in Section 13. Jesske & Kreipl Expires 6 May 2027 [Page 16] Internet-Draft AI enablement interface for multimedia s November 2026 12. Security Considerations AI-assisted communication services can perform actions affecting the privacy or communication of users, including recording, transcription, translation, summarization, contextual processing, media generation, media modification, or media analysis. Authentication of the AI Service alone does not establish that such processing has been authorized by the affected party. 12.1. Data Confidentiality and Integrity Communication between the Communication Platform and AI Services must provide confidentiality and integrity protection. Transport Layer Security (TLS) should be used where applicable to protect communication against eavesdropping, tampering, and man-in-the-middle attacks. TLS 1.3 [RFC8446] should be used. Integrity checks via message authentication codes (MAC) or similar mechanisms may be used as supplementary safeguards, especially for streaming data where applicable. 12.2. Authentication Access to the AI Enablement Interface shall be restricted to authenticated and authorized entities. Token-based mechanisms such as OAuth 2.0 [RFC6749] may be used for authorization and delegated access. Tokens may be carried using mechanisms appropriate for the protocol realization of the AI Enablement Interface. Where token-based mechanisms are used, token lifecycle management, renewal, revocation, and appropriate scope control should be considered. 12.3. Access Control The Communication Platform and AI Services must implement access controls ensuring that only authorized requests are processed. Authorization policies should limit access according to the capabilities, communication resources, and operations required by the AI Service. Role-based or attribute-based access control policies may be used to restrict access to sensitive information or specific operation types. Jesske & Kreipl Expires 6 May 2027 [Page 17] Internet-Draft AI enablement interface for multimedia s November 2026 12.4. Authorization of AI-Assisted Actions Failure to distinguish authorization of an AI Service from authorization of a specific AI-assisted action can result in unauthorized access to communication content or unauthorized modification of a Communication Session. Implementations MUST enforce the authorization applicable to the requested AI-assisted action and the affected communication resources. The authorization model and authorization evidence are described in Section 7. 12.5. Replay and Reuse of Authorization Evidence Implementations SHOULD protect authorization evidence against replay or reuse where such reuse could result in an unauthorized operation. Where required by the authorization mechanism, authorization evidence should be bound to information that limits its use to the intended operation, Communication Session, communication resource, or validity period. The mechanisms used to provide replay protection depend on the authorization system and are outside the scope of this document. 12.6. Separation of Communication Content and Control Communication content received from participants or external sources must not implicitly constitute authorization for communication- control operations or other privileged AI-assisted actions. Implementations should distinguish information representing communication content from information representing authorized control instructions. For example, spoken or written communication content containing an instruction to an AI Service does not by itself establish that the sender is authorized to request the corresponding operation through the AI Enablement Interface. 12.7. Untrusted Communication Content Media and communication content processed by an AI Service can contain instructions or information intended to influence the behavior of the AI system. Implementations should therefore treat communication content as potentially untrusted input. Jesske & Kreipl Expires 6 May 2027 [Page 18] Internet-Draft AI enablement interface for multimedia s November 2026 Communication content must not be allowed to bypass authentication, authorization, access-control, or policy mechanisms associated with the AI Enablement Interface. This consideration is particularly relevant where an AI Service interprets natural-language communication content and is also capable of initiating actions affecting the Communication Session. 12.8. Cross-Session Isolation Context, media, results, credentials, and authorization information associated with one Communication Session must not be unintentionally exposed to another Communication Session. Implementations should maintain appropriate isolation between Communication Sessions and between AI-assisted processing contexts associated with different users or participants. Correlation identifiers, session identifiers, participant identifiers, and media stream identifiers should be validated before they are used to associate AI processing with communication resources. 12.9. AI-Generated or Modified Media An AI Service can generate or modify media that is subsequently introduced into a Communication Session. Examples include generated speech, translated speech, generated text, or modified audio or video. The ability of an AI Service to receive or analyze media does not by itself authorize the AI Service to generate, modify, or inject media into the Communication Session. The Communication Platform should ensure that AI-generated or modified media is introduced into a Communication Session only when the corresponding operation is permitted by the applicable authorization and policy. 12.10. Security Considerations for Failure Handling Failure, timeout, or unavailability of an AI Service must not result in unintended authorization of another AI Service or in exposure of communication information to an unauthorized processing entity. Jesske & Kreipl Expires 6 May 2027 [Page 19] Internet-Draft AI enablement interface for multimedia s November 2026 Where a request is redirected or retried using another AI Service, the Communication Platform should ensure that the alternative service is authorized to perform the requested processing and that any authorization constraints applicable to the original request remain applicable. 13. Privacy Considerations The AI Enablement Interface can expose communication content, participant information, session information, media, and communication context to AI Services. Such information can contain sensitive or personally identifiable information. Implementations should therefore limit the information exposed to that required for the requested AI-assisted operation. 13.1. Data Minimization The Communication Platform should expose only the communication information, media, and context necessary for the requested AI- assisted operation. Where possible, access to media and context should be limited to the specific Communication Session, participant, and media stream required for the requested processing. Information that is not required for the requested operation should not be exposed merely because it is available to the Communication Platform. 13.2. Purpose Limitation Communication information exposed for one AI-assisted operation should not automatically be considered available for other processing purposes. Where applicable, the purpose associated with an AI-assisted operation can be included in, or associated with, the authorization information or authorization evidence. 13.3. Participant Authorization and Consent AI-assisted processing of communication content can require authorization or consent from one or more affected participants, depending on the type of processing, service, deployment, and applicable requirements. Jesske & Kreipl Expires 6 May 2027 [Page 20] Internet-Draft AI enablement interface for multimedia s November 2026 The fact that a participant takes part in a Communication Session does not by itself imply authorization for AI-assisted processing of that participant's communication content. Where authorization evidence is used to represent such authorization, it can be associated with the requested operation as described in Section 7.3. This document does not define how user consent is obtained, the legal requirements for obtaining consent, or the legal interpretation of authorization evidence. 13.4. Data Retention and Deletion Implementations should consider the retention period of communication content, media, context, and results generated by AI-assisted processing. Communication information should not be retained longer than required for the intended processing purpose and applicable operational or regulatory requirements. Where applicable, implementations should provide mechanisms for deletion of communication information and AI-generated processing results when they are no longer required. 13.5. External AI Services An AI Service can be operated in a different administrative or trust domain from the Communication Platform. Exposing communication information to such a service can therefore extend the set of entities that process communication information. Before exposing communication information to an AI Service, the Communication Platform should consider whether the AI Service is authorized to receive the requested information and whether the information provided is limited to that required for the requested operation. 14. IANA Considerations No IANA Considerations. 15. Acknowledgments The author would like to acknowledge the constructive feedback provided by Michael Kreipl, Iman Schrock, Thomas Spall, Elvira Pressler, Ursua Harrison and the IETF comunity. Jesske & Kreipl Expires 6 May 2027 [Page 21] Internet-Draft AI enablement interface for multimedia s November 2026 16. References 16.1. Normative References [RFC6455] Fette, I. and A. Melnikov, "The WebSocket Protocol", RFC 6455, DOI 10.17487/RFC6455, December 2011, . [RFC6749] Hardt, D., Ed., "The OAuth 2.0 Authorization Framework", RFC 6749, DOI 10.17487/RFC6749, October 2012, . [RFC8259] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data Interchange Format", STD 90, RFC 8259, DOI 10.17487/RFC8259, December 2017, . [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, . [RFC9113] Thomson, M., Ed. and C. Benfield, Ed., "HTTP/2", RFC 9113, DOI 10.17487/RFC9113, June 2022, . 16.2. Informative References Authors' Addresses Roland Jesske Deutsche Telekom Telekom Allee 9 64295 Darmstadt Germany Email: r.jesske@telekom.de URI: www.telekom.com Michael Kreipl Deutsche Telekom Dieselstrasse 43 90441 Nuernberg Germany Email: michael.kreipl@telekom.de URI: www.telekom.com Jesske & Kreipl Expires 6 May 2027 [Page 22]