Access Control Mechanism for User Group Name: SEC WG Source: Seongyoon Kim, LG Electronics, Meeting Date: 2013-12-9 Agenda Item:

Slides:

Advertisements

Similar presentations

Access Control Mechanism Discussion

Advertisements

Call for test suites Group Name: REQ Source: Jiaxin Yin, Huawei Technologies Co., Ltd., Meeting Date: Agenda Item: TBD.

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.

Problem of non-Blocking Synchronous mode Group Name: ARC WG Source: Yuan Tao, Mitch Tseng, Huawei Technologies Meeting Date: ARC 15.0 Agenda Item: TBD.

OneM2M portal introduction Group Name: Technical Plenary Source: Gerry McAuley, ETSI, Meeting Date: Agenda Item: 1.5.

Method of Converting Resource definitions into XSD Group Name: WG3 (PRO) Source: Shingo Fujimoto, FUJITSU, Meeting Date:

Mechanism to support establishment of charging policies Group Name: WG2-ARC Source: InterDigital Meeting Date: TP8 Agenda Item:

2-levels Access control for HTTP binding Group Name: WG4 (& WG2/WG3 for information) Source: Shingo Fujimoto, FUJITSU, Meeting.

App-ID Use Cases, Syntax and Attributes SEC App-ID_Use_Cases,_Syntax_and_Attributes Group Name: Architecture Source: Darold Hemphill, iconectiv,

Framework for Performance Metric Development draft-morton-perf-metrics-framework-01.txt Alan Clark IETF 70 PMOL WG.

Proposal for OID-based M2M Node ID Group Name: WG2 Architecture at TP#8 (Miyazaki, December 2013) Source: Yong-Suk Park, KETI, Meeting.

In-Band Access Control Framework Group Name: WG4 SEC Source: Qualcomm Meeting Date: Agenda Item:

3GPP Rel-13 Interworking discussions

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.

An operator’s perspective on support for different M2M deployment scenarios AT&T Group Name: TP Source: Farooq Bari, Jianrong Wang; AT&T;

TS0001 Identifiers way forward Group Name: WG2 Source: Elloumi, Foti, Scarrone, Lu (tbc), Jeong (tbc) Meeting Date: Agenda Item: ARC11/PRO11.

Discussion on the problem of non- Blocking Synchronous mode Group Name: ARC WG Source: Yuan Tao, Mitch Tseng, Huawei Technologies Meeting Date: ARC 15.2.

App-ID Discussion Group Name: ARC WG Source: Seongyoon Kim, LG Electronics, Meeting Date: 31 July 2014 Agenda Item: TBD.

Response Status Codes Concepts for oneM2M Group Name: WG3 Source: Philip Jacobs, Cisco, Meeting Date: Agenda Item: TS-0004.

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:

Discussion on the problem of non- Blocking Synchronous mode Group Name: ARC WG Source: Yuan Tao, Mitch Tseng, Huawei Technologies Meeting Date: ARC 15.2.

Access Control Status Report Group Name: ARC/SEC Source: Dragan Vujcic, Oberthur Technologies, Meeting Date: 09/12/2013 Agenda Item:

Status Report on Access TP8 Group Name: WG2 Decision  Meeting Date: Discussion  Source: OBERTHUR Technologies Information  Contact:

Node-Specific Resource Group Name: ARC&MAS Source: LGE, Meeting Date: Agenda Item: Contribution.

Technical questions on oneM2M certification Group Name: TST Source: JaeSeung Song KETI, TST WG Chair Meeting Date: Agenda.

App-ID Use Cases, Syntax and Attributes ARC R01-App-ID_Use_Cases,_Syntax_and_Attributes Group Name: Architecture Source: Darold Hemphill, iconectiv,

Introducing WI Proposal about Authorization Architecture and Policy Group Name: WG4 Source: Wei Zhou, Datang, Meeting Date: Agenda Item:

Introducing WI Proposal about Authorization Architecture and Policy Group Name: WG4 Source: Wei Zhou, Datang, Meeting Date: Agenda Item:

Access Control Status Report Group Name: ARC/SEC Source: Dragan Vujcic, Oberthur Technologies, Meeting Date: 09/12/2013 Agenda Item:

OIC INTERWORKING OPERATIONAL PROCEDURE (ADDRESSING AND DISCOVERY) Group Name: Architecture WG Source: Kiran Vedula, Samsung Electronics,

Routing Problem of the Current Architecture Group Name: ARC Source: Hongbeom Ahn, LG Electronics, Meeting Date: Agenda.

ARC ordinary F2F meeting Seoul, June 2013 WG2 MEETING NOTES.

M2M Service Subscription Profile Discussion Group Name: oneM2M TP #19.2 Source: LG Electronics Meeting Date: Agenda Item:

SE abstraction scenarios Group Name: SEC Source: Claus Dietze, Giesecke & Devrient Meeting Date: Agenda Item: WI SE abstraction.

ARC R02 Modelling operations – problem statement and proposal Group Name: ARC#19.3 Source: Joerg Swetina, NEC,

App and Management End- to-End Security Requirements Group Name: SEC WG4 Source: Phil Hawkes, Qualcomm,

Introducing Event handler Group Name: SEC & ARC Source: FUJITSU Meeting Date: Agenda Item: Device Configuration.

Discussion about RESTful Admin API Group Name: SEC & ARC Source: FUJITSU Meeting Date: Agenda Item: Device Configuration.

OIC INTERWORKING Resource mapping

Security API discussion Group Name: SEC Source: Shingo Fujimoto, FUJITSU Meeting Date: Agenda Item: Security API.

M2M Service Layer – DM Server Security Group Name: OMA-BBF-oneM2M Adhoc Source: Timothy Carey, Meeting Date:

SEC #11 WG4 Status & Release 1 Outlook Group Name: Source:,, Meeting Date: Agenda Item:

Attribute-level access control Group Name: ARC WG Source: Yuan Tao, Mitch Tseng, Huawei Technologies Meeting Date: ARC 16 Agenda Item: TBD.

Clarification of Access Control Mechanism on Rel-1 & Rel-2 Group Name: SEC ( ARC & PRO for information) Source: FUJITSU Meeting Date: Agenda.

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,

Authorization Architecture Discussion Group Name: SEC WG Source: Seongyoon Kim, LG Electronics, Meeting Date: 28 MAY, 2014 Agenda.

Draft way Forward on Access Control Model and associated Terminology Group Name: SEC Source: Dragan Vujcic, Oberthur Technologies,

SEC#2 Election Process Group Name: SEC WG 4 Source: Victoria Gray, ETSI, Meeting Date: Agenda Item:

Consideration Security Issues on Registration Group Name: WG4 (SEC) Source: Shingo Fujimoto, FUJITSU, Meeting Date:

Reasons for CSF Clean-up (Issues & Next Steps) Group Name: WG2 Source: Syed Husain – NTT DOCOMO Meeting Date: (ARC_9.3) Agenda Item: 6 DOC#:

DM Collaboration – OMA & BBF: Deployment Scenarios Group Name: WG5 - MAS Source: Tim Carey, ALU, Meeting Date:

Management CSF(s) Architectural choices Group Name: WG2 (ARC), WG5(MAS) Source: Catalina Mladin, InterDigital Comm., Meeting.

TS-0004 guideline for new resource type definition Group Name: PRO WG Source: SeungMyeong JEONG, LG Electronics Meeting Date: Agenda Item: TS.

Specifying the Address of Management Client of Managed Entity Group Name: ARC Source: Hongbeom Ahn, SK Telecom, Meeting Date: TP#21 Agenda.

Service Framework Proposal

Group multicast fanOut Procedure

Discussion about Use Case and Architecture in Developer Guide

Proposed design principles for modelling interworked devices

MAF&MEF Interface Specification discussion of the next steps

3GPP Rel-13 Interworking discussions

3GPP Interworking Abstraction

Considering issues regarding handling token

Discussion on feature catalogue

Summary of Access Control Rules Processing

CMDH Refinement Contribution: oneM2M-ARC-0397R01

Service Layer Dynamic Authorization [SLDA]

Presentation transcript:

Access Control Mechanism for User Group Name: SEC WG Source: Seongyoon Kim, LG Electronics, Meeting Date: Agenda Item: TBD

Introduction There were some discussions on whether oneM2M needs to define authorization of user in previous calls The motivation of the contribution is to introduce access control mechanism for user without any changes/impacts on current resource/architecture if we need the authorization of user This contribution is – To propose not to include any user context into resource/architecture – To provide means to access control per User © 2013 oneM2M Partners 2

We need to separate User  AE domain and AE  CSE domain © 2013 oneM2M Partners 3 User interacts with Application (AE). AE interacts with Application Framework (CSE). User doesn’t interact with Application Framework Imagine there is an Andriod application (e.g., Amazon). User logs in Amazon but it doesn’t mean User logs in Google; Authentication/Authorization of User shall be done at Amazon with Amazon User ID and PW. Google only knows Amazon Application ID and Amazon Application behavior.  Service Provider of AE and CSE cannot be the same. We should not allow Application Framework to know any context of User. Separation of Domains

Access Control per User? (1) How could we provide access control per User? – Case 1: Access Control on AE © 2013 oneM2M Partners 4 Access Control is done at AE. oneM2M doesn’t need to specify anything

Access Control per User? (2) – Case 2: Access Control on CSE (Delegation to CSE) 1.Use Extended AE ID consisting of App-Inst-ID and Extended-ID, Assign/Keep unique Extended-ID per User 2.Authorization per AE © 2013 oneM2M Partners 5

Proposal If we would like to achieve Authorization for User, it’s better to have unique AE ID per User – CSE doesn’t need to know User information (User ID, token, etc.) – It works with current architecture without changing resource/adding entities – We can reuse current access control mechanism defined in ARC (i.e., accessRight Resource) © 2013 oneM2M Partners 6