1. MAF&MEF Interface Specification discussion of the next steps
SEC
MAF&MEF Interface Specification discussion of the next steps
Group Name: SEC WG
Source: Qualcomm Inc., Phil Hawkes, Wolfgang Granzow
Meeting Date: SEC#26,
Agenda Item: WI-0057-TEF_interface

2. Objective At TP#24 the WI-0057 “TEF Interface” was agreed
From this WI, the stage-3 details of the interface between AEs and CSEs with M2M Authentication Function (MAF) and M2M Enrolment Function (MEF) shall result
Trust Enabling Function (TEF) is a generic term used for MAF and MEF
Discussion paper SEC R01 was presented at TP#25
3 reference architecture options were proposed:
separate reference points for MAF and MEF
single new reference point for TEF
define TEF as a new CSF, then MAF and MEF become CSEs and new reference point is not required, i.e. Mca/Mcc applies
No agreement on the way forward was achieved at TP#25

3. Proposal
Let‘s begin developing MAF and MEF interfaces separately, i.e. Mmef and Mmaf, and independent of Mca and Mcc
Even if MAF and MEF would be regarded as special types of CSEs, it would still make sense to use a distinct name for the reference points
We also use different names Mca and Mcc although the protocols used on these reference points are essentially identical
Alternatively we could use notation Ma and Me
There was discussion on using a one- or two-character index

4. Title of the new specification
When avoiding the term “TEF”, what should be the title of the new specification to be developed under WI-0057 “TEF Interface”?
New working title could be one of the following:
MAF and MEF Interface Specification (suggested here)
Credential Management Specification
Trust Enabling Architecture

5. Technical assumptions for MAF
The procedures already specified in TS-0003 assume that a MAF communicates with a MAF Client which is associated with a oneM2M entity (AE or CSE)
The MAF itself represents the server in this client-server model (we however do not use the term “MAF server“)
MAF
Mmaf
Mmaf
M2M
Entity A
M2M
Entity B
MAF
Client
MAF
Client

6. Use of MAF Interface as defined in TS-0003

7. Extension of present concept
MAF Clients could be associated with oneM2M (field) nodes (i.e. ASN, ADN, MN) rather than with AE or CSE entities
In this case a single MAF Client can act on behalf of all entities implemented on the node
We propose supporting both approaches
MAF
Mmaf
Mmaf
M2M Node
MAF
Client AE
CSE
Mcc
IN-CSE
MAF
Client

8. Resulting Reference Architecture

9. Definitions (to be included into the new spec)
MAF Client:
functionality for performing MAF procedures on behalf of an associated CSE or AE, or on behalf of CSE or AE(s) present on an associated Node.
Note: the existing definition in TS-0003 needs to be updated accordingly
MEF Client:
functionality for performing MEF procedures on behalf of an associated CSE or AE, or on behalf of CSE or AE(s) present on an associated Node.
MAF interface:
Communication interface between a MAF and a MAF Client identified by reference point Mmaf
MEF interface:
Communication interface between a MEF and a MEF Client identified by reference point Mmef

10. Proposed communication scheme on Mmaf
Reusing oneM2M RESTful protocol as applied on Mca and Mcc reference points
Reusing existing request and response primitives
many optional Mcc/Mca primitive parameters/features not required on Mmaf andMmef (not eliminating future extensions)
Blocking-mode access to server only (non-blocking may be defined in future release)

11. Request Primitive parameters
Data Type
Multiplicity
Presence on Mmaf
Notes
Operation
m2m:operation 1 M To
xs:anyURI
From
m2m:ID
0..1 O
AE-ID, CSE-ID, M2M-Node-ID or Device-ID, if available
Request Identifier
m2m:requestID
Resource Type
m2m:resourceType
resource types applicable to Mmaf or Mmef, tbd.
Content
m2m:primitiveContent
Role IDs
List of m2m:roleID NA
Originating Timestamp
m2m:timestamp
Request Expiration Timestamp
m2m:absRelTimestamp
Result Expiration Timestamp
Operation Execution Time
Response Type
m2m:responseTypeInfo
Default: Use 'blockingRequest'
Result Persistence
Result Content
m2m:resultContent
New enumeration values tbd
Event Category
m2m:eventCat
Delivery Aggregation
xs:boolean
Group Request Identifier
xs:string
Filter Criteria
m2m:filterCriteria
New filter criteria tbd.
Discovery Result Type
m2m:discResType
Tokens
List of m2m:dynAuthJWT
Token IDs
List of m2m:tokenID
LocalTokenIDs
List of xs:NCName
Token Request Indicator

12. Response Primitive parameters
Data Type
Multiplicity
Presence on Maf
Notes
Response Status Code
m2m:responseStatusCode 1 M
Possibly additional response status codes required tbd
Request Identifier
m2m:requestID
Content
m2m:primitiveContent
0..1 O To
m2m:ID NA
From
Originating Timestamp
m2m:timestamp
Result Expiration Timestamp
m2m:absRelTimestamp
Event Category
m2m:eventCat
Assigned Token Identifiers
m2m:dynAuthLocalTokenIdAssignments
Token Request Information
m2m:dynAuthTokenReqInfo

13. MAF Interface Stage 3 Details in the new spec
Use similar specification approach as currently applied for specification of Mcc/Mca stage 3 details:
Define request and response primitives with parameters applicable on Mmaf
Define new resource types hosted by the MAF, structure and data types as defined in TS-0004
Describe generic procedures at the MAF and MAF Client
Describe procedures specific to new resource types
Reuse bindings to application layer transport protocols
TS-0008/9/20 (HTTP/1.1, CoAP, WebSocket; MQTT not suitable)
Specify “delta” relative to TS-0008/9/20 (if there is any)

14. MAF and MEF Procedures defined in TS-0003
Remote Security Provisioning Frameworks (RSPF)
Clause 8.3 in TS-0003
Certificate Enrolment currently part of this functionality but only partly specified right now
MAF-based security frameworks
Clause 8.8 in TS-0003
Clause for MAF-based SAEF
Clause for MAF-based ESPrim
Currently no text for MAF-based ESData
Remote security frameworks for E2E security
Clause 8.6 in TS-0003
Referenced on Clause for ESData

15. Summary of proposed way forward
Start development of the new specification under the working title “MAF and MEF Interface Specification” at TP#26:
Proposed skeleton: SEC R01
Proposed scope: SEC R01
Proposed main body: SEC R01 (addressing MAF interface only)
Add parts which were dropped from SEC (short names) into the new specification (can be postponed to SEC#26.x telcos)
More details on procedures need to be added in TS-0003
Mapping between MAF/MEF procedures to CRUD procedures defined in the new MAF and MEF Interface Specification (i.e. follow-up on SEC )
Add definition of new reference points to TS-0001 when the new specification has become stable