OAuth option for mHealth Brief Profile Proposal for 2013/14 presented to the IT Infrastructure Planning Committee R Horn (Agfa Healthcare)

Patient Care Coordination Planning Committee Problem to be solved The mHealth profile does not specify any security profile options. This allows it to cover a very wide variety of use cases, but means that each installation and deployment must resolve the security and privacy controls in a local site specific manner. OAuth is a widely used authentication and authorization system for consumer and commercial users. The mHealth profile should have an authorization option. Current market factors make the OAuth framework a leading candidate to profile, with options selected to be appropriate for the mHealth use. The initial effort will examine other RESTful authorization alternatives, although none appear to have the level of acceptance of OAuth.

Patient Care Coordination Planning Committee External Requirements Continua Requirements – –We have consumer devices (e.g. tablet, smart phone …) running personal health applications with corresponding requirements. – –Focus on on-the-wire protocols and compliance. – –We need an easy/interoperable method for obtaining authorization tokens. – –Leverage RESTful approach for sending measurement observations across the WAN IF. – –Leverage RESTful approach for retrieving measurement observation across the WAN-IF. – –(non-technical – but equally important) Choice of protocols and technologies that motivate 3rd party independent software vendors (e.g. Apple App Store, Google Play) Enterprise Healthcare Requirements – –Hospitals need to provide authorization services for RESTful access from Hospital controlled medical devices BYOD devices Other enterprise devices

Patient Care Coordination Planning Committee External Requirements Government agencies – –ONC and others are prototyping RESTful authorization services. In the case of ONC, the OAuth 2.0 framework is being prototyped. Commercial Providers – –Various commercial providers have emerged and are requiring that authorization services not be tied to the healthcare provider. The preference is making authorization service selection a patient/user selection.

Patient Care Coordination Planning Committee Assumptions – –Authorization services will not be centralized, national, or unified. – –Authorization services will be not be healthcare provider selected. A patient will have their preferred authorization server, A healthcare provider will have to be able to support multiple authorization servers, and these servers will not be under the control of the healthcare provider. – –The selection of authorization services will be a matter for negotiation among patient, authorization services, and healthcare providers. – –Healthcare services will need to adapt commonly used authorization services – –RESTful services will require authorization – –Other options may evolve. (This is why this should be an option rather than part of the base profile.)

Patient Care Coordination Planning Committee Available Frameworks OAuth 2.0 is the dominant available framework – –OAuth 1.x has been successfully deployed for commercial uses with web browsers. – –OAuth 2.0 is a subsequent authorization framework that is designed to be profiled for specific uses, and to fix problems found with OAuth 1.x Other alternatives (these have not received much support outside of the enterprise environment) – –Kerberos tokens – –LDAP authentication – –HTTP password – –HTTP SAML – –Various proprietary systems

Patient Care Coordination Planning Committee Use Case (OAuth example) Client Authorization Server Service Provider OAuth Auth Request Unspecified other traffic OAuth Auth Response OAuth Service Ticket In HTTP headers Use Case 1 Use case 2 OAuth specifically avoids specifying other traffic and coordination traffic so that different authorization methods can be employed. For example, some authorization servers use tokens and others use password traffic as part of the request process

Patient Care Coordination Planning Committee Proposed Standards & Systems The proposal is toThe proposal is to Evaluate the alternatives, and profile an authorization method.Evaluate the alternatives, and profile an authorization method. Assuming OAuth V.20 from the IETF.Assuming OAuth V.20 from the IETF. –The OAuth framework expects to be profiled with specific information to meet use case specific needs. As a framework, it does not specify all of the requirements for implementation and deployment. –Benefit: The IHE profile can consolidate healthcare specific input to the IETF and OAuth implementers in a manner that they expect to be used.

Patient Care Coordination Planning Committee Discussion What level of effort do you foresee in developing this profile?What level of effort do you foresee in developing this profile? –Moderate work effort. Is there someone who is willing to act as profile editor?Is there someone who is willing to act as profile editor? –Rob Horn (Agfa), with Brad Generaux (Agfa)