Service Enabled AE (SAE)

Slides:



Advertisements
Similar presentations
Access Control Mechanism Discussion
Advertisements

CMDH Refinement Contribution: oneM2M-ARC-0397
SEC Clarification Group Name: WG4 (SEC-2014-xxxx) Decision  Meeting Date: Discussion  Source: OBERTHUR Technologies Information  Contact:
Problem of Current Notification Group Name: ARC WG Source: Heedong Choi, LG Electronics, Meeting Date: ARC 9.0 Agenda Item: TBD.
Group:WG3 (PRO) Source:Peter Niblett, IBM, Date: Agenda:PRO#14 TS-0004 Data Representation Proposal Discussion.
Group:WG3 (PRO) Source:Peter Niblett, IBM, Date: Agenda:PRO#14 TS-0004 Data Representation Proposal Discussion.
Discussion on Time Series Data Group Name: WG2 Source: Qi Yu, Mitch Tseng- Huawei Technologies, Co. LTD. Meeting Date: Work Item :WI-0033.
In-Band Access Control Framework Group Name: WG4 SEC Source: Qualcomm Meeting Date: Agenda Item:
Announcement Resources ARC Announcement_Issues Group Name: WG2 Source: Barbara Pareglio, NEC Meeting Date: Agenda Item: Input Contribution.
In-Band Access Control Framework Group Name: WG4 SEC Source: Qualcomm Meeting Date: Agenda Item:
Answer the Questions Regarding Pending Issues on Access Control Group Name: WG4 SEC Source: LG Electronics Meeting Date: Agenda Item: SEC#11.4.
Supporting Time Series Data Group Name: WG2 Source: Qi Yu, Mitch Tseng- Huawei Technologies, Co. LTD. Meeting Date: Work Item :WI-0033.
Management of CMDH Policies Group Name: WG5-MAS Source: Wolfgang Granzow, Qualcomm, Meeting Date: Agenda Item: Management.
Supporting long polling Group Name: ARC WG Source: SeungMyeong, LG Electronics, Meeting Date: x-xx Agenda Item: TBD.
AllJoyn-Interworking Discussion Group Name: TP WG2 ARC Source: Josef Blanz, Phil Hawkes, Qualcomm Inc., Meeting Date:
Customized Resource Types MAS Group Name: MAS + ARC + PRO WGs Source: Wolfgang Granzow, Qualcomm Inc., Meeting Date:
Status Report on Access TP8 Group Name: WG2 Decision  Meeting Date: Discussion  Source: OBERTHUR Technologies Information  Contact:
Interworking with an External Dynamic Authorization System Group Name: SEC WG Source: Qualcomm Inc., Wolfgang Granzow & Phil Hawkes Meeting Date: SEC#20.2,
OIC INTERWORKING OPERATIONAL PROCEDURE (ADDRESSING AND DISCOVERY) Group Name: Architecture WG Source: Kiran Vedula, Samsung Electronics,
LWM2M Interworking Group Name: Architecture
Different planes for the resource structure Group Name: WG5 – MAS and WG2 – ARC Source: Nicolas Damour, Sierra Wireless
E2EKey Resource Group Name: SEC WG Source: Qualcomm Inc., Wolfgang Granzow & Phil Hawkes Meeting Date: SEC#20.3, Agenda Item: End-to-End Security.
Different planes for the resource structure Group Name: WG5 – MAS and WG2 – ARC Source: Nicolas Damour, Sierra Wireless
M2M Service Subscription Profile Discussion Group Name: oneM2M TP #19.2 Source: LG Electronics Meeting Date: Agenda Item:
ARC R02 Modelling operations – problem statement and proposal Group Name: ARC#19.3 Source: Joerg Swetina, NEC,
PRO/ARC and TST/PRO joint sessions at TP20 Group Name: oneM2M TP20 Source: Peter Niblett, IBM Meeting Date:
App and Management End- to-End Security Requirements Group Name: SEC WG4 Source: Phil Hawkes, Qualcomm,
Protocol Issues related to Plugtest Group Name: TST Source: Wolfgang Granzow, Qualcomm Inc., Meeting Date: Agenda.
App End-to-End Security Requirements Group Name: SEC WG4 Source: Phil Hawkes, Qualcomm, Meeting Date:
M2M Service Layer – DM Server Security Group Name: OMA-BBF-oneM2M Adhoc Source: Timothy Carey, Meeting Date:
LWM2M Interworking Proxy Procedures ARC Considerations
M2M Service Session Management (SSM) CSF Group Name: WG2-ARC Source: IDCC, LGE, ZTE Meeting Date: TP8 Agenda Item:
Issues of Current Access Control Rule and New Proposal Introduction Group Name: ARC 21 Source: Wei Zhou, Datang, Meeting Date:
Adding Non-blocking Requests Contribution: oneM2M-ARC-0441R01R01 Source: Josef Blanz, Qualcomm UK, Meeting Date: ARC 7.0,
Draft way Forward on Access Control Model and associated Terminology Group Name: SEC Source: Dragan Vujcic, Oberthur Technologies,
CMDH and Policies Contribution: oneM2M-ARC-0603
Subscription and Notification Issue Group Name: WG2 Source: Qi Yu, Mitch Tseng- Huawei Technologies, Co. LTD. Meeting Date: ~23 Agenda Item:
Possible options of using DDS in oneM2M Group Name: ARC Source: KETI, Huawei, Hitachi, China Unicom Meeting Date: Agenda Item: DDS binding.
Specifying the Address of Management Client of Managed Entity Group Name: ARC Source: Hongbeom Ahn, SK Telecom, Meeting Date: TP#21 Agenda.
Interworking with an External Dynamic Authorization System Group Name: SEC WG Source: Qualcomm Inc., Wolfgang Granzow & Phil Hawkes Meeting Date: SEC#20.1,
Background Data Transfer
3GPP R13 Small Data Delivery
Resource subscription using DDS in oneM2M
[authenticationProfile] <mgmtObj> specialization
Service Framework Proposal
CSE Retargeting to AE, IPE, and NoDN Hosted Resources
CSE Retargeting to AE, IPE, and NoDN Hosted Resources
End-to-End Security for Primitives
Group multicast fanOut Procedure
2nd Interoperability testing issues
3GPP interworking in R3 Group Name: ARC
Possible options of using DDS in oneM2M
NIDD Discussion Points
Proposed design principles for modelling interworked devices
oneM2M Service Layer Protocol Version Handling
MAF&MEF Interface Specification discussion of the next steps
3GPP Rel-13 Interworking discussions
Proximal IoT Interworking solution discussion
TS-0004 Data Representation Proposal Discussion
oneM2M Versioning Next Steps
Discussion on feature catalogue
LWM2M Interworking with <mgmtObj> Resources
CMDH Refinement Contribution: oneM2M-ARC-0397R01
CMDH Policies Contribution: ARC-2014-xxxx
Service Layer Dynamic Authorization [SLDA]
3GPP V2X Interworking Potential Impact
3GPP Interworking and use of <schedule> resource
Summary of the MAF and MEF Interface Specification TS-0032
oneM2M interop 6 action point
Notification Target Discussion
Presentation transcript:

Service Enabled AE (SAE) Other suggested titles: “Benefits of oneM2M Standardization” Group Name: ARC WG Source: Dale Seed, Convida Wireless (Seed.Dale@ConvidaWireless.com) Josef Blanz, Qualcomm (jblanz@qti.qualcomm.com) Meeting Date: 2017-05-22 (ARC29)

Background At TP28 we had some good discussion (ARC-2017-0066R02) regarding the benefits of allowing an AE (and IPE) to host its own services. E.g. Allow an AE on a resource constrained IoT device (door lock) to host its own services (lock / unlock door) E.g. Allow an IPE on a IoT GW to host its own services for interworking NoDNs to a oneM2M system In the end, consensus was reached that doing so would address some shortcomings and limitations in the oneM2M architecture Two potential options were discussed: Allow AEs (and IPEs) to host their own services and corresponding resources Define a “minimal” CSE profile such that a CSE can realistically be hosted by a resource constrained IoT device  The following slides focus on the first option  Service Enabled AE (SAE)

Proposal Define some extensions to the Mca interface to allow AEs to host their own services Define a subset of existing resource types that can be hosted by an AE/IPE Define a simple & lightweight sub/not mechanism for AE/IPE hosted resources Define a simple & lightweight ACP mechanism for AE/IPE hosted resources Restrict addressing to only structured addressing for AE/IPE hosted resources Restrict communication to only blocking mode for AE/IPE hosted resources Define some extensions to CSE to allow it to re-target CRUD requests to AE/IPE hosted resources

Allowed AE/IPE Hosted Resource Types <container> <contentInstance> <flexContainer> <mgmtObj> <subscription> (Note - See separate slide)

Subscription / Notification We need a lightweight subscription mechanism for AE/IPE Option #1 – Define a new resource type <AESubscription> Justification - keep oneM2M specs cleaner and simpler to understand since <subscription> resource and procedures are pretty complex as-is. Also this could allow further streamlining of AE subscriptions without impacting CSE subscription functionality Option #2a - Profile / Restrict <subscription> functionality that can be used by AEs Option #2b - Define a resource inheritance model in oneM2M ARC E.g. Use an inheritance model to define a <subscriptionBase> with minimal functionality that is inherited by <subscription>. Use <subscriptionBase> for AEs and <subscription> by CSEs.  Proposal is to use Option 1 as defined below By default, AESubscription is a resource-level subscription and notification is triggered when any attribute in subscribed-to-resource is updated. Notification content contains only the modified attributes of the subscribed-to-resource subscribedToAttributes enables attribute-level subscription and notification is triggered when any attribute(s) specified in subscribedToAttributes is updated. Attributes of <subscription> Multiplicity RW/ RO/ WO resourceType 1 RO resourceID resourceName parentID expirationTime RW creationTime lastModifiedTime labels 0..1 (L) subscribedAttributes notificationURI 1 (L)

Access Controls Leverage existing oneM2M security association between an AE and its Registrar CSE. No changes proposed to security association procedure. Once oneM2M security association (e.g. D/TLS session) is established between an AE and Registrar CSE, AE will only allow its Registrar CSE to access its AE hosted resources. All others will be denied access by the AE AE will perform “Registrar CSE impersonation check” To enable this, Registrar CSE will configure From parameter with its CSE-ID in all requests it re-targets to an AE AE will verify the value in the From parameter of all requests it receives is the same CSE-ID as the one established during security association with its Registrar CSE In addition, Registrar CSE can host oneM2M ACPs for AE. Registrar CSE can use these ACPs to restrict access to AE hosted resources to only those Originators that have proper privileges assigned. AE does not need to be burdened with supporting <accessControlPolicy> resources and checks. Registrar CSE well positioned to do this on AE’s behalf.

Addressing Proposal - support only structured addressing scheme to keep things simple for AE hosted resources (i.e. structured AE-Relative addressing) E.g. lock/sub01

Registration Enhance existing AE registration procedure to allow an AE to configure its Registrar CSE with a list (i.e. directory) of its AE hosted resources Each entry in directory can contain info such as a path to an AE hosted resource, the type of resource, link to an ACP for the resource, whether ACP is applicable to child resources (DEEP) of this AE hosted resource or not (SHALLOW), etc This will enable Registrar CSE to service requests to discover AE hosted resources and the capability to re-target requests to AE hosted resources Registrar CSE can also assist with the authorization to access AE hosted resources default is only Registrar CSE has authorization to access AE hosted resources

CREATE To: MNCSEBase, Content: <AE> Registration ADN-AE MN-AE MN-CSE CREATE To: MNCSEBase, Content: <AE> AEHostedResources = {path=/lock, type=doorLock, acp=acp01, acpMode=DEEP} CREATED

Retargeting to an ADN-AE MN-CSE Retargeted Request CREATE To: MNCSEBase/frontDoor/lock, Content: <AESubscription> CREATE To: /lock, Content: <AESubscription> CREATED Retargeting CREATED UPDATE To: MNCSEBase/frontDoor AEHostedResources = {path=/lock, type=doorLock, acp=acp01, acpMode=DEEP; path=/lock/sub01, type=AESubscription} Alternatively, Registrar CSE can update AEHostedResources and add “lock/sub01” entry UPDATED

Retargeting to an ADN-AE MN-CSE UPDATE To: MNCSEBase/frontDoor/lock, Content: {state = LOCKED} Retargeted Request UPDATE To: /lock, Content: {state = LOCKED} Retargeting UPDATED UPDATED

Retargeting to an ADN-AE MN-CSE NOTIFY To: /MN-CSE/AE1, Content: {state = LOCKED,…} NOTIFY To: AE1, Content: {state = LOCKED,…} Retargeting OK OK

Communication Modes To simplify AE, recommendation is for AE to only support blocking request handling for requests it services for AE hosted resources

Next Steps? Reach some consensus on whether this approach of supporting AE hosted resources is acceptable