justin richer the mitre corporation october 8, 2014 overview of oauth 2.0 and blue button + rest
TRANSCRIPT
Justin Richer
The MITRE Corporation
October 8, 2014
Overview of OAuth 2.0 and Blue Button + REST
“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
“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 +
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
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
Underlying protocols
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
The OAuth 2.0 process
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
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)
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
How does this relate?
Consent Management
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
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
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
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/
