Proposal for App Id and Service Provider Id registration Group Name: Shelby Kiewel Source: Shelby Kiewel, iconectiv / Ericsson, Meeting Date:

Introduction Application ID – Concept – Assignment and Administration of Identifier – Potential Usage Service Provider ID – Concept – Method of administration of Identifier © 2014 oneM2M Partners 2

Application Id Applications could be registered along with the following information – Registry: multiple registries could be operating at once – Application Purpose (or function): Sensor, Data Store – Payload: HTML, JSONP, SOAP, XML – Generic (GENR) or oneM2M-SP-ID – Version – Contract Interface details – Service Provider Specific: Yes, No App ID proposal: Users and oneM2M nodes can query the registry to determine available applications Application Ids can identify either individual function calls or entire suites of functionality

Application Purpose An indication of the primary function served by the application would be inventoried by the registrar Proposed primary application values are: – Analysis (ANAL) – concerned with the analysis of information – Data Store (DTST) – amass and manage information repositories of information – Integration (INTG) – involved in integrating information from different sources – Processor (PROC) – sum, tabulate, consolidate larger numbers of inputs into summarized information – Management (MGMT) – concerned with the oversight and management of other nodes – Monitor (MNTR) – monitor the function of the oneM2M network – Security (SECU) – authorize and authenticate oneM2M communications – Sensor (SENS) – collection the value of one or more attributes

Example App Ids ‘Connect Many to Many Inc.’ has registered 2 App Ids – App Id: RegA-SENS-XML-GENR was registered in registry A for software which primarily is involved in sensing. The XML contract interface is open to everyone (or Generic) and can be accessed from the App Id record – App Id: RegA-SENS-XML-CMTM was registered in registry A for software which primarily is involved in sensing. The XML contract interface is CMTM proprietary and can not be inspected Generic Proprietary

Single/Multiple Registries With a single registrar/administration authority, the identifiers would be able to associate to the oneM2M namespace With multiple registrar’s/authorities, complexity in management of the identifiers becomes problematic – Advanced coordination between the repositories would be required – Maintaining the uniqueness of the identifier requires real-time validation between registries – Separate API’s, processes, interfaces, agreements, and more would be necessary for providers of oneM2M applications

Payload Request and response messages can be provided in different formats. – Potential payload formats: HTML, JSONP, SOAP or XML – Request/response scheme would be included in the application record

Versioning Software version of the App Id. – The App Id will potentially change for each release. – The App Id will allow consumers to identify prerelease versions – alpha and beta. Version and backward compatibility will also allow automated decisions about whether upgrading version is feasible or warranted within the oneM2M system.

Contract Interface The contract interface will be uploaded and analyzed for adherence to oneM2M standards and validated for uniqueness and backward compatibility to the extent possible (e.g., upload the SOAP WSDL) Software Stores will need to make software available by App Id – Inclusion of compatible App Ids needed for ‘customers’ to find compatible applications which run in their environment if.. The exact App Id is not available potentially due to.. – Running on a different platform or… – Exposes a contract interface like SOAP, but a JSONP interface is preferred.

Contract Interface - Example Temperature: Request RegA-SENS-SOAP-GENR procX1A27 ******* Temperature: Response ,000 ft

Service Provider Specific AppID The App Id is intended to be Generic and freely reusable within the oneM2M ecosystem. Generic/Open App Id’s could be clearly indicated in the App Id identifier e.g. –GENR- Potential Method of Application Segregation – Service Providers may optionally retain the proprietary nature of their application; they would submit the Contract Interface to the registrar, but information would not be made available to public App Ids queries – Registration of applications may be by application developers rather than Service Providers – For application only developers, the registrar would be required to retain some process of identification for these companies.

Potential AppId Usage Potentially used to route a request to a node where an instance of the requested software is available AppId software instance could authenticate that the credentials are correct AppId software instance could determine if the provided credentials are allowed to perform the requested function Access Control Privileges could be assigned/managed at an AppId level, supporting various management privilege scenarios

Service Provider ID (M2M-SP-ID) Companies requesting an App Id must have a Service Provider Code Questions and issues surround the App Id usage and performance can be directed to responsible party, i.e. Service Provider

Service Provider ID (M2M-SP-ID) Companies which operate in the oneM2M space: – Service Providers – Software Companies – Hardware Companies Require company legal documents to establish an identifier Register company name, headquarters location and contact information Associate a unique mnemonic code to be used when identifying the company

M2M-SP-Id’s are provided by registrar and follow a procedure to select the mnemonic code which models the Company Name where possible Example (M2M-SP-ID)

Thank you for your attention