Adding Role to ACPs Group Name: SEC Source: OBERTHUR Technologies, Dragan Vujcic Meeting Date: Agenda Item: RBAC

Introduction oneM2M ACPs are ABAC oriented (who, what when) Group is in general collection of the entities IDs When the resource owner and the requester are unknown to each other (e.g. in decentralized and complex environments), access control based on ID is either ineffective or very expensive to maintain. In such case RBAC is recommended Role is in general collection of permissions (i.e. ACPs)

Options to combine Role & ACPs 1.Role in the Originator parameter type – Origins(role), Ops(1...n), Ctxts(1...n) → perm – A role is just one of originator parameter type – Drawback is the loss of administrative simplicity as more entities are added 2.Static Role (based on 2-tuple) – Origins(1...n), Ops(1...n) → Role → perm – A role is determined by the orgin. and ops. tuple – Retains a conventional RBAC administrative simplicity 3.Dynamic Role (based on 3 tuple) – Origins(1...n), Ops(1...n), Ctxts(1...n) → Role → perm – Contexts parameter such as time window or location (when not static ) are used to determine the role – Retains a conventional RBAC administrative simplicity, but changing role sets dynamically 4.Constrained Role – Origins(1...n), Ops(1...n) → Role → Ctxts(1...n) → perm – Contexte parameter used to constrain the Role and not to expand it – In options 2 and 3 all permissions are available depending on the active role(s) – Option 4 constrains the set of permissions available during a role’s session – Retains a conventional RBAC administrative simplicity

Role’s Session There is no notion of « session » in oneM2M The role parameter in the Request message may play the notion of session roles (TBD) USERS ROLES OPERA TIONS OBJECTS permissions (UA) User Assignment (PA) Permission Assignment Sess- ions user_sessionssession_roles