The integration of Model Context Protocol (MCP) with oneM2M in Internet of Things (IoT) systems introduces unique security challenges that necessitate dedicated solutions to ensure secure interworking. MCP, designed for contextual data exchange and model-based interactions, enables advanced querying and resource access in IoT environments. However, when MCP clients seek to interact with oneM2M resources, such as creating, retrieving, updating, or deleting data stored in Common Service Entities (CSEs), potential vulnerabilities arise, including unauthorized access, data leakage, impersonation attacks, and integrity breaches. These risks stem from differences in the protocols' native security mechanisms: oneM2M relies on Access Control Policies (ACPs) and Application Entity (AE) identifiers for fine-grained authorization, while MCP does not define equivalent built-in controls for cross-protocol operations, leading to exposure if the mediator forwards requests using a shared oneM2M originator or AE identity for multiple MCP clients.
A security solution is essential to mitigate these issues by providing robust authentication, authorization, and message translation. This approach adopts a token-based authorization and authentication framework for MCP-side access while preserving oneM2M-native authentication and authorization toward the CSE. Each AI agent (via its MCP client) obtains a Personal Access Token (PAT), which encapsulates information about who owns the token, to whom it was issued, its lifetime, the MCP-related scopes granted to the token owner, and the oneM2M AE identifier required for interworking with oneM2M. PAT is a JWT-based OAuth access token [i.2][i.3] issued by a PAT Issuer (OAuth Authorization Server), with a single oneM2M-specific AE identifier binding claim. In this profile, that token-bound AE identifier denotes the actual oneM2M AE-ID of the oneM2M-facing IPE AE used by the MCP-IPE, with a one-to-one binding between an agent context, the token-bound AE identifier, and the corresponding AE identity toward the CSE. The PAT Issuer does not create that oneM2M-side identity; rather, it issues the PAT using deployment-established binding information for the already established oneM2M-facing IPE AE.
From the perspective of oneM2M security, the MCP-IPE acts as an interworking proxy entity (described in oneM2M TS-0033 [i.4]) at the MCP-oneM2M interworking boundary. Its oneM2M-facing side is realized as a oneM2M-facing IPE AE registered at the hosting CSE. It terminates the PAT at the MCP-IPE, applies deny-by-default admission limited to token-level eligibility and locally configured capability exposure policy, and only then issues ordinary oneM2M request primitives toward the CSE without forwarding the PAT. Those oneM2M requests are authenticated using oneM2M-side credential arrangements between the oneM2M-facing IPE AE of the MCP-IPE and the CSE. In this profile, the credential material for those arrangements is protected within a deployment-specific secure environment and secure storage function corresponding to the TS-0003 secure storage concept; that protected material is accessed only for authorized MCP-IPE operations and is not retrieved directly by the PAT Issuer or the CSE. TS-0003 already provides the secure storage, bootstrap credential configuration, remote provisioning, and association configuration concepts used for this oneM2M-facing side. In this profile, the token-bound AE identifier equals the AE-ID of that oneM2M-facing IPE AE used for the mediated request, so that the From value remains consistent with the authenticated identity checked by oneM2M impersonation-prevention procedures and the CSE continues to make its final authorization decision using its native security mechanisms as specified in oneM2M TS-0003 [i.5].
This report does not define a new authorization framework. Instead, it profiles the OAuth 2.1 Authorization Framework [i.6] already used in MCP deployments [i.7] for secure oneM2M interworking. It preserves interoperability with MCP implementations that support OAuth, while adding oneM2M-specific bindings for authentication and message translation.
The high-level 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. Key components include:
The solution described in this clause assumes a deployment in which the MCP-IPE operates as a remote MCP server and is reached by MCP clients over the HTTP transport. Single-user or purely local deployments (e.g. using the STDIO transport) can rely on simpler arrangements that are outside the scope of this security profile.
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
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.
7.3 Security procedure for MCP Interworking
7.3.1 Security procedure overview
This clause describes the security procedure for end-to-end authorization and protected operations in an MCP-oneM2M interworking deployment, where access to the oneM2M CSE is mediated by the MCP-IPE on behalf of the MCP Client. The procedure preserves oneM2M's native, resource-centric authorization model based on the Originator (AE identifier) and Access Control Policies (ACPs), while enabling MCP-side authentication and request mediation using short-lived Personal Access Tokens (PATs).
In this procedure, two distinct authentication paths are used. First, the MCP Client presents a PAT only to the MCP-IPE as the intended protected resource. Second, the MCP-IPE uses oneM2M-side credential material, prepared and stored according to deployment policy, together with the dedicated supporting AE identified by onem2m_aeid for the associated MCP Client when constructing mediated oneM2M requests. When forwarding mediated oneM2M requests, the MCP-IPE uses the dedicated supporting AE identified by onem2m_aeid as the Originator identity for the associated MCP Client. The PAT is terminated at the MCP-IPE and is not forwarded to the oneM2M CSE. The MCP-IPE validates and terminates PATs at the MCP boundary, applies token-based checks and local capability exposure policy, and then issues ordinary oneM2M request primitives toward the CSE. The CSE processes only oneM2M operations, and the CSE remains the final authorization decision point using its native mechanisms.
For clarity, this clause assumes that MCP is deployed as a remote MCP server reachable over the HTTP transport. Other transports (e.g., STDIO) and purely local or single-user deployments are outside the scope of this clause.
Communication between the MCP Client and the MCP-IPE, and between the MCP-IPE and the CSE, is assumed to be protected by a secure transport (e.g., TLS) according to deployment policy.
The procedure is organized into four phases:
Authorization and token issuance. The MCP Client discovers and interacts with the PAT Issuer designated for the MCP-IPE, establishes its client_id, completes dedicated supporting AE assignment / registration and actual AE-ID acquisition before PAT issuance, and obtains a short-lived PAT addressed to the MCP-IPE.
Protected operation. The MCP Client presents the PAT when invoking protected capabilities exposed by the MCP-IPE. The MCP-IPE validates the PAT, verifies the MCP-side client binding, applies token-level deny-by-default admission controls and locally configured capability exposure policy, and translates the request into corresponding oneM2M operations where applicable. When forwarding oneM2M requests, the MCP-IPE uses the dedicated supporting AE associated with the MCP Client as the Originator identity. The CSE enforces the final authorization decision using its native access decision procedures and returns results, which the MCP-IPE relays back to the MCP Client after any necessary response filtering or normalization.
Token reissuance. When a PAT expires, is revoked, or when the effective privileges or keys change, the MCP Client obtains a new PAT from the PAT Issuer. The PAT Issuer updates any related state as needed (e.g., token lifecycle status), onem2m_aeid remains aligned with the dedicated supporting AE associated with the MCP Client, and the MCP-IPE refreshes or invalidates cached token-validation context according to cache policy or notifications.
AE de-registration and cleanup. When an MCP Client is decommissioned or no longer needed, PAT use is revoked or invalidated, and the lifecycle of the dedicated supporting AE associated with that MCP Client and related state is cleaned up according to deployment policy.
Purpose: Ensure that oneM2M-side secure-storage, credential, and management capability are established so that the MCP-IPE can create, allocate, register, and operate dedicated supporting AEs before protected oneM2M mediation begins.
This prerequisite establishes the oneM2M-side secure-storage, credential, and management capability required for the MCP-IPE to create, allocate, register, and operate dedicated supporting AEs used for mediated MCP-Client-specific requests. It applies TS-0003 secure storage, bootstrap credential configuration, remote security provisioning, and association configuration concepts to the MCP-IPE's oneM2M-facing side without constraining deployments to a single provisioning actor or framework. The per-client dedicated supporting AE assignment / registration and actual AE-ID acquisition occurs later in clause 7.3.2.
Pre-Conditions:
The deployment requires authenticated oneM2M-side communication between the MCP-IPE and the CSE.
Procedure Description:
A deployment-specific provisioning authority provisions or enrolls the oneM2M-facing MCP-IPE entity with credential material according to deployment policy, using TS-0003-compatible bootstrap credential configuration, remote security provisioning, or equivalent credential-configuration procedures as appropriate for the deployment.
The credential material may be symmetric-key-based or certificate/public-key-based according to deployment policy. In this profile, the primary case is credential material that enables the MCP-IPE to operate its oneM2M-side management anchor and to create, allocate, register, and operate dedicated supporting AEs used for mediated MCP-Client-specific requests. Other TS-0003 credential forms may also appear in deployments, but they remain outside the default identity assertion model of this profile unless explicitly profiled to support the same capability.
The provisioned credential material and related identity information are protected within a deployment-specific secure environment and secure storage function corresponding to TS-0003 Secure Storage.
Access to that protected material is controlled according to secure-storage policy and authorized use by the MCP-IPE; the PAT Issuer, DAS, and the CSE do not directly retrieve it.
Bootstrap and trust establishment are performed according to deployment policy so that the MCP-IPE can establish its oneM2M-side security association with the CSE and operate supporting-AE lifecycle functions.
Association configuration is completed according to deployment policy so that the MCP-IPE's oneM2M-side management anchor, its relevant oneM2M identity information, and the related credential material are consistently bound before protected mediation begins.
The MCP-IPE establishes and maintains the registration of its IPE AE as needed for interworking realization and supporting-AE lifecycle management before protected mediation begins.
The MCP-IPE is configured to retrieve or otherwise access the protected material through the secure environment / secure storage function for subsequent dedicated supporting AE assignment, registration, operation, and mediated oneM2M requests.
Post-Conditions:
oneM2M-side credential material required by the MCP-IPE has been provisioned or enrolled and protected for later authenticated CSE access and supporting-AE lifecycle functions.
Association configuration for the MCP-IPE's oneM2M-side management capability and related credential material has been completed according to deployment policy.
The MCP-IPE has the capability required for later dedicated supporting AE assignment / registration and actual AE-ID acquisition before PAT issuance.
7.3.1.2 (Optional) DAS authorization data availability prerequisite
Purpose: In complex mode, ensure that deployment-specific oneM2M authorization data for the dedicated supporting AE associated with the MCP Client can be made available for later consultation by the CSE.
Pre-Conditions:
The oneM2M CSE supports DAS.
The deployment includes a oneM2M DAS Server for DAS processing.
Procedure Description:
Deployment-specific oneM2M authorization data for the token-bound AE identifier (onem2m_aeid) may be maintained according to deployment policy so that the CSE can consult the oneM2M DAS Server during authorization when DAS is enabled. In this profile, that identifier denotes the dedicated supporting AE associated with the MCP Client.
Such oneM2M authorization data may associate the dedicated supporting AE associated with the MCP Client with effective authorization policy or permission representation needed for DAS processing.
The maintenance, distribution, authentication, and internal artifact formats of that authorization data are outside the scope of this report.
This prerequisite is logically separate from PAT issuance and does not require that oneM2M authorization data be created as part of the PAT issuance transaction.
Post-Conditions:
Where DAS is enabled and deployment policy requires it, oneM2M authorization data is available for subsequent CSE consultation.
7.3.2 Authorization and Token Issuance phase
In this phase, the MCP Client obtains a short-lived Personal Access Token (PAT) from the PAT Issuer for accessing the MCP-IPE, following the MCP authorization flow based on OAuth 2.1 Authorization Code with PKCE. The MCP-IPE initiates discovery using an HTTP authentication challenge and provides Protected Resource Metadata so the MCP Client can select an appropriate PAT Issuer. The oneM2M-side trust establishment prerequisite described in clause 7.3.1.1 is assumed to be satisfied according to deployment policy.
PAT is a JWT-encoded OAuth access token (JWT AT) issued by the PAT Issuer and used by the MCP Client to access the MCP-IPE as an OAuth protected resource. The PAT follows the authorization and token processing expectations defined by MCP deployments and conforms to the JWT access token profile. The PAT also carries a client identifier claim (client_id) so that the MCP-IPE can verify that a protected request is issued by the token-bound MCP Client by comparing the client_id claim in the PAT with a deployment-specific MCP-side client-binding value presented under the selected transport binding or equivalent local context. For MCP-oneM2M interworking, the PAT carries a single oneM2M-specific claim (onem2m_aeid) that identifies the AE-ID of the dedicated supporting AE associated with the MCP Client. The final authorization decision remains enforced by the oneM2M CSE via its native mechanisms. Token status and related OAuth lifecycle records are maintained within the OAuth infrastructure.
PRM and the OAuth resource parameter are used for MCP-IPE discovery and audience targeting. They are not the vehicle for per-client AE assignment or actual AE-ID acquisition. In this profile, the dedicated supporting AE assignment / registration and actual AE-ID acquisition procedure occurs after MCP Client identity establishment and before PAT issuance.
In this approach, the PAT carries the following relevant properties:
The PAT is a signed JWT access token issued by the PAT Issuer. The MCP-IPE validates its signature and required token properties (e.g., by using the PAT Issuer's JWKS).
The PAT is audience-restricted to the MCP-IPE (i.e., aud identifies the MCP-IPE) and includes an issuer identifier (iss) that identifies the PAT Issuer.
The PAT is short-lived (exp) and includes an issuance time (iat). It may include additional standard claims as required by deployment policy (e.g., nbf).
The PAT includes a subject identifier (sub) that identifies the token owner or principal, and a token identifier (jti) that uniquely identifies the token instance for audit correlation and lifecycle tracking at the MCP-IPE.
The PAT includes a client identifier claim (client_id) that identifies the MCP Client instance authorized to use the PAT toward the MCP-IPE. The MCP-IPE verifies the client binding by comparing the deployment-specific MCP-side client-binding value presented under the selected transport binding or equivalent local context with the client_id claim carried in the PAT.
The PAT conveys granted OAuth scope information for MCP-IPE capabilities (e.g., via scope or an equivalent claim representation consistent with JWT AT profiling). The MCP-IPE may use this information as an input for token-level validation and local policy gating.
The PAT includes the onem2m_aeid claim as its only oneM2M-specific claim. In this profile, that value is the AE-ID of the dedicated supporting AE associated with the MCP Client.
Boundary and secrecy: the PAT is terminated at the MCP-IPE and is not forwarded to the oneM2M CSE. The PAT does not contain oneM2M credentials or secrets.
The PAT may be accompanied by a refresh token depending on deployment policy. If used, the refresh token is handled only within the PAT Issuer infrastructure and is not presented to the MCP-IPE.
Figure 7.3.2‑1 provides an overview of the Authorization and Token Issuance phase. In this phase, PRM and the OAuth resource parameter identify the MCP-IPE / PAT Issuer path, while the dedicated supporting AE assignment / registration and actual AE-ID acquisition procedure occurs before PAT issuance and provides the value inserted into onem2m_aeid.
Figure 7.3.2‑1: Overview of the Authorization and Token Issuance phase
Figure 7.3.2‑1: Overview of the Authorization and Token Issuance phase
7.3.2.1 Protected resource discovery procedure
Purpose: Enable the MCP Client to discover the Protected Resource Metadata (PRM) and obtain the information required to locate and select the PAT Issuer for the MCP-IPE.
Pre-Conditions:
The MCP Client is configured with the MCP-IPE endpoint.
Procedure Description:
The MCP Client sends an MCP request to the MCP-IPE without presenting an access token.
The MCP-IPE responds with HTTP 401 Unauthorized and includes a WWW-Authenticate header that contains a reference to the Protected Resource Metadata (e.g., a resource_metadata URL). The MCP-IPE should include a scope parameter in the WWW-Authenticate header to indicate the scope(s) required for accessing the requested capability.
NOTE 1: OAuth scopes are permission identifiers used by the MCP Client to request the minimum access needed for MCP-IPE capabilities. The MCP-IPE may advertise scopes_supported as a general catalogue of supported scopes (e.g., via Protected Resource Metadata), while the scope parameter in the WWW-Authenticate challenge indicates the scope set required to satisfy the current request.
NOTE 2: The MCP Client treats the scope(s) provided in the WWW-Authenticate challenge as authoritative for satisfying the current request and does not assume any particular set relationship between the challenged scope set and scopes_supported.
In case of missing or malformed WWW-Authenticate parameters, the MCP Client treats the MCP-IPE as not discoverable via challenge and uses a configured PRM endpoint if available, otherwise fails the authorization attempt.
The MCP Client requests the Protected Resource Metadata from the MCP-IPE using the discovered PRM endpoint.
The MCP-IPE returns the Protected Resource Metadata, including at minimum the PAT Issuer candidate(s) and the canonical resource identifier [i.14] for the MCP-IPE.
NOTE 3: PRM is used for discovery of the MCP-IPE and PAT Issuer path. It does not carry dedicated supporting AE assignment information and is not used for actual AE-ID acquisition.
In case of non-success responses when retrieving PRM (e.g., network errors or 5xx), the MCP Client retries according to local policy and does not proceed to token acquisition without valid PRM.
Post-Conditions:
The MCP Client has obtained PRM and identified PAT Issuer candidate(s) and the MCP-IPE resource identifier.
7.3.2.2 PAT Issuer discovery and client registration procedure
Purpose: Allow the MCP Client to select a PAT Issuer and establish valid OAuth client identity and metadata for the authorization flow.
Procedure Description:
The MCP Client parses the Protected Resource Metadata and determines the PAT Issuer to use according to local policy when multiple PAT Issuers are advertised.
The MCP Client retrieves PAT Issuer metadata by attempting OAuth 2.0 and OpenID Connect discovery endpoints in priority order, and caches the resulting issuer and endpoint information (e.g., authorization endpoint, token endpoint, and JWKS URI).
In case of metadata retrieval failure (e.g., unreachable discovery endpoint), the MCP Client selects another advertised PAT Issuer if available; otherwise it fails the authorization attempt.
The MCP Client establishes its client identity using one of the following methods supported by the selected PAT Issuer:
Client ID Metadata Document: The MCP Client uses an HTTPS URL as the client_id. The PAT Issuer fetches and validates the client metadata document, including validation of registered redirect URIs.
Dynamic Client Registration: The MCP Client registers at the PAT Issuer (e.g., POST /register) and obtains client credentials.
Pre-registered Client: The MCP Client uses an existing client_id provisioned out-of-band.
In case of client registration failure or invalid client metadata (e.g., redirect URI mismatch), the MCP Client does not proceed to the authorization request.
The MCP Client stores the client_id securely for subsequent use in the authorization flow and for the MCP-side client binding model applied under the selected transport binding or equivalent local context.
Post-Conditions:
The MCP Client has selected a PAT Issuer, obtained and cached its metadata, and has a valid client identity (client_id) for the authorization flow and subsequent dedicated supporting AE assignment.
7.3.2.3 Dedicated supporting AE assignment / registration and actual AE-ID acquisition procedure
Purpose: Ensure that, before PAT issuance, a dedicated supporting AE has been assigned or registered for the MCP Client and that the actual AE-ID of that dedicated supporting AE is available for insertion into onem2m_aeid.
Pre-Conditions:
The MCP Client identity (client_id) has been established.
The oneM2M-side trust establishment prerequisite in clause 7.3.1.1 is satisfied according to deployment policy.
Procedure Description:
The PAT Issuer has or receives the MCP Client identity (client_id) for the authorized MCP Client instance.
The PAT Issuer requests the actual AE-ID for the dedicated supporting AE associated with that MCP Client from the MCP-IPE or from an assignment / acquisition function controlled by the MCP-IPE. The PAT Issuer does not obtain the actual AE-ID directly from the CSE.
The MCP-IPE checks whether a dedicated supporting AE has already been assigned to that MCP Client and whether its actual AE-ID is already available.
If a dedicated supporting AE has already been assigned to that MCP Client and its actual AE-ID is available, the MCP-IPE returns the existing actual AE-ID to the PAT Issuer. Existing dedicated supporting AE assignment reuse is allowed.
If no dedicated supporting AE has yet been assigned to the MCP Client, the MCP-IPE allocates a pre-created dedicated supporting AE or creates and registers a new dedicated supporting AE with the CSE.
The MCP-IPE retains the resulting client-to-dedicated-supporting-AE association state according to deployment policy.
The MCP-IPE returns the actual AE-ID of the dedicated supporting AE associated with the MCP Client to the PAT Issuer for PAT issuance.
NOTE: Whether the MCP-IPE uses a pre-created pool or on-demand creation is deployment-specific. The storage format used for the resulting association state is deployment-specific. The existence and timing of this procedure before PAT issuance are not deployment-specific.
Post-Conditions:
A dedicated supporting AE associated with the MCP Client has been assigned or confirmed for reuse.
The actual AE-ID of the dedicated supporting AE associated with the MCP Client is available to the PAT Issuer for insertion into onem2m_aeid.
7.3.2.4 Authorization code with PKCE and PAT issuance procedure
Purpose: Obtain a PAT bound to the AE-ID of the dedicated supporting AE associated with the MCP Client and targeted to the MCP-IPE.
Pre-Conditions:
The MCP Client has completed PRM retrieval and PAT Issuer discovery.
The dedicated supporting AE assignment / registration and actual AE-ID acquisition procedure in clause 7.3.2.3 has completed.
Procedure Description:
The MCP Client generates Proof Key for Code Exchange (PKCE) [i.15] parameters (e.g., code_verifier and code_challenge) and prepares the authorization request parameters, including:
a resource indicator that identifies the MCP-IPE as the target protected resource, and
a scope set according to local scope selection strategy.
If the WWW-Authenticate challenge includes scope(s), the MCP Client treats the challenged scope set as authoritative for the current request when constructing the authorization request; otherwise it may use scopes_supported as guidance according to local policy.
The MCP Client initiates the authorization request by opening a user-agent (browser) to the PAT Issuer authorization endpoint, including the PKCE parameters and the resource parameter.
The PAT Issuer authenticates the user (or other authorization subject) and obtains authorization for the requested scopes and resource.
In case of user denial, authentication failure, or expired interaction, the PAT Issuer returns an authorization error and the MCP Client aborts the token acquisition attempt.
The PAT Issuer redirects the user-agent back to the MCP Client callback endpoint with an authorization code. The MCP Client receives the authorization code via the callback.
The MCP Client sends a token request to the PAT Issuer token endpoint, including the authorization code, the PKCE code_verifier, and the same resource indicator.
Upon successful validation, the PAT Issuer issues a short-lived PAT for the MCP-IPE with aud identifying the MCP-IPE, client_id identifying the MCP Client instance, and onem2m_aeid carrying the actual AE-ID obtained from the dedicated supporting AE assignment / registration and actual AE-ID acquisition procedure for the dedicated supporting AE associated with that MCP Client, and returns the PAT (and optionally a refresh token) to the MCP Client.
In case issuance is denied, the PAT Issuer returns an authorization error and no PAT is issued.
The MCP Client stores the received PAT securely for subsequent presentation to the MCP-IPE.
In case of token response validation failure at the client side (e.g., missing required fields), the MCP Client discards the tokens and restarts authorization as needed.
Post-Conditions:
The MCP Client holds a valid PAT intended for the MCP-IPE.
7.3.2.5 MCP-IPE verification material preparation procedure
Purpose: Ensure the MCP-IPE can validate PATs locally using PAT Issuer metadata and key material, without requiring per-request interaction with the oneM2M CSE.
Procedure Description:
Prior to processing protected requests, the MCP-IPE retrieves (or refreshes) the PAT Issuer metadata needed to validate token properties (e.g., issuer and JWKS URI), and retrieves the current JWKS from the PAT Issuer.
The MCP-IPE caches the JWKS by key identifier (e.g., kid) and applies refresh logic according to local cache policy.
In case of key mismatch or signature verification failure due to stale keys, the MCP-IPE refreshes JWKS and retries signature verification once before rejecting the request.
The MCP-IPE applies local configuration to enforce token-level requirements (e.g., expected issuer, expected audience, and accepted algorithms) for PAT validation.
Post-Conditions:
The MCP-IPE has the necessary metadata and key material to perform local PAT verification for subsequent protected operations.
7.3.3 Protected operation phase
Figure 7.3.3‑1 provides an overview of the Protected operation phase.
Figure 7.3.3‑1: Overview of the Protected operation phase
Figure 7.3.3‑1: Overview of the Protected operation phase
7.3.3.1 Protected operation overview
In this phase, the MCP Client invokes protected capabilities exposed by the MCP-IPE using a valid PAT. For each protected request, the MCP-IPE validates the PAT locally (e.g., signature, lifetime, and audience), verifies that the request is issued by the token-bound MCP Client (client identifier binding), and applies deny-by-default admission controls that are limited to token-level eligibility and locally configured capability exposure policy. The MCP-IPE then mediates the request into oneM2M operation(s) toward the CSE when applicable. The PAT is terminated at the MCP-IPE and is not forwarded to the oneM2M CSE. The CSE makes the final authorization decision using its native mechanisms, including evaluation of the Originator (From), applicable access control policies, relevant request security context, and optionally DAS processing.
For oneM2M-side communication in this phase, the MCP-IPE uses oneM2M-side credential material prepared according to clause 7.3.1.1 and mediates requests using the dedicated supporting AE associated with the MCP Client as the oneM2M Originator identity. The IPE AE may remain the MCP-IPE's oneM2M-side presence and management anchor, but it is not the default per-client mediated Originator identity in this profile.
In simple mode, the dedicated supporting AE associated with the MCP Client relies on the applicable oneM2M access control state, including default access policy behaviour where applicable. In complex mode, additional privileges may be made available through oneM2M Dynamic Authorization System (DAS) processing, while the CSE remains the final authorization decision point for oneM2M authorization.
NOTE: Error signalling depends on the MCP transport binding. For the HTTP transport, unauthorized, forbidden, and rate-limit outcomes are typically carried as HTTP 401/403/429 responses (and may include WWW-Authenticate guidance). For other transports, equivalent outcomes are returned as corresponding MCP error responses.
7.3.3.2 Common protected request pre-processing procedure
Purpose: Provide a common and repeatable pre-processing pipeline for protected MCP requests so that authentication, token-validation context handling, deny-by-default gating, and abuse controls are applied consistently before any protected action (e.g., capability exposure, tool execution, oneM2M mediation).
Pre-Conditions:
The MCP Client can present a PAT intended for the MCP-IPE and a deployment-specific MCP-side client-binding value corresponding to the token-bound client.
The MCP-IPE has access to PAT Issuer metadata and verification key material (e.g., JWKS) as described in clause 7.3.2.
Procedure Description:
The MCP-IPE applies token extraction and request validation checks (see clause 7.3.3.2.1) to obtain a well-formed request processing context and token presentation.
In case of missing token presentation, the MCP-IPE returns an unauthorized error and, when available, includes WWW-Authenticate information (e.g., resource_metadata) to guide the MCP Client to clause 7.3.2.
The MCP-IPE establishes a validated token context for the PAT (see clause 7.3.3.2.2), using local verification and/or cached validation results according to deployment policy.
In case of invalid or expired token, audience mismatch, or signature failure, the MCP-IPE returns an unauthorized error and, when available, includes resource_metadata to guide re-authorization via clause 7.3.2.
The MCP-IPE applies token acceptance state handling as needed (see clause 7.3.3.2.3) using local caches and token lifecycle signals according to deployment policy.
In case token acceptance state indicates the PAT must not be relied upon, the MCP-IPE returns an unauthorized error and, when available, includes resource_metadata to guide re-authorization via clause 7.3.2.
The MCP-IPE applies token-level deny-by-default admission and capability gating (see clause 7.3.3.2.4), determining whether the request is eligible for further processing.
In case of insufficient scope for the requested capability, the MCP-IPE returns a forbidden error and, when possible, indicates the scope(s) required for satisfying the current request.
The MCP-IPE applies abuse mitigation and audit handling (see clause 7.3.3.2.5) and either rejects the request locally or creates an execution context to be consumed by subsequent procedures in this phase.
Post-Conditions:
If admitted, an execution context is created that includes the requested capability context, token correlation identifiers, the token-bound AE identifier (onem2m_aeid), and references to the time-bounded cached validation result and/or token-validation cache entry used for this request.
If rejected, the request is handled locally at the MCP-IPE with an appropriate error response and does not proceed to oneM2M mediation.
7.3.3.2.1 Token extraction and request validation procedure
Purpose: Extract token presentation and establish a minimally valid request processing context before applying cryptographic validation or authorization gating.
Pre-Conditions:
The MCP-IPE receives an MCP request over a protected transport channel according to deployment policy.
Procedure Description:
The MCP-IPE extracts the PAT from the Authorization header (Bearer) and extracts the deployment-specific MCP-side client-binding value from the selected transport binding or equivalent local request context, and captures basic request metadata (e.g., request identifier, method name, and tool or resource identifiers if present).
In case of missing Authorization header or unsupported token presentation or missing client-binding value, the MCP-IPE returns an unauthorized error and, when available, includes WWW-Authenticate information (e.g., resource_metadata) for clause 7.3.2.
The MCP-IPE performs MCP-layer request validation checks (e.g., JSON-RPC framing validity, method existence, required parameter presence, and message size limits) and rejects malformed requests without contacting the CSE.
In case of malformed request framing or unsupported method invocation, the MCP-IPE returns an appropriate MCP error.
The MCP-IPE determines the requested capability context (e.g., capability discovery vs tools/call) and normalizes capability identifiers into a canonical internal form used for later gating.
Post-Conditions:
A request processing context is available for subsequent token validation and authorization gating steps.
If the request fails validation checks, it is rejected locally without contacting the PAT Issuer or the CSE.
7.3.3.2.2 PAT cryptographic and claim validation procedure
Purpose: Validate the PAT as a JWT access token (JWT AT) using local verification material and establish a validated token context for subsequent token-acceptance handling and capability gating.
Pre-Conditions:
The PAT and the deployment-specific MCP-side client-binding value have been extracted as described in clause 7.3.3.2.1.
The MCP-IPE has cached or retrievable PAT Issuer verification material (e.g., JWKS).
Procedure Description:
The MCP-IPE checks whether a cached token-validation result is available for the presented PAT (e.g., keyed by an internal token hash and stable token identifiers such as iss and jti) and is still within its cache validity bounds.
NOTE 1: Even when a cached validation result is used, the MCP-IPE still evaluates time-variant properties (e.g., exp or nbf with the current time) and applies request-level policy gating in clause 7.3.3.2.4.
If no valid cached result is available, the MCP-IPE verifies the PAT signature using cached verification material and applies local token verification policy (e.g., accepted algorithms and key selection constraints).
If key material resolution fails (e.g., unknown or rotated key identifier), the MCP-IPE refreshes verification material according to local cache policy and retries signature verification once.
In case of persistent signature verification failure, the MCP-IPE returns an unauthorized error and, when available, includes resource_metadata to guide clause 7.3.2.
The MCP-IPE validates essential JWT AT properties relevant for protected operation, including issuer identification (iss), audience restriction (aud identifying the MCP-IPE), and lifetime constraints (exp, iat, and optionally nbf under deployment policy).
In case of invalid or expired token or audience mismatch, the MCP-IPE returns an unauthorized error and, when available, includes resource_metadata to guide clause 7.3.2.
The MCP-IPE extracts token correlation identifiers and bindings needed for later steps (e.g., sub, jti, client_id, onem2m_aeid, and scope or an equivalent representation consistent with JWT access token profiling).
NOTE 2: Depending on deployment policy and JWT access token profiling, the MCP-IPE may additionally validate profile elements such as typ="at+jwt" when present.
The MCP-IPE validates that the deployment-specific MCP-side client-binding value extracted from the request context equals the client_id claim carried in the PAT.
NOTE 3: The exact encoding of the MCP-side client-binding value is deployment-specific; in this profile it is a transport- or execution-context value used by the MCP-IPE to identify the MCP Client instance presenting the protected request.
In case of mismatch, the MCP-IPE rejects the request with an unauthorized outcome and provides PRM guidance (e.g., a WWW-Authenticate challenge that references resource_metadata) so the MCP Client can obtain a new PAT by following clause 7.3.2.
When local verification succeeds (either via fresh verification or cache), the MCP-IPE stores or refreshes a cached token-validation entry with a bounded lifetime that does not exceed the token's remaining validity (e.g., up to exp) and is subject to invalidation events (e.g., notifications described in clause 7.3.3.8).
Post-Conditions:
A validated token context is established and can be used for token-acceptance handling and local capability gating.
Invalid, expired, or audience-mismatched tokens are rejected locally and do not proceed to oneM2M mediation.
The MCP-IPE has verified that the protected request is issued by the token-bound MCP Client by validating the MCP-side client binding against the client_id claim.
7.3.3.2.3 Token acceptance state handling procedure
Purpose: Maintain and apply token-acceptance state (e.g., cached token-validation outcomes and token lifecycle signals) so that the MCP-IPE can effectively accept or reject PATs.
Pre-Conditions:
A validated token context has been established as described in clause 7.3.3.2.2.
The MCP-IPE maintains token-validation cache entries according to local policy.
Procedure Description:
The MCP-IPE determines whether a token-acceptance cache entry exists for the presented PAT and whether it remains valid under local cache policy.
If the deployment supports token lifecycle signals (e.g., revocation signals, key-rotation signals, or other token-acceptance-related notifications), the MCP-IPE applies those signals to invalidate or refresh token-validation cache entries as appropriate.
If token-acceptance state indicates that the PAT must not be relied upon (e.g., explicitly invalidated by local policy), the MCP-IPE rejects the request with an unauthorized outcome and provides PRM guidance (e.g., a WWW-Authenticate challenge that references resource_metadata) so the MCP Client can obtain a new PAT by following clause 7.3.2.
Post-Conditions:
The MCP-IPE has determined whether the PAT remains acceptable for further processing based on token-level acceptance state.
7.3.3.2.4 Token-level deny-by-default admission and capability gating procedure
Purpose: Apply deny-by-default admission controls that are limited to token-level eligibility and locally configured capability exposure controls.
Pre-Conditions:
The MCP-IPE has established a validated token context (clause 7.3.3.2.2) and has applied token-acceptance state handling (clause 7.3.3.2.3).
Procedure Description:
The MCP-IPE determines whether the requested MCP capability is eligible under locally configured exposure policy (e.g., capability allow-lists, tool availability constraints, and scope requirements expressed at the MCP layer).
The MCP-IPE evaluates token-level eligibility for the requested capability based on PAT claims (e.g., scope) and the MCP-side client-binding result established in clause 7.3.3.2.2.
If the capability requires additional scopes that are not present in the PAT, the MCP-IPE returns a forbidden outcome and, when possible, indicates the minimum required scope value(s) for the current capability and includes PRM guidance so the MCP Client can obtain a new PAT with appropriate scopes by following clause 7.3.2.
If the request is not eligible under local exposure policy, the MCP-IPE rejects the request locally with a forbidden outcome.
Post-Conditions:
The MCP-IPE has either admitted the request for further processing (tool execution and/or oneM2M mediation) or rejected it with an appropriate outcome.
7.3.3.2.5 Abuse mitigation and audit procedure
Purpose: Apply abuse-mitigation controls and generate audit records for protected requests without exposing sensitive token material.
Pre-Conditions:
The request has passed token validation and local policy gating, or is being rejected with a decision that should be audited.
Procedure Description:
The MCP-IPE applies rate limiting appropriate for protected endpoints, keyed by stable identifiers available in the validated token context and execution context (e.g., sub, onem2m_aeid, and/or other deployment-specific identifiers).
In case of rate limit exceeded, the MCP-IPE rejects the request locally with a rate-limit error and does not contact the CSE.
The MCP-IPE applies replay or duplication mitigation according to deployment policy (e.g., tracking recently seen request identifiers where such identifiers are available at the MCP layer).
In case of suspected replay or duplication, the MCP-IPE rejects the request locally and does not contact the CSE.
The MCP-IPE records an audit event that correlates the request with relevant identifiers and the decision outcome (e.g., request identifier, sub, jti, onem2m_aeid, capability context, and decision category), while avoiding logging token secrets or sensitive payload beyond what is required by deployment policy.
The MCP-IPE finalizes the execution context for admitted requests so that subsequent procedures can proceed deterministically (e.g., tool execution and oneM2M mediation), or finalizes the error response for rejected requests.
Post-Conditions:
Abuse controls are applied consistently.
An audit record exists for the protected request decision and outcome, without unnecessary exposure of token material.
7.3.3.3 Capability exposure and accessible privileges listing procedure
Purpose: Expose the MCP-IPE's available capabilities to the MCP Client in a least-exposure manner and provide a server-managed view of capability aliases and resource references, so the MCP Client can construct requests without embedding oneM2M security-relevant parameters. This listing is informational at the MCP layer and does not constitute a oneM2M authorization decision; final authorization remains enforced by the CSE.
Pre-Conditions:
The MCP Client can present a PAT intended for the MCP-IPE and a deployment-specific MCP-side client-binding value corresponding to the token-bound client.
The MCP-IPE can apply the common protected request pre-processing pipeline (clause 7.3.3.2).
Procedure Description:
The MCP Client sends a protected capability discovery request to the MCP-IPE (e.g., tools/list, resources/list, and prompts/list where applicable), presenting the PAT.
The MCP-IPE applies the common protected request pre-processing pipeline (clause 7.3.3.2) and establishes the execution context for capability exposure.
In case of token invalid, expired, or revoked, the MCP-IPE returns an unauthorized error and, when available, includes resource_metadata guidance to trigger clause 7.3.2.
In case the requested capability is not eligible under local exposure policy or the PAT has insufficient scope, the MCP-IPE returns a forbidden error and, when possible, indicates the scope(s) required for satisfying the current request.
The MCP-IPE returns tools/list results filtered to the effective token context (e.g., scope) and locally configured capability exposure policy.
The MCP-IPE returns resources/list results as a server-managed list of resource references or aliases that the MCP-IPE is willing to accept as inputs for mediation under the current token context and local policy. The returned list does not assert that the operation will be authorized at the CSE.
NOTE 1: The CSE remains the final decision point for oneM2M authorization. Any listing returned by the MCP-IPE is informational for MCP interaction and does not replace CSE authorization enforcement.
NOTE 2: The MCP-IPE does not rely on client-supplied oneM2M values (e.g., Originator or From, oneM2M resource identifiers, or oneM2M paths) when determining the resource references or aliases and capability parameters to accept for mediation.
Where prompts/list is supported, the MCP-IPE returns only the prompts that are eligible under the effective token context (e.g., scope) and locally configured capability exposure policy, and does not expose prompts that would imply or enable unauthorized actions.
The MCP Client uses the exposed capabilities and server-managed resource references or aliases to select a tool and construct subsequent protected operation requests without embedding oneM2M security-relevant parameters.
Post-Conditions:
The MCP Client has a filtered view of available capabilities (tools, resources, and prompts, where supported) and server-managed resource references or aliases sufficient to drive subsequent tool invocation without requiring oneM2M internal knowledge.
The MCP-IPE has not exposed unnecessary oneM2M internals (e.g., oneM2M resource identifiers, paths, or protocol parameters) beyond what is needed for MCP-side interaction.
Purpose: Allow the MCP Client to invoke a protected tool at the MCP-IPE using the PAT, while keeping oneM2M-specific and security-relevant fields under server-side control to reduce impersonation and injection risks.
Pre-Conditions:
The MCP Client holds a valid PAT intended for the MCP-IPE and presents a deployment-specific MCP-side client-binding value that matches the client_id claim in the PAT.
The MCP Client has obtained capability exposure information and server-managed resource references or aliases as needed (e.g., from clause 7.3.3.3).
Procedure Description:
The MCP Client selects an eligible tool based on the currently exposed capabilities and privileges and prepares a tools/call request with tool-specific parameters.
The MCP Client sends the protected tool invocation request to the MCP-IPE, presenting the PAT in the request (as defined by the transport binding) and presenting the deployment-specific MCP-side client-binding value under the selected transport binding or equivalent local context.
The MCP Client does not attempt to supply oneM2M security-relevant values (e.g., Originator or From, oneM2M resource identifiers, oneM2M paths, or oneM2M protocol headers) as tool parameters for on-behalf-of request forwarding.
In case such values are included in the request payload (intentionally or accidentally), the MCP-IPE may ignore them or reject the request according to local policy.
The MCP Client includes only the minimum information required to express the intended action at the MCP tool level (e.g., target alias or reference and desired state or value), relying on the MCP-IPE to perform server-side mapping and mediation as described in clause 7.3.3.5.
If the MCP Client receives a forbidden response due to local exposure policy or insufficient scope, it may reattempt the operation with a reduced request or re-authorize to obtain the required scope(s) following clause 7.3.2, depending on deployment policy.
Post-Conditions:
A protected tool invocation request has been submitted to the MCP-IPE with token presentation and without relying on client-supplied oneM2M security-relevant parameters.
Subsequent processing follows the MCP-IPE execution and mediation procedure (clause 7.3.3.5) and response handling (clause 7.3.3.7).
7.3.3.5 Tool execution and oneM2M mediation procedure
Purpose: Execute a protected tool invocation at the MCP-IPE and, where applicable, mediate the invocation into oneM2M operation(s) toward the CSE using the dedicated supporting AE associated with the MCP Client as the Originator identity, while minimizing impersonation risks and preserving the CSE's final authorization decision.
Pre-Conditions:
The MCP Client holds a valid PAT intended for the MCP-IPE and presents a deployment-specific MCP-side client-binding value that matches the client_id claim in the PAT.
Common protected request pre-processing (clause 7.3.3.2) can be applied for the incoming request.
Procedure Description:
The MCP Client sends a protected tool invocation request (e.g., tools/call) to the MCP-IPE, presenting the PAT in the request (as defined by the transport binding) and presenting the deployment-specific MCP-side client-binding value under the selected transport binding or equivalent local context.
The MCP-IPE applies the common protected request pre-processing pipeline (clause 7.3.3.2) and determines an execution plan for the requested tool. The execution plan may map to:
zero oneM2M requests (e.g., local processing or cache-based response), or
a single oneM2M request, or multiple oneM2M requests (e.g., retrieve-then-conditionally-update).
In case of token invalid, expired, or revoked, the MCP-IPE returns an unauthorized error and, when available, includes resource_metadata guidance to trigger clause 7.3.2.
In case the requested capability is not eligible under local exposure policy or the PAT has insufficient scope, the MCP-IPE returns a forbidden error and, when possible, indicates the scope(s) required for satisfying the current request.
When oneM2M mediation is required, the MCP-IPE performs server-side mapping, sets the Originator (From) to the AE-ID carried in onem2m_aeid, where that value identifies the dedicated supporting AE associated with the MCP Client, and submits ordinary oneM2M request primitives to the CSE without forwarding the PAT. The MCP-IPE remains the mediator, and the PAT is terminated at the MCP-IPE and is not forwarded to the oneM2M CSE.
NOTE: The MCP-IPE does not rely on client-supplied oneM2M security-relevant values (e.g., Originator or From, oneM2M resource identifiers, or oneM2M paths). The MCP-IPE determines the target and operation through server-side mapping and uses the dedicated supporting AE identified by onem2m_aeid as the Originator.
If the execution plan includes oneM2M request(s), the MCP-IPE sends the prepared oneM2M request primitive(s) to the CSE over the Mca reference point over a protected channel and in a manner that preserves the CSE's applicable oneM2M-side authenticated identity / impersonation-prevention checks, i.e., the Originator (From) value in the request remains consistent with the relevant authenticated requester identity under deployment policy, and collects the resulting oneM2M response(s). If the execution plan maps to zero oneM2M requests, the MCP-IPE produces a local tool result without invoking the CSE.
The MCP-IPE proceeds to response normalization and minimal exposure handling (see clause 7.3.3.7) using either the collected oneM2M response(s) or the local tool result, and returns the resulting MCP response to the MCP Client.
Post-Conditions:
If applicable, oneM2M request primitive(s) are issued to the CSE with Originator derived from onem2m_aeid, where that value identifies the dedicated supporting AE associated with the MCP Client, and are subject to final authorization decision at the CSE.
The MCP-IPE has produced either oneM2M response(s) or a local tool result for subsequent response handling and minimal exposure processing.
The PAT is presented only to the MCP-IPE and is not forwarded to the CSE.
7.3.3.6 CSE authorization and execution procedure
Purpose: Define how the CSE performs final authorization and executes oneM2M operations received from the MCP-IPE.
Pre-Conditions:
The CSE receives oneM2M request primitive(s) from the MCP-IPE.
Procedure Description:
The CSE processes each request as an ordinary oneM2M operation and evaluates authorization using its native mechanisms based on the Originator corresponding to the dedicated supporting AE associated with the MCP Client, the targeted resource, applicable ACPs, and relevant request security context such as whether the Originator is considered authenticated by the Hosting CSE, the resulting rq_authn, and access control evaluation inputs such as accessControlAuthenticationFlag where applicable.
NOTE: In simple mode, the CSE applies the applicable oneM2M access control state for resources created for or by the dedicated supporting AE associated with the MCP Client, including default access policy behaviour where applicable.
The CSE executes the requested operation(s) if authorized and returns a corresponding oneM2M response.
In case of authorization denial under the CSE's native access decision procedure, the CSE returns an appropriate error response, and the MCP-IPE relays it after applying response handling rules (see clause 7.3.3.7).
In complex mode, when DAS is enabled, the CSE may perform additional authorization decision processing by consulting the Dynamic Authorization System (DAS) as part of its native access decision procedure. This report does not specify the internal DAS authentication mechanisms, authorization artifact formats, or DAS decision procedures.
The CSE remains unaware of the PAT and does not require any PAT processing to perform the authorization decision. Any authorization-relevant token or role processing used within oneM2M DAS remains within oneM2M-native procedures.
Post-Conditions:
The MCP-IPE receives oneM2M response(s) indicating success or failure for the mediated operation(s), and the CSE remains the final authorization decision point.
7.3.3.7 Response normalization and minimal exposure procedure
Purpose: Normalize protected operation results into MCP responses while preserving essential semantics and minimizing exposure of oneM2M internals and security-sensitive information.
Pre-Conditions:
The MCP-IPE has either:
received oneM2M response(s) from the CSE for the mediated operation(s), or
produced a local tool result when the execution plan maps to zero oneM2M requests.
Procedure Description:
The MCP-IPE determines the response source for the current operation:
oneM2M response(s) collected from the CSE, or
a local tool result produced by the MCP-IPE.
When oneM2M response(s) are present, the MCP-IPE converts them into an MCP response while preserving the essential outcome semantics (e.g., success vs failure categories) and avoids exposing unnecessary oneM2M details.
In case of non-success responses from the CSE, the MCP-IPE propagates the outcome with minimal shaping and avoids adding information that would increase exposure of the CSE's internal state or resource structure.
The MCP-IPE applies response filtering and normalization to minimize exposure, for example by removing or abstracting non-essential oneM2M internal identifiers, resource tree details, and policy-related artifacts that are not required by the MCP Client for correct operation.
The MCP-IPE records an audit event that correlates the request with stable identifiers (e.g., request identifier, sub, jti, and onem2m_aeid) and the decision or outcome category, without logging sensitive token material or unnecessary payload content beyond deployment policy.
The MCP-IPE returns the normalized MCP response to the MCP Client.
Post-Conditions:
The MCP Client receives an MCP response whose outcome semantics reflect the mediated oneM2M operation(s) or local tool execution, while unnecessary oneM2M internals and token material are not exposed.
An audit record exists for the request outcome with appropriate correlation identifiers.
Purpose: Ensure the MCP-IPE reflects token acceptance changes managed by the PAT Issuer (e.g., revocation signals, key rotation, or other token lifecycle-related events) by refreshing or invalidating cached token-validation context, thereby reducing the window for accepting a token based on stale validation context.
Pre-Conditions:
The MCP-IPE maintains cached token-validation context used for protected operations according to local policy.
A protected channel exists between the PAT Issuer and the MCP-IPE for delivering token-acceptance-related notifications according to deployment policy.
Procedure Description:
The PAT Issuer detects a token-acceptance-related event relevant to the MCP-IPE (e.g., token revocation, key rotation, issuer metadata change, or other lifecycle events that affect whether a presented PAT should be accepted).
The PAT Issuer sends a notification to the MCP-IPE identifying the affected token-validation context (e.g., by iss, jti, subject, key identifier, or other stable correlation identifiers supported by the deployment).
In case of notification delivery failure, the MCP-IPE's cache entries expire according to local cache policy so that stale validation context is eventually removed even without notification.
Upon receiving the notification, the MCP-IPE invalidates, refreshes, or marks as stale the affected cached token-validation entries according to local policy.
For subsequent protected requests that rely on affected cached validation context, the MCP-IPE performs fresh token validation (or refreshes verification material such as JWKS or metadata) before admitting the request for further processing.
The MCP-IPE records an audit event for notification receipt and cache invalidation, without logging sensitive token material.
Post-Conditions:
Token acceptance changes managed by the PAT Issuer are reflected in the MCP-IPE's token-validation caches within the bounds of notification delivery and local cache policy.
Subsequent protected requests are not admitted based on stale token-validation context.
7.3.3.9 Operational scenarios procedure
The following scenarios illustrate protected operations mediated by the MCP-IPE. Where a concrete example is needed, a flexContainer or a container or contentInstance mapping may be used according to deployment policy.
7.3.3.9.1 Sensing scenario (Retrieve state)
The MCP Client discovers capabilities and associated privileges via tools/list and resources/list (see clause 7.3.3.3).
The MCP Client invokes a sensing tool (tools/call) with the PAT (see clause 7.3.3.4).
The MCP-IPE applies the common pre-processing (see clause 7.3.3.2) and mediates the request to oneM2M operation(s) that retrieve the current state from the mapped resource(s) (e.g., RETRIEVE on a flexContainer).
The CSE enforces access control and returns the result; the MCP-IPE normalizes the response and returns it to the MCP Client (see clause 7.3.3.6 and 7.3.3.7).
The MCP Client discovers actuation-related capabilities and privileges (see clause 7.3.3.3).
The MCP Client invokes an actuation tool (tools/call) with the desired target parameters (see clause 7.3.3.4).
The MCP-IPE applies the common pre-processing (see clause 7.3.3.2) and mediates the request to oneM2M operation(s) that apply the state change to the mapped resource(s) (e.g., UPDATE on a flexContainer or CREATE of a contentInstance under a container).
The CSE enforces access control and returns the result; the MCP-IPE normalizes the response and returns it to the MCP Client (see clause 7.3.3.6 and 7.3.3.7).
The MCP Client invokes a tool that requires multi-step mediation (e.g., "change state only if current state differs") using the PAT.
The MCP-IPE applies the common pre-processing (see clause 7.3.3.2) and first performs oneM2M operation(s) to retrieve current state from the mapped resource(s) (e.g., RETRIEVE).
Based on the retrieved state and local policy gating, the MCP-IPE conditionally performs subsequent oneM2M operation(s) to apply changes (e.g., UPDATE or CREATE), noting that a single tool invocation may map to multiple oneM2M requests.
In case of insufficient privileges for any step, the MCP-IPE returns a forbidden error and, when possible, indicates the scope(s) required for step-up authorization (see clause 7.3.3.2.4).
The MCP-IPE normalizes the combined outcome into an MCP response and records an audit event (see clause 7.3.3.7).
7.3.4 Token Reissuance phase
This phase specifies how the MCP Client obtains a new PAT when the currently held PAT can no longer be used for protected requests to the MCP-IPE. Reissuance is required because a PAT is a time-bounded bearer credential, because the effective authorization grant may change over time (e.g., revocation or privilege updates), and because additional scopes may be required at runtime (step-up) and cannot be satisfied by the existing PAT. Token acquisition mechanisms (e.g., PRM-based discovery, PAT Issuer discovery, and OAuth-based authorization flows) follow clause 7.3.2 and are not repeated here. In this profile, onem2m_aeid continues to identify the dedicated supporting AE associated with the MCP Client during reissuance. The exact encoding of errors and notifications is deployment-specific and depends on the selected transport binding. Optional PAT-Issuer-to-MCP-IPE notification is described separately in clause 7.3.4.3.
Figure 7.3.4‑1 provides an overview of the Token Reissuance phase.
7.3.4.1 Reissuance trigger and client guidance procedure
Purpose: Determine when a new PAT is required and provide sufficient guidance for the MCP Client to obtain a new PAT by following clause 7.3.2.
Pre-Conditions:
The MCP Client is configured with the MCP-IPE endpoint.
The MCP-IPE supports PRM-based discovery as described in clause 7.3.2.
Procedure Description:
The MCP Client sends a protected request to the MCP-IPE using its current PAT.
The MCP-IPE determines that a new PAT is required when any of the following conditions holds:
The PAT is missing or not acceptable e.g., malformed, expired, not yet valid, or fails signature or claim validation).
The PAT is not intended for the MCP-IPE (audience does not identify the MCP-IPE).
The PAT is valid but the requested capability requires additional scopes (step-up is required).
The PAT Issuer has revoked or otherwise invalidated the PAT (e.g., due to privilege updates), so the PAT is no longer acceptable for protected requests.
The deployment-specific MCP-side client-binding value presented in the request context does not match the client_id claim carried in the PAT.
When the PAT is missing or not acceptable, or not intended for the MCP-IPE, or the client-binding check fails, the MCP-IPE returns an unauthorized outcome and provides PRM guidance (e.g., a WWW-Authenticate challenge that references resource_metadata) so the MCP Client can obtain a new PAT by following clause 7.3.2.
In case of missing or malformed PRM guidance, the MCP Client performs PRM discovery according to clause 7.3.2; otherwise it fails the authorization attempt.
When step-up is required, the MCP-IPE returns a forbidden outcome and, when possible, indicates insufficient scope, provides the minimum required scope value(s) for the current capability, and includes a resource_metadata reference so the MCP Client can obtain a new PAT with appropriate scopes by following clause 7.3.2.
In case the PAT Issuer denies the requested scopes, the MCP Client does not proceed with the protected operation using the current PAT.
The MCP Client initiates reissuance by re-running the applicable parts of clause 7.3.2 to obtain a new PAT intended for the MCP-IPE.
The MCP Client retries the previously failed protected request only after obtaining a new PAT.
Post-Conditions:
The MCP Client has sufficient guidance to obtain a new PAT via clause 7.3.2.
Requests under a non-acceptable PAT are handled at the MCP-IPE and do not reach the oneM2M CSE.
7.3.4.2 New PAT issuance procedure
Purpose: Ensure that the new PAT and the PAT Issuer authorization state remain consistent, while keeping the PAT terminated at the MCP-IPE.
Pre-Conditions:
The PAT Issuer maintains authoritative token status and privilege records.
Procedure Description:
The MCP Client obtains a new PAT by re-running the applicable parts of clause 7.3.2, requesting only the scopes required for the intended capability. Where required by deployment policy, this includes reusing or re-confirming the existing dedicated supporting AE assignment and actual AE-ID acquisition result before issuance.
The PAT Issuer issues a new PAT intended for the MCP-IPE (aud identifies the MCP-IPE) and includes the oneM2M binding claim (onem2m_aeid) as the single oneM2M-specific claim according to this profile. That claim continues to identify the AE-ID of the dedicated supporting AE associated with the MCP Client.
In case issuance is denied, the PAT Issuer returns an authorization error and no new PAT is issued.
The PAT Issuer updates its authorization state store to reflect the new effective state, including token lifecycle status and the effective privilege records.
The MCP Client stores the new PAT securely and retries the previously failed protected request to the MCP-IPE with the new PAT.
Upon receiving the retried request, the MCP-IPE validates the new PAT (including MCP-side client binding validation) and applies token-level admission checks before proceeding with clause 7.3.3 while terminating the PAT at the MCP boundary.
Post-Conditions:
The MCP Client holds a new PAT for continued protected operations toward the MCP-IPE.
The PAT is terminated at the MCP-IPE and is not forwarded to the oneM2M CSE.
7.3.4.3 Revocation and reissuance change notification procedure
Purpose: Ensure revocation and key or metadata changes are reflected at the MCP boundary by notifying the MCP-IPE so that stale token-validation context is invalidated and token acceptance reflects the current PAT Issuer state.
Pre-Conditions:
A protected channel exists between the PAT Issuer and the MCP-IPE for operational notifications according to deployment policy.
The MCP-IPE may maintain bounded token-validation caches according to local cache policy.
Procedure Description:
The PAT Issuer determines that an authorization state change must be applied, including one or more of:
token revocation,
token replacement due to reissuance,
effective privilege update.
The PAT Issuer commits the change in its authoritative state, including updating token lifecycle status and any associated issuance records.
The PAT Issuer notifies the MCP-IPE of the change with sufficient information to identify the affected token-validation context (e.g., by iss, jti, subject, or key identifier) and invalidate relevant cached entries. The exact notification encoding and field names are deployment-specific.
Upon receiving the notification, the MCP-IPE invalidates cached token-validation context for the identified token(s) and applies updated token acceptance on subsequent requests:
In case of revoked or replaced tokens, the MCP-IPE treats matching tokens as invalid and returns an unauthorized outcome without contacting the oneM2M CSE.
In case of key rotation or metadata changes, the MCP-IPE refreshes verification material (e.g., JWKS or metadata) according to local cache policy before accepting subsequent requests.
The MCP-IPE records an audit event for notification receipt and cache invalidation, without logging sensitive token material.
Post-Conditions:
Revocation and reissuance-driven changes are propagated to the MCP-IPE as explicit events, and stale cached token-validation context is not relied upon for subsequent protected operations.
7.3.5 AE de-registration and cleanup phase
This phase specifies how AE-related state associated with the dedicated supporting AE for an MCP Client is removed when that MCP Client is decommissioned or remains inactive beyond deployment policy. This cleanup is distinct from PAT reissuance because it concerns the lifecycle of the dedicated supporting AE associated with the MCP Client and related state, not only the lifecycle of the PAT. Depending on deployment policy, this typically corresponds to de-registration of the dedicated supporting AE, usually realized by deletion of the AE resource or equivalent lifecycle cleanup at the hosting CSE.
7.3.5.1 Dedicated supporting AE de-registration and cleanup procedure
Purpose: Revoke PAT use and remove unused AE-related state when an MCP Client is decommissioned or remains inactive beyond deployment policy. Unused resources, credential material, or association state associated with the dedicated supporting AE for that MCP Client are a security risk.
Pre-Conditions:
MCP Client decommissioning, prolonged inactivity, or an equivalent lifecycle trigger has been identified according to deployment policy.
Procedure Description:
The PAT Issuer revokes or marks non-acceptable any active PAT associated with the affected MCP Client.
Stored oneM2M-side credential material, protected association state, or other protected records associated with the dedicated supporting AE associated with the MCP Client are disabled, removed, or otherwise made non-usable according to deployment policy.
If the dedicated supporting AE is no longer needed, the responsible oneM2M management function de-registers that dedicated supporting AE according to deployment policy, typically by deleting the AE resource or applying equivalent lifecycle cleanup at the hosting CSE.
Resources that were created for or by that dedicated supporting AE and are no longer needed are removed or marked for cleanup according to deployment policy.
The cleanup result is recorded for audit and operational follow-up.
Post-Conditions:
Active PAT use is terminated for the affected MCP Client.
Stored material and association state for the dedicated supporting AE associated with the MCP Client that should no longer be used have been disabled, removed, or marked for follow-up according to deployment policy.
Unused AE-related resources are removed or are pending explicit cleanup according to deployment policy.
oneM2M TR-0081Release Notes diff from v0.2.0 to v0.1.0
