1. Justin Richer The MITRE Corporation October 8, 2014 Overview of OAuth 2.0 and Blue Button + REST

2.  “Download my data” –Patient right of access  Digital files made available to patients through a portal  No real specification of formats –Could be human-readable text of PDF  Generally a one-off –Not live access to data The original Blue Button

3.  “Connect my data” –Provide machine-addressable APIs to data –Access to data over time  Multiple transport and access mechanisms –S/MIME (DIRECT) –REST  Common security models –Software knows what to expect Moving to Blue Button +

4.  Standard RESTful API –Subset of FHIR  OAuth 2.0 for access delegation  Service discovery and trust roots –BB+ Registry component  Dynamic and trusted client registration –Profiles for different classes of client software depending on what the client is capable of at runtime  Standardized scopes for resource access  Developed in the open on GitHub Blue Button + REST

6.  Technology has gone a little stale –FHIR has moved forward –OAuth 2.0 Dynamic Client registration has adopted and altered BB+ “trusted registration” model  No successful bilateral pilots to date –Lots of interest from the consumer application side, little from the EHR vendor side  Some aspects should be factored out of BB+  Doesn’t focus on discrete structured data Status of Blue Button + REST

7. Underlying protocols

8.  Rights delegation and authorization protocol –A resource owner uses an authorization server to authorize a client to access a protected resource on their behalf  Open standard –Anybody can implement and use –IETF RFC 6749, 6750  In wide use across the internet –Hundreds of thousands of APIs and growing daily OAuth 2.0

9. The OAuth 2.0 process

10.  Federated identity protocol built on top of OAuth 2.0 –Open standard –In use by several large and many small players  Single-sign-on at internet scale  Key technology for solving the “multiple portals” problem  Fundamental to several major NSTIC initiatives OpenID Connect

11.  Consent management application built on OAuth 2.0 and OpenID Connect –Draft open standard  Allows “Alice to Bob” sharing  More on this next time from Eve Maler User Managed Access (UMA)

12.  Core components –OAuth 2.0: authorization and delegation –OpenID Connect: authentication and identity federation –FHIR: data access and formats  Fit-for-use applications –RHEx: provider-to-provider sharing –Blue Button + REST: provider-to-patient access Building blocks of digital health

13. How does this relate? Consent Management

14.  Current notions and laws around “consent” are biased to paper processing –HIPAA: “Must be presented in writing and signed”  Misapplication and re-use of terminology –e.g.: We have a thing called “digital signatures” that must mean the same thing as “signed” above Consent management legacy

15.  Conscious action –Single point of decision –Opportunity to inform –Requires some amount of effort and intent  Verifiable audit trail –When a decision was made –Who made the decision –What context the decision was made in The spirit of the law

16.  Explicit decision point(s) –Resource owner granting access at the authorization endpoint –Client being granted a token at the token endpoint  End user is authenticated at decision point –Appropriate rights to make the authorization decision, such as strong binding to the underlying data  Stored in a central location –Authorization server can track and provide audit  Why are we not considering this to be a record of consent? OAuth authorization decisions

17.  Emerging standard for detailing consent and notice decisions  Could be made available as part of the authorization server’s function  API could be queryable and aggregatable Consent receipts http://opennotice.org/open-notice-with-a-consent-receipts/

18. jricher@mitre.org Thank you