1. Interworking with an External Dynamic Authorization System Group Name: SEC WG Source: Qualcomm Inc., Wolfgang Granzow & Phil Hawkes Meeting Date: SEC#20.2, 2015-12-03 Agenda Item: Dynamic Authorization

2. Background There are currently five (5) high level dynamic authorization architectures, all with advantages and disadvantages – 4x client-based proposals (using access tokens) Delegation of existing authority – not issuing new authority – 1x server-based proposals (dynamically updating ACPs) New conditions for authorizing &/or updating ACPs Supports Hosting CSE decisions and delegation decisions made by back-end – Authors’ opinion Client-based and server-based dyn auth are complementary: suit different scenarios Strict deadline for stage 2 details R01 – minor changes to some slides. – New slides identified using in the top left corner 2 NEW

3. NOTE This proposal focusses on a approach where the Hosting CSE does not make decisions about dynamic authorization- the decisions are made elsewhere – e.g. At an Authorization Server This is not the only valid approach – IDCC proposal DAA4/SLDA supports the Hosting CSE making decisions – Such a system could work in parallel with our proposal, we are not opposed – In the author’s opinion, the present proposal minimizes standardization effect, and has most likelihood of making it into Rel 2. 3 NEW

4. Suggestion Multiple Aspects to Dynamic Authorization 1.How is a delegation authorized? Architecture: Entities, Messages, parameters Protocol level details: Defining Policies 2.What parameters are exchanged over oneM2M msgs? 3.How is an delegation used in an access control decision? Why don’t we A.Leave (1) completely out of scope. Assume that an external Dynamic Authorization System (e.g. OAuth, UMA) provides this functionality. Can always define a oneM2M-based Dyn Auth System in more detail (or profile an existing Dyn Auth System) at some time in the future. B.Focus on (2) and (3). 4

5. Suggestion (2) Integrated with existing ACPs – Enhance ACPs to include rules which are compared against Authorized Delegations. – NOT alternative to ACPs. Create a common framework providing Client- based and Server-based dyn auth – Decisions made at an Authorization server (Author’s opinion) This approach minimizes impact on – ARC WG work & changes to TS-0001 – SEC WG work & changes to TS-0003 5

6. Ext Dyn Authz System Actors Subject – Stakeholder (end-user, business, org) or entity whose authority can be delegated – Could also be dictating access control policy on the Host CSE – Not “Token Subject” of DAA3! Authorized Server – Trusted entity issuing data objects (on behalf of Subjects) describing authority delegated by the Subject. These data objects are called Authorized Delegations (more details in a couple of slides) Resource Server Agent – Functionality interacting with the Ext Dyn Authz System of behalf of Hosting CSE Resource Server Agent appears to the Ext Dyn Authz System as Resource Server, Difference to normal Ext Dyn Authz System: Hosting CSE hosts the resources Hosting CSE trusts the Resource Server Agent Client Agent (Token/Client-based dyn auth only) – Functionality interacting with the Ext Dyn Authz System of behalf of Originator Client Agent appears to the Ext Dyn Authz System as a Client Difference to normal Ext Dyn Authz System: Originator requests the resources. Originator trusts the Client Agent 6 NEW

7. Out of Scope & In Scope Interactions between Ext Dyn Authz System actors are out of scope We want to standardize – Parameters exchanged between oneM2M system and Ext Dyn Authz System Client Agent  Originator Resource Server Agent  Hosting CSE – (Client-Based dyn auth) Hosting CSE and Originator to forward data between Client Agent and Resource Server Agent Nature of the forwarded data is out of scope – Data object representing a delegation, processed by Hosting CSE – How delegation data object is used in access control decisions 7 NEW

8. Two new Data Objects Authorized Delegation (AuthzDlgn) – Outcome of the interaction with the Ext Dyn Authz System – Describes the authorization (in form of subject-managed roles) issued by an Authorization Server on behalf of a Subject (user, business, organization). Can optionally identify one or more Originators AuthzDlgn can include expiry. Permitted Delegation Rule (PermDlgnRule) – (Optional) New parameters inside an access control rule. – A set of values (including wild cards) matched against corresponding parameter values of Authorized Delegation(s) and the request – When evaluating the access control rule for a particular request: IF an Authorized Delegation matches a Permitted Delegation Rule, THEN behave as if Originator’s identifier was in accessControlOriginators. Further details on parameters in a few slides 8

9. Server-based Flow (ACP Update) 9 Advantage: No impact on Originator

10. Client-based Flow (Token) 10 Advantage: Works with OAuth-based Ext Dyn Authz Systems

11. Implementation and Deployment Options The Originator and Client Agent could be i.Integrated to a single component and indistinguishable. ii.Distinct components on a single device. iii.Implemented on distinct Nodes. We should try to support options i + ii. – Option iii requires defining messages exchanged between devices. Won’t get this in Rel 2, maybe in future releases? We should support scenarios where a single Client Agent acts on behalf of multiple Originators. For example: i.App presents itself as multiple AEs, and App contain a Client Agent which acts on behalf of all these AEs. ii.A single Client Agent on a Node could act on behalf of multiple Originators on the same Node. iii.A Client Agent on a MN could act on behalf of multiple Originators on the MNs, ASNs and ADNs registered to that MN. Similar comments apply for Hosting CSE and Resource Server Agent 11

12. Summary of parameters 12 Parameter (JWT elements) Authorized Delegation Permitted Delegation Rule Matching rule Issuer (iss) AS FQDN [1]FQDN [1..n] (wildcards allowed?) At least one match Subject (sub) AS-assigned Subject-ID [1] Subject-ID [0..n] (wildcards allowed?) At least one match “anonymous” allowed Audience (aud) CSE-ID regex*[0..n]Not presentHosting CSE-ID matches AuthzDlgn.aud Authorized Originators (azo**) AE/CSE-ID [0..n] (including wildcards?) AE/CSE-ID [0..n] (wildcards allowed?) Orig.’s AE/CSE-ID matches both AuthzDlgn.azo and PermDlgnRule.azo Dyn Authz Roles (rol**) Dyn Authz Role-ID [0..n] Dyn Authz Role-ID[0..n] (wildcards allowed?) At least one match between AuthzDlgn.rol matches PermDlgnRule.rol Access Token Usage (atu**) Client-based only: “auto”, “required” Not present.See next slide AuthDlgn IDAS assign AuthDlgn IDAuthDlgn ID [0..n] (wildcards allowed?) At least one match * The hosting CSE only checks this regex once (when AuthDlgn is received) ** azo, rol and atu would be new elements of JWT (JSON Web Token RFC 7519).

13. Access Token Usage parameter Message size is important. If can avoid resending access token, while still knowing that the Hosting CSE will still consider the Authorized Delegation, then that would be great! – Some scenarios require including access token in every request. Access Token Usage: – Assigned by Authz Server on behalf of Subject. – “required” means the Authorized Delegation will be considered in a subsequent requests only if that subsequent request contains either the access token or (in the case of a self-contained access token including the Authorized Delegation – which would be a very large access token) an identifier for the Authorized Delgation. – “auto” means the Authorized Delegation will be automatically considered in all subsequent requests – where or not the access token (or identifier) is included in the request. 13

14. Other optional parameters JWT elements include – nbf: Not Before – exp: Expiry – iat: Issued At These elements can be provided in Authorized Delegations Permitted Delegation Rules can include similar elements to limit the time window in which it applies These are compared against the time that the request is processed. 14