ETSI TR 118 516 V2.0.0 (2016-09)

TECHNICAL REPORT
oneM2M;
Study of Authorization Architecture for Supporting
Heterogeneous Access Control Policies
(oneM2M TR-0016 version 2.0.0)

oneM2M TR-0016 version 2.0.0 2 ETSI TR 118 516 V2.0.0 (2016-09)

Reference
DTR/oneM2M-000016
Keywords
authorization, IoT, M2M
ETSI
650 Route des Lucioles
F-06921 Sophia Antipolis Cedex - FRANCE

Tel.: +33 4 92 94 42 00  Fax: +33 4 93 65 47 16

Siret N° 348 623 562 00017 - NAF 742 C
Association à but non lucratif enregistrée à la
Sous-Préfecture de Grasse (06) N° 7803/88

Important notice
The present document can be downloaded from:
http://www.etsi.org/standards-search
The present document may be made available in electronic versions and/or in print. The content of any electronic and/or
print versions of the present document shall not be modified without the prior written authorization of ETSI. In case of any
existing or perceived difference in contents between such versions and/or in print, the only prevailing document is the
print of the Portable Document Format (PDF) version kept on a specific network drive within ETSI Secretariat.
Users of the present document should be aware that the document may be subject to revision or change of status.
Information on the current status of this and other ETSI documents is available at
https://portal.etsi.org/TB/ETSIDeliverableStatus.aspx
If you find errors in the present document, please send your comment to one of the following services:
https://portal.etsi.org/People/CommiteeSupportStaff.aspx
Copyright Notification
No part may be reproduced or utilized in any form or by any means, electronic or mechanical, including photocopying
and microfilm except as authorized by written permission of ETSI.
The content of the PDF version shall not be modified without the written authorization of ETSI.
The copyright and the foregoing restriction extend to reproduction in all media.

© European Telecommunications Standards Institute 2016.
All rights reserved.
TM TM TM
DECT , PLUGTESTS , UMTS and the ETSI logo are Trade Marks of ETSI registered for the benefit of its Members.
TM
3GPP and LTE™ are Trade Marks of ETSI registered for the benefit of its Members and
of the 3GPP Organizational Partners.
GSM® and the GSM logo are Trade Marks registered and owned by the GSM Association.
ETSI
oneM2M TR-0016 version 2.0.0 3 ETSI TR 118 516 V2.0.0 (2016-09)
Contents
Intellectual Property Rights . 5
Foreword . 5
1 Scope . 6
2 References . 6
2.1 Normative references . 6
2.2 Informative references . 6
3 Definitions and abbreviations . 7
3.1 Definitions . 7
3.2 Abbreviations . 7
4 Conventions . 7
5 Overview of authorization system . 7
5.1 High level authorization architecture . 7
5.2 Generic authorization procedure . 9
6 Detailed design of authorization architecture . 10
6.1 Self-contained authorization . 10
6.2 Distributed authorization . 10
6.2.1 Distributed authorization use cases . 10
6.2.1.1 M2M gateway make access control decisions on behalf of m2m devices . 10
6.2.2 Proposal 1: Using resource-based approach to implement distributed authorization . 11
6.2.2.1 Introduction . 11
6.2.2.2 Resources . 11
6.2.2.2.1 Resource type authorization . 11
6.2.2.2.2 Resource type policyDecisionPoint . 13
6.2.2.2.3 Resource type policyRetrievalPoint . 13
6.2.2.2.4 Resource type policyInformationPoint . 13
6.2.2.3 Procedures . 13
6.2.2.3.1 Introduction . 13
6.2.2.3.2 Create . 13
6.2.2.3.3 Retrieve . 14
6.2.2.3.4 Update . 14
6.2.2.3.5 Delete . 15
6.2.2.3.6 Retrieve . 15
6.2.2.3.7 Retrieve . 16
6.2.2.3.8 Retrieve . 17
6.3 Message between authorization components. 18
6.3.1 Proposal 1: Extending XACML and SAML for exchanging message between authorization
components . 18
6.3.1.1 Messages between PEP and PDP . 18
6.3.1.1.1 Introduction of XACML element and element . 18
6.3.1.1.2 Using XACML element . 19
6.3.1.1.3 Using XACML element . 21
6.3.1.2 Messages between PDP and PIP . 22
6.3.1.2.1 Introduction of SAML . 22
6.3.1.2.2 Using SAML element . 22
6.3.1.2.3 Using SAML element . 23
6.4 Implementing Role Based Access Control . 24
6.4.1 Introduction of Role Based Access Control . 24
6.4.2 General procedure of user-role assignment and role use . 25
6.4.3 Solutions of implementing Role Based Access Control . 26
6.4.3.1 Proposal 1: Solution of supporting Role Based Access Control . 26
6.4.3.1.1 Role Based Access Control architecture . 26
6.4.3.1.2 Role token structure . 27
6.4.3.1.3 Resource type role . 28
6.4.3.1.4 Role Based Access Control procedure without using role tokens . 30
ETSI
oneM2M TR-0016 version 2.0.0 4 ETSI TR 118 516 V2.0.0 (2016-09)
6.4.3.1.5 Role Based Access Control procedure using role tokens . 32
6.5 Implementing Attribute Based Access Control . 34
6.5.1 Introduction of Attribute Based Access Control . 34
6.5.2 General procedure of Attribute Based Access Control . 35
6.5.3 Solutions of implementing Attribute Based Access Control . 37
7 Supporting user specified access control policies . 37
7.1 Issues . 37
7.2 Solutions . 37
7.2.1 Proposal 1: Solution of supporting heterogeneous access control policies . 37
7.2.1.1 Introduction . 37
7.2.1.2 Redefined resource type accessControlPolicy . 37
7.2.1.3 Generic procedure of evaluating heterogeneous access control policies . 38
8 Investigating existing access control policy languages and proposals . 39
8.1 Proposal 1: Using XACML . 39
8.1.1 Introduction. 39
8.1.2 Detailed descriptions. 40
8.1.3 Evaluation . 42
8.2 Evaluation of oneM2M access control rule . 43
8.2.1 Introduction. 43
8.2.2 Application scenario description . 43
8.2.3 Access control rules and evaluation . 44
8.2.4 Conclusion . 45
8.3 Proposal of new access control rule format . 45
8.3.1 Introduction. 45
8.3.2 Rule format . 45
8.3.2.1 Introduction . 45
8.3.2.2 accessControlResources . 45
8.3.2.3 permittedAttributes . 46
8.3.2.4 permittedChildResources . 46
8.3.3 Evaluation of the proposed oneM2M access control rule . 46
8.3.4 Conclusion . 47
9 Privacy protection architecture using Privacy Policy Manager (PPM) . 47
9.1 Introduction . 47
9.2 Relationship between components of PPM and oneM2M . 47
9.3 Privacy Policy Management in oneM2M architecture . 48
9.3.0 Introduction. 48
9.3.1 Actor . 48
9.3.2 Management flow in PPM architecture . 49
9.3.2.1 Join to a M2M platform . 49
9.3.2.2 Subscription to an ASP's service . 50
9.3.2.3 Request for personal data to the M2M platform . 51
10 Conclusions . 53
Annex A: Bibliography . 54
History . 55

ETSI
oneM2M TR-0016 version 2.0.0 5 ETSI TR 118 516 V2.0.0 (2016-09)
Intellectual Property Rights
IPRs essential or potentially essential to the present document may have been declared to ETSI. The information
pertaining to these essential IPRs, if any, is publicly available for ETSI members and non-members, and can be found
in ETSI SR 000 314: "Intellectual Property Rights (IPRs); Essential, or potentially Essential, IPRs notified to ETSI in
respect of ETSI standards", which is available from the ETSI Secretariat. Latest updates are available on the ETSI Web
server (https://ipr.etsi.org/).
Pursuant to the ETSI IPR Policy, no investigation, including IPR searches, has been carried out by ETSI. No guarantee
can be given as to the existence of other IPRs not referenced in ETSI SR 000 314 (or the updates on the ETSI Web
server) which are, or may be, or may become, essential to the present document.
Foreword
This Technical Report (TR) has been produced by ETSI Partnership Project oneM2M (oneM2M).
ETSI
oneM2M TR-0016 version 2.0.0 6 ETSI TR 118 516 V2.0.0 (2016-09)
1 Scope
The present document provides technical solutions for oneM2M authorization architecture, authorization procedures
and access control policies. The present document also gives evaluations of these proposed technical solutions.
ETSI TS 118 103 [i.2] only defines a high level authorization architecture that describes its major components and
general authorization procedure. The objective of the present document is to provide candidate security solutions related
to authorization architecture, authorization procedures and access control policies.
The present document provides security solutions in the following three aspects:
• Detailed design of authorization architecture: This part investigates the interfaces among authorization
components (e.g. procedures and parameters), how these components could be distributed in different
oneM2M entities (i.e. different CSEs), and how to implement Role Based Access Control (RBAC) and token
based access control.
• Supporting user specified access control policies: This part investigates how the oneM2M authorization
system could be an extensible system that can support user-defined access control mechanisms and/or access
control policy languages.
• Investigating existing access control policy languages: This part investigates if some standardized access
control policy languages could become oneM2M recommended access control policy description languages.
2 References
2.1 Normative references
References are either specific (identified by date of publication and/or edition number or version number) or
non-specific. For specific references, only the cited version applies. For non-specific references, the latest version of the
referenced document (including any amendments) applies.
Referenced documents which are not found to be publicly available in the expected location might be found at
https://docbox.etsi.org/Reference/.
NOTE: While any hyperlinks included in this clause were valid at the time of publication, ETSI cannot guarantee
their long term validity.
The following referenced documents are necessary for the application of the present document.
Not applicable.
2.2 Informative references
References are either specific (identified by date of publication and/or edition number or version number) or
non-specific. For specific references, only the cited version applies. For non-specific references, the latest version of the
referenced document (including any amendments) applies.
NOTE: While any hyperlinks included in this clause were valid at the time of publication, ETSI cannot guarantee
their long term validity.
The following referenced documents are not necessary for the application of the present document but they assist the
user with regard to a particular subject area.
[i.1] ETSI TS 118 101: "oneM2M; Functional Architecture (oneM2M TS-0001)".
[i.2] ETSI TS 118 103: "oneM2M; Security Solutions (oneM2M TS-0003)".
[i.3] ANSI American national standard for information technology - role based access control. ANSI
INCITS 359-2004, February 2004.
ETSI
oneM2M TR-0016 version 2.0.0 7 ETSI TR 118 516 V2.0.0 (2016-09)
[i.4] NIST Special Publication 800-162: "Guide to Attribute Based Access Control (ABAC) Definition
and Considerations".
[i.5] OASIS Standard: "eXtensible Access Control Markup Language (XACML)", Version 3.0,
22 January 2013.
[i.6] OASIS Standard: "Assertions and Protocols for the OASIS Security Assertion Markup Language
(SAML)" V2.0.
[i.7] oneM2M Drafting Rules.
NOTE: Available at http://www.onem2m.org/images/files/oneM2M-Drafting-Rules.pdf.
[i.8] ETSI TS 118 111: "oneM2M; Common Terminology (oneM2M TS-0011)".
[i.9] ETSI TR 118 501: "oneM2M; Use Case collection (oneM2M TR-0001)".
3 Definitions and abbreviations
3.1 Definitions
For the purposes of the present document, the terms and definitions given in ETSI TS 118 111 [i.8] apply.
3.2 Abbreviations
For the purposes of the present document, the abbreviations given in ETSI TS 118 111 [i.8] apply.
4 Conventions
The key words "Shall", "Shall not", "May", "Need not", "Should", "Should not" in the present document are to be
interpreted as described in the oneM2M Drafting Rules [i.7].
5 Overview of authorization system
5.1 High level authorization architecture
Figure 5.1-1 provides a high level overview of a generic authorization architecture. This architecture comprises four
subcomponents that are described as follows:
• Policy Enforcement Point (PEP):
- PEP intercepts resource access requests, makes access control decision requests, and enforces access
control decisions. The PEP coexists with the entity that needs authorization services.
• Policy Decision Point (PDP):
- PDP interacts with the PRP and PIP to get applicable authorization polices and attributes needed to
evaluate authorization policies respectively, and then evaluates access requests using authorization
policies to render an access control decision. The PDP is located in the Authorization service.
• Policy Retrieval Point (PRP):
- PRP obtains applicable authorization policies according to an access control decision request. These
applicable policies should be combined in order to get a finial access control decision. The PRP is
located in the Authorization service.
ETSI
oneM2M TR-0016 version 2.0.0 8 ETSI TR 118 516 V2.0.0 (2016-09)
• Policy Information Point (PIP):
- PIP provides attributes that are needed to evaluate authorization policies, for example the IP address of
the requester, creation time of the resource, current time or location information of the requester. The PIP
is located in the Authorization service.
The Authorization service may comprise any of the subcomponents: PDP, PRP and/or PIP. This means that the
subcomponents PEP, PRP, PDP and PIP could be distributed across different nodes. For example the PEP is located in
an ASN/MN and the PDP is located in the IN.
The present release 1 does not support separation of PRP and PIP on different CSE from PDP. The generic procedure
described below is provided for information and to support further extensions, while clause 7 provides the details of
authorization mechanisms in the current release.

Figure 5.1-1: Overview of the authorization architecture
ETSI
oneM2M TR-0016 version 2.0.0 9 ETSI TR 118 516 V2.0.0 (2016-09)
5.2 Generic authorization procedure
The generic authorization procedure is shown in figure 5.2-1.

Figure 5.2-1: Authorization Procedure
Step 001: Mutual authentication (Pre-requisite).
Step 002: Access Requester sends an Access Request to the PEP.
Step 003: PEP makes an Access Control Decision Request according to the requester's Access Request, and
sends the Access Control Decision Request to the PDP.
Step 004: PDP sends an Access Control Policy Request that is generated based on the Access Control
Decision Request to the PRP.
Step 005: PRP finds all access control policies applicable to the access request and sends them back to the
PDP. When multiple access control polices are involved, the PRP also provides a policy
combination algorithm to combine multiple evaluation results into one finial result.
Step 006 PDP sends Attribute Request to the PIP, if any attributes are needed to evaluate these access
control policies.
Step 007: PIP gets requested attributes and sends them back to the PDP.
Step 008: PDP evaluates Access Request using access control policies. When there are multiple applicable
access control policies, the PEP needs to calculate a final Access Control Decision using the policy
combination algorithm.
Step 009: PDP returns the Access Control Decision to the PEP.
Step 010: PEP enforces the access control decision, i.e. either forwards the Access Request to the resource or
denies this access.
Step 011: PEP returns access result back to the Access Requester.
ETSI
oneM2M TR-0016 version 2.0.0 10 ETSI TR 118 516 V2.0.0 (2016-09)
6 Detailed design of authorization architecture
6.1 Self-contained authorization
In a self-contained authorization system the PEP, PDP, PRP and PIP are all in the same CSE, and the messages
exchanged between these authorization components are not crossing the oneM2M reference points Mca, Mcc and Mcn.
So there is no specific standardization requirement about how to implement PEP, PDP, PRP and PIP, and the
interactions between them.
6.2 Distributed authorization
6.2.1 Distributed authorization use cases
6.2.1.1 M2M gateway make access control decisions on behalf of m2m devices
Some constrained M2M Devices may be unable to evaluate the complex access control policy languages, such as those
investigated in clause 8 "Investigating existing access control policy languages". These M2M Devices may be
configured to request an M2M Gateway to assist with making access control decisions.
Here consider a scenario with two M2M Devices, Device 1 and Device 2, registered to a common M2M Gateway.
Device 1 often interacts with M2M Devices that it has not encountered before, and so it frequently encounters situations
where the Originator of the request cannot have been configured into the resources resident on
Device 1. In this case, Device 1 has not encountered Device 2 previously, and so Device 1 requests the M2M Gateway
to make an access control decision on behalf of Device 1. The relevant access control policies for Device 1 are not
present on the M2M Gateway, so the M2M Gateway requests the relevant access control policies from M2M Server 1.
When the M2M Gateway receives the access control policies, it realizes that it needs additional information about
Device 2, so the M2M Gateway requests the relevant information from M2M Server 2. The M2M Gateway makes the
access control decision and returns the decision result to Device 1. Figure 6.2.1.1-1 illustrates this process, which can be
seen to map onto figure 5.1-1 "Overview of the authorization architecture".

Figure 6.2.1.1-1: Use case scenario where an M2M Gateway makes
authorization decisions on behalf of an M2M Device
Table 6.2.1.1-1 provides the mapping from the actors in the present use case scenario to functions in figure 5.1-1. Each
authorization component (PEP, PDP, PRP and PIP) is on a distinct entity in this scenario. This motivates defining
mechanisms for using oneM2M primitives enabling the following:
• a PEP entity requesting an access control decision from a distinct PDP entity;
• a PDP entity requesting relevant access control policies from a distinct PRP entity; and
• a PDP entity requesting relevant access control information from a distinct PIP entity.
ETSI
oneM2M TR-0016 version 2.0.0 11 ETSI TR 118 516 V2.0.0 (2016-09)
Table 6.2.1.1-1: Mapping from actors in the use case scenario to the functions in figure 5.1-1
Actor Function in figure 5.1-1
Device 1 Policy Enforcement Point (PEP)
Device 2 Access Requestor
M2M Gateway Policy Decision Point (PDP)
M2M Server 1 Policy Retrieval Point (PRP)
M2M Server 2 Policy Information Point (PIP)

6.2.2 Proposal 1: Using resource-based approach to implement
distributed authorization
6.2.2.1 Introduction
According to the description in clause 8 of ETSI TS 118 101 [i.1], the general flow that governs the information
exchange within a procedure is based on the use of Request and Response messages. The message applies to
communications between an AE and a CSE which should cross the Mca reference point and among CSEs which should
cross the Mcc reference point. Requests over the Mca and Mcc reference points, from an Originator to a Receiver
should address the target resource or target attribute for the operation.
In the distributed authorization system the PEP, PDP, PRP and PIP might be located in different CSEs, so the
communication between PEP, PDP, PRP and PIP should cross the Mcc reference point. The method of message
exchange among these authorization components should conform to the ETSI TS 118 101 [i.1], i.e. the request message
sent from one authoriztion component in one CSE to another authorization component in another CSE should address a
resource.
According to the description in clause 9.2.2 of ETSI TS 118 101 [i.1], a virtual resource or a virtual attribute does not
have a permanent representation in a CSE, they are used to trigger processing and/or retrieve results. So we can use
virtual resources to exchange authorization messages among different CSEs, and at the same time, trigger a
corresponding authorization process.
This clause describes a solution for distributed authorization using a newly defined resource and its
child resources over the Mcc and Mcc' reference points. The child resources of the resource are
, and . These child resources are virtual

resources that are used to trigger PDP process, PRP process and PIP process defined in ETSI TS 118 103 [i.2]
respectively.
This clause also describes the management procedures for the resource and its child resources.
6.2.2.2 Resources
6.2.2.2.1 Resource type authorization
The resource represents the method for providing authorization related services. The
resource contains three child resources, they are , and
. These child resources are virtual resources that provide authorization functions of PDP, PRP
and PIP defined in ETSI TS 118 103 [i.2] respectively. The resource should be located directly under
.
ETSI
oneM2M TR-0016 version 2.0.0 12 ETSI TR 118 516 V2.0.0 (2016-09)

Figure 6.2.2.2.1-1: Structure of resource
The resource should contain the child resources specified in table 6.2.2.2.1-1.
Table 6.2.2.2.1-1: Child resources of resource
Child Resources of
Child Resource Type Multiplicity Description
Child Resource Types
[variable] 1 See clause 6.2.2.2.2 none
[variable] 1 See clause 6.2.2.2.3 none
[variable] 1 See clause 6.2.2.2.4 none

The resource should contain the attributes specified in table 6.2.2.2.1-2.
Table 6.2.2.2.1-2: Attributes of resource
RW/
Attributes of
Multiplicity RO/ Description

WO
resourceType 1 RO See clause 9.6.1.3 of ETSI TS 118 101 [i.1] where this
common attribute is described
resourceID 1 RO See clause 9.6.1.3 of ETSI TS 118 101 [i.1] where this
common attribute is described.
resourceName
1 WO See clause 9.6.1.3 of ETSI TS 118 101 [i.1] where this
common attribute is described.
parentID 1 RO See clause 9.6.1.3 of ETSI TS 118 101 [i.1] where this
common attribute is described.
authorizationPolicyIDs 1 (L) RW See clause 9.6.1.3 of ETSI TS 118 101 [i.1] where this
common attribute is described
creationTime 1 RO See clause 9.6.1.3 of ETSI TS 118 101 [i.1] where this
common attribute is described
expirationTime 1 RW See clause 9.6.1.3 of ETSI TS 118 101 [i.1] where this
common attribute is described
lastModifiedTime 1 RO See clause 9.6.1.3 of ETSI TS 118 101 [i.1] where this
common attribute is described
labels 0.1 (L) RW See clause 9.6.1.3 of ETSI TS 118 101 [i.1] where this
common attribute is described
ETSI
oneM2M TR-0016 version 2.0.0 13 ETSI TR 118 516 V2.0.0 (2016-09)
6.2.2.2.2 Resource type policyDecisionPoint
The resource is a virtual resource because it does not have a representation. It is the child
resource of the resource. When a RETRIEVE Request addresses the resource, a
PDP process is triggered. The access control decision request should be included in the Content parameter of the
RETRIEVE Request, and the access control decision response should be included in the Content parameter of the
RETRIEVE Response.
The resource inherits access control policies that apply to the parent resource.
6.2.2.2.3 Resource type policyRetrievalPoint
The resource is a virtual resource because it does not have a representation. It is the child
resource of the resource. When a RETRIEVE Request addresses the resource,
a PRP process is triggered. The access control policy request should be included in the Content parameter of the
RETRIEVE Request, and the access control policy response should be included in the Content parameter of the
RETRIEVE Response.
The resource inherits access control policies that apply to the parent resource.
6.2.2.2.4 Resource type policyInformationPoint
The resource is a virtual resource because it does not have a representation. It is the child
resource of the resource. When a RETRIEVE Request addresses the
resource, a PIP process is triggered. The access control attribute request should be included in the Content parameter of
the RETRIEVE Request, and the access control attribute response should be included in the Content parameter of the
RETRIEVE Response.
The resource inherits access control policies that apply to the parent
resource.
6.2.2.3 Procedures
6.2.2.3.1 Introduction
This clause describes the management procedures for the resource and its virtual child resources. These
virtual child resources are , and that are used
to trigger a PDP process, a PRP process and a PIP process defined in ETSI TS 118 103 [i.2] respectively. Only Retrieve
operation should be allowed on these virtual resources.
6.2.2.3.2 Create
This procedure should be used to create a resource.
ETSI
oneM2M TR-0016 version 2.0.0 14 ETSI TR 118 516 V2.0.0 (2016-09)
Table 6.2.2.3.2-1: CREATE
CREATE
Associated Reference Mcc and Mcc'.
Point
Information in Request All parameters defined in table 8.1.2-2 of ETSI TS 118 101 [i.1] apply with the specific
message details for:
To: the address of the where the resource is intended to
be Created.
Content: attributes of the resource as defined in clause 6.2.2.2.1-2.
Processing at Originator According to clause 10.1.1.1 of ETSI TS 118 101 [i.1].
before sending Request
Processing at Receiver According to clause 10.1.1.1 of ETSI TS 118 101 [i.1] with the following additions:
• Upon successful validation of the provided attributes, the Hosting CSE
creates the resource including its virtual child resources
specified in table 6.2.2.2.1-1.
• If there is a PDP process should be bound to the
virtual resource, then bind it to the virtual resource,
otherwise leave the binding void. The PDP process and the binding method
are out of scope.
• If there is a PRP process should be bound to the
virtual resource, then bind it to the virtual resource,
otherwise leave the binding void. The PRP process and the binding method
are out of scope.
• If there is a PIP process should be bound to the
virtual resource, then bind it to the virtual resource,
otherwise leave the binding void. The PIP process and the binding method
are out of scope.
Information in Response According to clause 10.1.1.1 of ETSI TS 118 101 [i.1].
message
Processing at Originator According to clause 10.1.1.1 of ETSI TS 118 101 [i.1].
after receiving
Response
Exceptions According to clause 10.1.1.1 of ETSI TS 118 101 [i.1].

6.2.2.3.3 Retrieve
This procedure should be used to retrieve the attributes of a resource.
Table 6.2.2.3.3-1: RETRIEVE
RETRIEVE
Associated Reference Mcc and Mcc'
Points
Information in Request According to clause 10.1.2 of ETSI TS 118 101 [i.1]
message
Processing at Originator According to clause 10.1.2 of ETSI TS 118 101 [i.1]
before sending Request
Processing at Receiver According to clause 10.1.2 of ETSI TS 118 101 [i.1]
Information in Response According to clause 10.1.2 of ETSI TS 118 101 [i.1]
message
Processing at Originator According to clause 10.1.2 of ETSI TS 118 101 [i.1]
after receiving
Response
Exceptions According to clause 10.1.2 of ETSI TS 118 101 [i.1]

6.2.2.3.4 Update
This procedure should be used to update the attributes of a resource.
ETSI
oneM2M TR-0016 version 2.0.0 15 ETSI TR 118 516 V2.0.0 (2016-09)
Table 6.2.2.3.4-1: UPDATE
UPDATE
Associated Reference Mcc and Mcc'
Points
Information in Request According to clause 10.1.3 of ETSI TS 118 101 [i.1]
message
Processing at Originator According to clause 10.1.3 of ETSI TS 118 101 [i.1]
before sending Request
Processing at Receiver According to clause 10.1.3 of ETSI TS 118 101 [i.1]
Information in Response According to clause 10.1.3 of ETSI TS 118 101 [i.1]
message
Processing at Originator According to clause 10.1.3 of ETSI TS 118 101 [i.1]
after receiving
Response
Exceptions According to clause 10.1.3 of ETSI TS 118 101 [i.1]

6.2.2.3.5 Delete
This procedure should be used to delete a resource.
Table 6.2.2.3.5-1: DELETE
DELETE
Associated Reference Mcc and Mcc'
Points
Information in Request According to clause 10.1.4 of ETSI TS 118 101 [i.1]
message
Processing at Originator According to clause 10.1.4 of ETSI TS 118 101 [i.1]
before sending Request
Processing at Receiver According to clause 10.1.4 of ETSI TS 118 101 [i.1]
Information in Response According to clause 10.1.4 of ETSI TS 118 101 [i.1]
message
Processing at Originator According to clause 10.1.4 of ETSI TS 118 101 [i.1]
after receiving
Response
Exceptions According to clause 10.1.4 of ETSI TS 118 101 [i.1]

6.2.2.3.6 Retrieve
This procedure is used to trigger a PDP process that is bound to a virtual resource.
Originator: The Originator should request to obtain an access control decision by using RETRIEVE operation on a
virtual resource from the Receiver. The Originator is a CSE.
Receiver: The Receiver should check if the Originator has RETRIEVE permission on the
virtual resource. Upon successful validation, the Receiver should make an access control decision based on access
control policies. If there is no process bound to the virtual resource, the Receiver should respond
with an error.
ETSI
oneM2M TR-0016 version 2.0.0 16 ETSI TR 118 516 V2.0.0 (2016-09)
Table 6.2.2.3.6-1: RETRIEVE
RETRIEVE
Associated Reference Mcc and Mcc'.
Points
Information in Request According to clause 10.1.2 of ETSI TS 118 101 [i.1] with the following additions:
message To: The address of the virtual resource.
Content: The representation of the access control decision request.
Processing at Originator The Originator should create an access control decision request according to an
before sending Request access request.
The Originator should request to obtain an access control decision by using the
RETRIEVE operation on a virtual resource which is the child
resource of a resource of the Receiver. The access control decision
request should be included in the Content parameter of the Request message. The
Originator should be a CSE.
Processing at Receiver The Receiver should perform the following operations:
• Check if the Originator has RETRIEVE permission on the
virtual resource.
• Check the validity of the provided parameters.
• Check if the virtual resource is bound to a PDP
process.
• Upon successful validation, passing the access control decision request to
the PDP process.
• The PDP process contact a PRP to obtain applicable access control policies,
and may also contact a PIP to obtain some access control attributes, and
then make an access control decision.
• The Receiver should create an access control decision response according
to the access control decision and respond to the Originator. The access
control decision response should be included in the Content parameter of the
Response message.
Information in Response According to clause 10.1.2 of ETSI TS 118 101 [i.1] with the following additions:
Content: The representation of the access control decision response.
message
Processing at Originator The Originator should enforce the access control decision, i.e. either permit or deny the
after receiving access to resource.
Response
Exceptions According to clause 10.1.2 of ETSI TS 118 101 [i.1] with the following:
• There is no PDP process bound to the virtual resource
• The provided content of the access control decision request is not in line with
the specified structure
6.2.2.3.7 Retrieve
This procedure is used to trigger a PRP process that is bound to a virtual resource.
Originator: The Originator should request to obtain access control policies by u
...