OAuth option for mHealthOAuth option for mHealth

Brief Profile Proposal for 2013/14Brief Profile Proposal for 2013/14presented to thepresented to the

IT Infrastructure Planning CommitteeIT Infrastructure Planning Committee

R Horn (Agfa Healthcare)R Horn (Agfa Healthcare)

Patient Care Coordination Planning CommitteePatient 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 CommitteePatient 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 CommitteePatient 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 CommitteePatient Care Coordination Planning Committee

Assumptions

• 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 CommitteePatient 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 CommitteePatient Care Coordination Planning Committee

Use Case (OAuth example)

Client

Authorization Server

Service Provider

OAuth Auth Request

Unspecified other traffic

OAuth Auth Response

OAuth Service TicketIn HTTP headers

Use C

ase 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 CommitteePatient Care Coordination Planning Committee

Proposed Standards & Systems

• The proposal is to The proposal is to • Evaluate the alternatives, and profile an authorization Evaluate the alternatives, and profile an authorization

method.method.• Assuming OAuth V.20 from the IETF.Assuming OAuth V.20 from the IETF.

– The OAuth framework expects to be profiled with specific The OAuth framework expects to be profiled with specific information to meet use case specific needs. As a framework, it information to meet use case specific needs. As a framework, it does not specify all of the requirements for implementation and does not specify all of the requirements for implementation and deployment.deployment.

– Benefit: The IHE profile can consolidate healthcare specific input Benefit: The IHE profile can consolidate healthcare specific input to the IETF and OAuth implementers in a manner that they expect to the IETF and OAuth implementers in a manner that they expect to be used.to be used.

Patient Care Coordination Planning CommitteePatient Care Coordination Planning Committee

Discussion

• What level of effort do you foresee in developing this What level of effort do you foresee in developing this profile?profile?– Moderate work effort.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)Rob Horn (Agfa), with Brad Generaux (Agfa)