7.2 Security architecture

7.2.1 Security architecture overview

The security architecture for MCP-oneM2M interworking is designed around a proxy-mediated framework to ensure that AI agents can access oneM2M resources in a controlled way, while the AI system has no direct awareness of oneM2M.

Figure 7.2.1-1 provides a high-level overview of the security architecture assumed in this profile.

Figure 7.2.1-1: High-level overview of the MCP interworking security architecture

The architecture consists of the following components:

• MCP Host: An AI application that interacts with users and may host an AI agent. It configures MCP Clients, which obtain a PAT from the PAT Issuer (OAuth Authorization Server) and call the MCP-IPE using the PAT.
• PAT Issuer (OAuth Authorization Server): An OAuth 2.1 Authorization Server that issues PATs for MCP Client authorization and authentication toward the MCP-IPE. In the deployment considered in this report, a oneM2M DAS Server is co-located in the same AS domain, while remaining a separate oneM2M-side authorization function.
• MCP Interworking Proxy Entity (MCP-IPE): An MCP server and oneM2M-facing interworking entity that mediates access to the oneM2M CSE. It validates MCP Client requests, performs MCP-side protection, manages dedicated supporting AE lifecycle functions, and issues oneM2M requests toward the CSE.
• oneM2M CSE: A service layer entity that hosts oneM2M CSFs and makes the final authorization and execution decision for oneM2M operations.

In addition to the components shown in Figure 7.2.1-1, the MCP-IPE may rely on oneM2M-side credential material, related identity information, and association state that are protected within a deployment-specific secure environment and secure storage function corresponding to TS-0003 Secure Storage. That protected material may be used to establish and operate the MCP-IPE's oneM2M-side presence, to create or allocate dedicated supporting AEs, and to maintain the association between each MCP Client identity and the dedicated supporting AE associated with that client. In this profile, the token-bound AE identifier refers to the AE-ID of the dedicated supporting AE associated with the MCP Client, not the IPE AE. Figure 7.2.1-1 abstracts deployment details, but the profile assumes a one-to-one association between the MCP Client identity and the dedicated supporting AE associated with that client for mediated oneM2M requests.

Detailed explanations are provided in the following subclauses.

7.2.2 MCP Host and AI Agent

The MCP Host is the AI application that interacts with the user and may host an AI agent. It uses xLMs running locally or accessed via external APIs to interpret user input, generate appropriate MCP calls, and relay the results back to the user. The MCP Host configures one or more MCP Clients, each bound to a particular MCP server (e.g., the MCP-IPE). The MCP Host itself is not aware of oneM2M; all interactions with the oneM2M CSE occur indirectly through the MCP-IPE.

The MCP Client acts as an OAuth 2.1 client created by the MCP Host. Each client maintains an isolated connection to the MCP server (e.g., MCP-IPE) and issues MCP requests. These requests may invoke MCP tools, resources, and prompts exposed by the MCP-IPE, and may result in the MCP-IPE either executing MCP-server functions or issuing corresponding oneM2M operations (e.g., create, retrieve, update, or delete) on target resources. It obtains a PAT from the PAT Issuer and includes it in requests to the MCP-IPE.

The implementation details of the MCP Host and MCP Client are beyond the scope of this report.

7.2.3 PAT Issuer (OAuth Authorization Server)

The PAT Issuer (OAuth Authorization Server) is an OAuth 2.1 Authorization Server that issues short-lived PATs to MCP Clients. The PAT Issuer does not communicate with the oneM2M CSE. In the deployment considered in this report, the PAT Issuer and oneM2M DAS Server are co-located within the same AS domain while remaining logically separate functions. If a oneM2M DAS Server is present, it remains part of oneM2M-side authorization and is consulted by the CSE rather than by the PAT Issuer. The PAT Issuer obtains the actual AE-ID of the already established or newly assigned dedicated supporting AE associated with the MCP Client from the MCP-IPE or from an MCP-IPE-controlled assignment / acquisition function and inserts that value into onem2m_aeid without itself performing final oneM2M authorization.

It performs the following functions:

• PAT Issuer metadata publication: PAT Issuer publishes the OAuth Authorization Server Metadata [i.8] required by the MCP Client to know the endpoints it needs to complete the authorization flow.
• Client Registration: PAT Issuer supports OAuth Client ID Metadata Document [i.9], an option for static client credentials, or OAuth Dynamic Client Registration [i.10] so that the MCP Client can establish its client identity and metadata.
• Dedicated supporting AE assignment coordination: After the MCP Client identity is established and before PAT issuance, the PAT Issuer obtains the actual AE-ID to be inserted into onem2m_aeid from the MCP-IPE or from an MCP-IPE-controlled assignment / acquisition function.
• Client Authorization and PAT Issuance: PAT Issuer provides the authorization endpoint where the client can obtain the PAT that explicitly specifies the audience as MCP-IPE and carries onem2m_aeid as the single oneM2M-specific claim.
• Token lifecycle management: PAT Issuer issues PATs as short-lived tokens and manages the lifecycle of PATs within the OAuth infrastructure, including issuance, reissuance, and optionally revocation [i.11].
• JSON Web Key Sets (JWKS) publication: PAT Issuer publishes a JWKS [i.12] endpoint and the public key material required by the MCP-IPE to verify PAT signatures, enabling verification of token integrity and issuer authenticity.
• Administrative separation from DAS: In the deployment considered in this report, a oneM2M DAS Server is co-located in the same AS domain, but it remains outside PAT issuance and is used only for later CSE-side authorization processing.

For secure interworking, the PAT Issuer has the following relevant properties:

• Non-interference in AE assignment: The MCP Client does not influence the determination of the dedicated supporting AE associated with a PAT. The relevant AE assignment is determined within the oneM2M environment and consumed by the PAT Issuer according to deployment policy.
• Actual AE-ID consumption for PAT issuance: The PAT Issuer obtains the actual AE-ID from the MCP-IPE or from an MCP-IPE-controlled assignment / acquisition function and consumes that value for PAT issuance; it does not obtain the value directly from the CSE.
• Client and authorization data management: The PAT Issuer maintains client registration data (e.g., client identifiers and metadata) and authorization data required to issue and manage PATs, including token status.
• Change notification to the MCP-IPE: When token lifecycle records change (e.g., key rotation signals, token revocation signals, or other events that affect token acceptance), the PAT Issuer may notify the MCP-IPE so that cached token-validation context can be refreshed or invalidated according to local cache policy.

The implementation details of the PAT Issuer are beyond the scope of this report.

7.2.4 MCP Interworking Proxy Entity (MCP-IPE)

The MCP-IPE is the intermediary component at the MCP-oneM2M boundary that implements the MCP server role toward the MCP Client and a oneM2M-facing interworking function toward the oneM2M CSE. It mediates MCP requests, validates and terminates PATs at the proxy, manages dedicated supporting AE lifecycle functions, and issues ordinary oneM2M request primitives toward the CSE.

It performs the following functions:

• MCP server interface: The MCP-IPE exposes MCP tools, resources, and prompts, receives MCP requests from MCP Clients, and returns MCP responses.
• OAuth protected resource role: The MCP-IPE acts as an OAuth 2.1 protected resource endpoint that accepts requests protected by PATs and publishes OAuth Protected Resource Metadata [i.13] so that MCP Clients can discover the PAT Issuer and request appropriate scopes for accessing capabilities exposed by the MCP-IPE.
• Token validation: The MCP-IPE verifies incoming PATs using the PAT Issuer's published JWKS and validates required token properties (e.g., issuer, audience, lifetime, and token identifier).
• Secure-storage use and oneM2M-side credential access: The MCP-IPE accesses oneM2M-side credential material, related identity information, and protected association state through a deployment-specific secure environment and secure storage function according to deployment policy.
• Supporting-AE lifecycle management: The MCP-IPE creates, allocates, registers, and maintains dedicated supporting AEs associated with MCP Clients and retains the related association state required for mediated oneM2M requests.
• On-behalf-of request forwarding: When submitting mediated oneM2M requests, the MCP-IPE sets the Originator (From, i.e., fr in the impersonation checking procedure) to the AE-ID carried in onem2m_aeid, where that value identifies the dedicated supporting AE associated with the MCP Client.
• Message translation and normalization: The MCP-IPE translates MCP requests into MCP-server actions and, where applicable, into oneM2M operations (e.g., create, retrieve, update, delete), and converts oneM2M responses back into MCP responses while filtering or normalizing non-essential fields to reduce unnecessary exposure of CSE internals.
• Audit and abuse mitigation: The MCP-IPE records security-relevant events for accountability and may support basic abuse controls such as rate limiting and replay mitigation.

For secure interworking, the MCP-IPE has the following relevant security properties:

• Credential-based CSE communication: The MCP-IPE establishes a protected channel with the CSE (e.g., TLS), with mutual authentication as required by deployment policy, using oneM2M-side credential arrangements and protected material available to the MCP-IPE.
• Supporting-AE association maintenance: The MCP-IPE maintains the association between the MCP Client identity, the PAT presented for that client, and the dedicated supporting AE associated with that client. The IPE AE may remain registered as the MCP-IPE's oneM2M-side management anchor, but it is not the default per-client mediated Originator identity in this profile.
• Strict PAT processing: The MCP-IPE strictly validates PATs before processing protected requests and rejects requests with missing, malformed, expired, or otherwise invalid tokens.
• Strict tenant isolation: In multi-tenant deployments where the MCP-IPE mediates requests for multiple MCP Clients, the MCP-IPE should enforce strict tenant isolation. The MCP-IPE should maintain an immutable binding between each MCP Client identity, the presented PAT, and the dedicated supporting AE associated with that client, and should re-validate this binding for each protected request. The MCP-IPE should also separate per-tenant state (e.g., mapping caches, authorization context, and audit correlation) so that requests and enforcement contexts cannot be mixed across tenants.
• Deny-by-default admission: The MCP-IPE applies deny-by-default admission at the MCP boundary and performs actions only when token-level eligibility (e.g., PAT validity, audience, lifetime, scope) and locally configured capability exposure controls are satisfied.
• No PAT forwarding to the CSE: The MCP-IPE terminates the PAT at the MCP boundary. Since the PAT is audience-restricted to the MCP-IPE, it is not forwarded to the oneM2M CSE.
• Auditability: The MCP-IPE generates audit records that correlate the token identifier, onem2m_aeid, requested operation, target, and enforcement decision, and protects these logs from tampering.
• Timely token acceptance updates: The MCP-IPE refreshes or invalidates cached token-validation context when notified by the PAT Issuer (e.g., key rotation or revocation signals) or when cache validity expires, so that token acceptance decisions do not rely on stale validation context.
• Fail-safe error handling: The MCP-IPE denies requests when token verification or policy evaluation cannot be completed, returns an appropriate error response, and applies operational safeguards (e.g., bounded caching, backoff) to reduce denial-of-service amplification due to transient dependency failures.

The implementation details of the MCP-IPE are beyond the scope of this report.

7.2.5 oneM2M CSE

The oneM2M CSE is the service layer entity that hosts oneM2M Common Service Functions (CSFs) and manages the oneM2M resource tree. In this architecture, the CSE receives ordinary oneM2M request primitives from the MCP-IPE over the Mca reference point and applies its native security mechanisms, including authorization decisions based on the Originator corresponding to the dedicated supporting AE associated with the MCP Client, applicable ACPs, relevant request security context (e.g., whether the Originator is considered authenticated by the Hosting CSE and the resulting rq_authn, together with access control evaluation inputs such as accessControlAuthenticationFlag where applicable), and optionally the Dynamic Authorization System (DAS). The CSE is not required to be aware of MCP or PATs, and it does not process PATs directly or retrieve material from the MCP-IPE's secure environment or secure storage function.

This report assumes that the Originator (From) carried in each mediated request corresponds to the dedicated supporting AE associated with the MCP Client and remains consistent with the applicable oneM2M-side authenticated identity / impersonation-prevention checks under deployment policy. Mechanisms for credential provisioning, secure storage, supporting-AE registration, and operation of the relevant oneM2M-side security association are deployment-specific and are outside the scope of this report.