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

2. Background There are currently five (5) high level dynamic authorization architectures, all with advantages and disadvantages – 4x access token-based proposals Delegation of existing authority – not issuing new authority – 1x Dynamic ACP Update New conditions for authorizing &/or updating ACPs – Authors’ opinion Access Tokens & Dyn ACP Update are complementary: suit different scenarios Strict deadline for stage 2 details NOTE: when we talk about dynamic authorization, we really mean delegating authority to an CSE/AE? 2

3. 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.e.g Oauth, UMA) provides this functionality. Can always define a oneM2M-based Dyn Auth System in more detail in the future. B.Focus on (2) and (3). 3

4. Suggestion (2) Integrated with existing ACPs – Enhance ACPs to include rules which are compared against Authorized Delegations. – NOT alternative to ACPs. Align Token-based dyn auth and ACP-Update dyn auth – Token-Based  Client-Based Flow. – ACP Update  Server-Based Flow These two suggestions will have minimal impact on Architecture, and minimal work for us 4

5. 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 to one or more Originators on behalf of a Subject. Permitted Delegation Rule – (Optional) New parameters inside an access control rule. – A set of Regex matched against parameters of Authorized Delegation(s) and the request – When evaluating the access control rule, IF an Authorized Delegation matches a Permitted Delegation Rule, THEN behave as if Originator’s identifier was in accessControlOriginators. Further details in a few slides 5

6. Server-based Flow (ACP Update) 6

7. Client-based Flow (Token) 7

8. 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. 8

9. Summary of parameters 9 Parameter (JWT elements) Authorized Delegation Permitted Delegation Rule Matching rule Issuer (iss) AS FQDN [1]FQDN regex [1..n]Match one regex Subject (sub) AS-assigned Subject-ID [1] Subject-ID regex [0..n]Regex match. “anonymous” allowed Audience (aud) CSE-ID regex [0..n]Not presentHosting CSE-ID matches AuthzDlgn.aud Authorized Originators (azo) AE/CSE-ID regex [0..n] Orig.’s AE/CSE-ID matches both regexs Dyn Auth Roles (rol) Dyn Auth Role-ID [0..n] Dyn Auth Role-ID regex [0..n] At least one match between AuthzDlgn.rol matches PermDlgnRule.rol Access Token Usage (atu) Client-based only: “auto”, “required” Not present.See next slide azo, rol and atu would be new elements of JWT.

10. 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” The AuthzDlgn will be considered in subsequent requests only if they contain the access token. – “auto” The AuthzDlgn will be considered in all subsequent requests. 10

11. Other details 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 11