8.4 Resource Type <mefClientReg>_

8.4.1 Introduction

A <mefClientReg> resource shall represent a MEF Client enrolled with the MEF on behalf of an M2M Service Provider or M2M Trust Enabler. A <mefClientReg> resource shall be a child resource of the MEF's <MEFBase> resource.

Table 8.4.1-1: Data Type Definition of <mefClientReg>

Data Type ID	File Name	Note
mefClientReg	SEC-mefClientReg-v2_1_0.xsd

Table 8.4.1-2: Universal/Common Attributes of <mefClientReg> resource

Attribute Name	Request Optionality
	Create	Update
@resourceName	NP	NP
resourceType	NP	NP
resourceID	NP	NP
parentID	NP	NP
creationTime	NP	NP
labels	O	O
expirationTime	M	M
creator	NP	NP

Table 8.4.1-3: Resource Specific Attributes of <mefClientReg> resource

Attribute Name	Request Optionality		Data Type	Default Value and Constraints
	Create	Update
adminFQDN	M	NP	xs:anyURI	No default
assignedSymmKeyID	NP	NP	sec:credentialID	No default
sourceIDs	O	NP	list of m2m:ID	No default

Table 8.4.1-4: Child resources of <mefClientReg> resource

Child Resource Type	Child Resource Name	Multiplicity	Ref. to Resource Type Definition
<mefClientCmd>	"cmd"	1	Clause 7.7

8.4.2 <mefClientReg> resource specific procedures on CRUD operations

8.4.2.1 Create

This procedure is denoted MEF Client Registration in clause 8.3.5.2.3 of oneM2M TS-0003 [2]. The To parameter of the <mefClientReg> create request primitive includes the MEF-FQDN and the character "-" (dash) as a shorthand notation for the name of the <MEFBase> resource:

//{MEF-FQDN}/-/

EXAMPLE: //mef123.mefprovider.org/-/

The MEF-FQDN represents a globally unique identifier of a MEF (aka. MEF ID).

The From parameter of the <mefClientReg> create request primitive shall be left empty if the MEF client does not have a MEF Client ID assigned yet. If the MEF client interfaces with the MEF on behalf of the node (see clause 5.2.1), the Node-ID of the respective ADN, ASN, MN or IN shall serve as MEF Client ID.

Originator:

No change from the generic procedures in clause 7.2.2.1 of [3] with clarifications discussed in clauses 5.2.2 and 6.3, and with following differences:

In step Orig-6.0: "Process Response primitive", if the Originator used a symmetric key to authenticate to the MEF, and the <mefClientReg> resource in the response contained an assignedSymmKeyID then the originator shall use the assignedSymmKeyID to identify this symmetric key when it is subsequently used in authenticating to the MEF.

Receiver:

Same as the generic procedures in clause 7.2.2.2 of [3] with clarifications discussed in clauses 5.2.2 and 6.3, and with following differences:

The Receiver shall perform the following steps in order in the place of Recv-6.3: "Check authorization of the Originator":

1. The Receiver shall determine if the Originator is authorized to register with the administrating stakeholder (M2M SP or MTE) identified by fqdn attribute. The present document does not specify how the Receiver makes this determination:
   • a) If the Originator is not authorized, then the Receiver shall execute the following steps in order:
     • i) "Create an unsuccessful Response primitive" with the Response Status Code indicating "ACCESS_DENIED" error.
     • ii) "Send the Response primitive".
   • b) If the Originator is authorized, then the Receiver shall allow the request.

The Receiver shall perform the following steps in order as part of "Create the resource" (clause 7.3.3.5 of [3] ) during Step Recv-6.5: "Create/Update/Retrieve/Delete/Notify operation is performed":

1. If the Originator authenticated using symmetric key with a key identifier which does not use the Receiver's FQDN, then:
   • a) The Receiver shall assign a symmetric key identifier with the Receiver's FQDN and with relative part which is unique within the scope of symmetric key identifiers issued by the Receiver. The Receiver shall associate this symmetric key identifier with the symmetric key used for authenticating the Originator.
   • b) The Receiver shall set the assignedSymmKeyID attribute to be the Credential-ID formed from the assigned symmetric key identifier as specified in clause 10.4 of [2].
2. If the Originator authenticated using a symmetric key with a key identifier which does not use the Receiver's FQDN, or if the Originator authenticated using a certificate, then the Receiver shall not include an assignedSymmKeyID attribute in the created resource.
3. The Receiver shall assign the creator attribute to an AE-ID or CSE-ID or Node-ID on instructions from the administrating stakeholder. The present document does not specify any details of how the AE-ID or CSE-ID or Node-ID is determined.
4. The Receiver shall instantiate the <mefClientCmd> child resource.

8.4.2.2 Retrieve

This procedure is denoted MEF Client Configuration Retrieval in clause 8.3.5.2.4 of oneM2M TS-0003 [2]. This procedure is used to retrieve the <mefClientReg> resource.

Originator:

No change from the generic procedures in clause 7.2.2.1 of [3] with clarifications discussed in clauses 5.2.2 and 6.3.

Receiver:

Same as the generic procedures in clause 7.2.2.2 of [3] with clarifications discussed in clauses 5.2.2 and 6.3, performing the following steps in order in the place of Recv-6.3: "Check authorization of the Originator":

1. The Receiver shall determine if the Originator is authorized by checking if the Originator is the creator of the resource:
   • a) If the Originator is not authorized, then the Receiver shall execute the following steps in order:
     • i) "Create an unsuccessful Response primitive" with the Response Status Code indicating "ACCESS_DENIED" error.
     • ii) "Send the Response primitive".
   • b) If the Originator is authorized, then the Receiver shall allow the request.

8.4.2.3 Update

This procedure is denoted MEF Client Configuration Update in clause 8.3.5.2.5 of oneM2M TS-0003 [2]. This procedure is used to update attributes of the <mefClientReg> resource, such as e.g. labels, expiration time.

Originator:

The <mefClientReg> resource shall not be updated by a MEF client via API.

Receiver:

Same as the generic procedures in clause 7.2.2.2 of [3] with clarifications discussed in clauses 5.2.2 and 6.3, and with the following differences:

The Receiver shall perform the following step in the place of Recv-6.3: "Check authorization of the Originator":

1. The Receiver shall determine if the Originator is authorized by checking if the Originator is the creator of the resource:
   • a) If the Originator is not authorized, then the Receiver shall execute the following steps in order:
     • i) "Create an unsuccessful Response primitive" with the Response Status Code indicating "ACCESS_DENIED" error.
     • ii) "Send the Response primitive".
   • b) If the Originator is authorized, then the Receiver shall allow the request.

The Receiver shall perform the following step as part of "Update the resource" (clause 7.3.3.7 of [3] )" during Step Recv-6.5: "Create/Update/Retrieve/Delete/Notify operation is performed":

1. If the Originator was the Creator of the resource, then the Receiver shall perform steps 2 and 3 in clause 8.4.2.1.

8.4.2.4 Delete

This procedure is denoted MEF Client De-Registration in clause 8.3.5.2.6 of oneM2M TS-0003 [2]. This procedure enables the MEF client to delete its own <mefClientReg> resource on a MEF.

Originator:

No change from the generic procedures in clause 7.2.2.1 of [3] with clarifications discussed in clauses 5.2.2 and 6.3.

Receiver:

Same as the generic procedures in clause 7.2.2.2 of [3] with clarifications discussed in clauses 5.2.2 and 6.3, performing the following step in the place of Recv-6.3: "Check authorization of the Originator":

1. The Receiver shall determine if the Originator is authorized by checking if the Originator is the creator of the resource:
   • a) If the Originator is not authorized, then the Receiver shall execute the following steps in order:
     • i) "Create an unsuccessful Response primitive" with the Response Status Code indicating "ACCESS_DENIED" error.
     • ii) "Send the Response primitive".
   • b) If the Originator is authorized, then the Receiver shall allow the request.