1. Considerations on M2M URIs Group Name: WG2(ARC) Source: Yong-Suk Park, Sung-Chan Choi, Jaeho Kim, KETI, {yspark,csc,jhkim}@keti.re.kr Meeting Date: 2013-12-10 Agenda Item: Consideration of M2M URIs

2. Issue 1 Length of URIs – Current oneM2M resource structure allows to have long URIs. – Example: cseBase/cses/mn- cse1/temperature_applications/temperature_application_2/ containers/container_1/contentInstances/contentInstance1/ content – Pros: easy to explore based on network topology a client machine can easily guess which resources comes next – Cons: long URIs are not appropriate for a constraint devices Better to have shorten URI length

3. Issue 2 (1) Open API – Generally, API provides capabilities of interacting with a M2M platform using REST interface. – API includes a URI, which can represent a resource in oneM2M resource model. – For M2M service ecosystem, APIs need to be opened to service developers. – However, it is hard to open APIs including a full URI: Problem 1. a full URI is too long to use Problem 2. Resource is dynamically created, and thus a full URI representing the resource is created as well. Accordingly, a full URI could not be published prior to creation of a resource. – We need a Pseudonym URI representing a full URI, which can be practically included in API opened to service developers. 3 Better to have Pseudonym URIs for Open API

4. Issue 2 (2) Open API 4 Better to have Pseudonym URIs for Open API M2M refrigerator “X” functions - monitoring doorStatus - monitoring foodstuffs …… - setting temperature Open APIs - GET cseBase/ /doorStatus - GET cseBase/ /foodstuffs …… - PUT cseBase/ /setTemperature X’s APIs Deployment X_#1 X_#2 X_#n …… Infrastructure Node User A using X_#1 User B using X_#2 Instance #1 of X GET cseBase/id_of_X_#1/doorStatus Instance #2 of X Instance #n of X GET cseBase/id_of_X_#2/doorStatus …… cseBase/cses/mncseXX/refrigerator_applications/refrigerator_application/containers/con tainer/contentInstances/contentInstance1/content Pseudonym URI

5. Issue 3 Security – In the case of a hierarchical resource structure, the structure reveals the network topology. – Anyone who sees the URI can easily guess which resource is for a Gateway and target it for an attack. – For a highly secure system, a URI itself better not to be shared with others. 5 Better to use more secure URIs

6. Direction Option 1 (Issue 1 & 2) – Pseudonym URI based on device identifier – Example: cseBase/cses/… /content  cseBase/ /container_name Option 2 (Issue 1 & 3): pseudonym URI – Each URI is mapped to pseudonym URI – Example: cseBase/cses/… /content  cseBase/asdfr03ndnbabddfs (using 17 bytes pseudonym URI) – Pseudonym URI resource or interworking function or mapping tables are required. – For much more secure: client specific pseudonym URI For a resource, all clients get different URIs Pseudonym URI is generated based on both the client machine and the original URI. Example: For the cseBase/cses/mn-cse_12 … /content – Client A:  cseBase/asdfr03ndnbabddfs – Client B:  cseBase/998asdnasdfasdfaa – Client C:  cseBase/998asdnasdfasdfaa 6