Meeting Etiquette

1. Meeting Etiquette • Please announce your name each time prior to making comments or suggestions during the call • Remember: If you are not speaking keep your phone on mute • Do not put your phone on hold – if you need to take a call, hang up and dial in again when finished with your other call • Hold = Elevator Music = very frustrated speakers and participants • This meeting, like all of our meetings, is being recorded • Another reason to keep your phone on mute when not speaking! • Feel free to use the “Chat” or “Q&A” feature for questions or comments, especially if you have a bad phone connection or background noise in your environment From S&I Framework to Participants: Hi everyone: remember to keep your phone on mute  NOTE: This meeting is being recorded and will be posted on the Wiki page after the meeting

2. RESTful Health Exchange (RHEx)Security OverviewWebEx #3July 26, 2012 wiki.siframework.org/RHEx Powering Secure, Web-Based Health Data Exchange DRAFT—for discussion purposes only

3. Overview • RHEx and the Security Challenge • The problems RHEx aims to solve • RHEx and Document Linking – the Filing Cabinet analogy • The RHEx Access Model • The basic model • Extensibility • The underlying standards: OAuth and OpenID Connect • RHEx Support for Services • RHEx support for NIST Levels of Assurance • Summary

4. Orientation - What is RHEx? • An open source, exploratory project to apply proven web technologies to demonstrate a simple, secure, and standards-based health information exchange • Sponsored by the Federal Health Architecture (FHA) program • Called RESTful Health Exchange (RHEx) • A Fiscal Year 2012 project demonstrating RESTful health information exchange in two phases • Phase I: Security Approach (April-July 2012) • Phase II: Content Approach (July-September 2012) Powering Secure, Web-Based Health Data Exchange wiki.siframework.org/RHEx

5. What Are the Elements of RHEx Security? Who am I? How is that identity represented? How can I prove who I am? What can I do when I've proved who I am? Something you know Something you have Something unique to you IDENTITY IDENTIFIERS AUTHENTICATION AUTHORIZATION

6. What Are the Basic Problems RHEx is Exploring? • Data needs to be made available only to authorized parties • Data needs to be accessible to services via API calls and end users within a browser • Security protocols need to work with HTTP and REST • Security needs to be easy for application providers to deploy on their systems • Privacy is enforced by implementation of security controls • People need to be given notice about data access

7. RHEx Security Take-away Points • RHExapproachis secure • Uses same trusted tools used by high volume, secure systems to move money and exchange other sensitive information • Secure Transport: all transactions over Transport Layer Security protected HTTP • Exchanged tokens verified by trusted 3rd party • RHEx security is interoperable • Integrates with JSON, XML, HTML, etc. • Designed to support NIST Level of Assurance up to 3 (Identity Provider dependent) • Harmonizes with existing NwHIN standards • RHEx security is scalable • Documents contain separable links to information – each uniquely securable • Allows security and privacy to be applied atomically

8. RHEx as a RESTful Approach: Document Linking • Documents contain HTTP links to information • Clients (web browsers) fetch them separately • Arbitrary granularity with a well-designed API • Allows security and privacy to be applied atomically • Each request can be to a different security domain • Each request can have its own authentication parameters • Supports privacy and security practices of existing deployments • Availability of information can be hidden where appropriate • Presence of a URL in one document does not indicate presence of information at that URL • Knowledge of a URL does not automatically grant permission to view content at that URL

9. A RHEx Mental-Model: Filing Cabinets • Historically, paper health records were separated • Two physically distinct filing cabinets in different buildings held different parts of the records • Traditional Electronic Health Record (EHR) approaches make one giant filing cabinet • All records get pulled to a single digital filing cabinet and distributed from there • RHEx approach allows digital separation • Like having a file in one filing cabinet with a note stapled to it in the right place with the address of another filing cabinet • If you want what’s in the other filing cabinet, you have to go to that cabinet to get it • The other filing cabinet decides whether or not to let you in

10. Consider as a Model: The Paper-based System Primary Care Specialist In paper based systems, each organization keeps its records in its own filing cabinet

11. Traditional EHR Approach in This Model Data Gateway In a traditional EHR, everyone accesses data through the big digital filing cabinet in the sky, which has access to all member systems on your behalf.

12. The RHEx Approach in this Model URL link to record Primary Care Specialist With RHEx approach, each organization keeps its own cabinet, but records can contain pointers to files that live in someone else’s cabinet.

13. OpenID Connect Use in the RHEx Model Primary Care Specialist OpenID Connect allows a user to use their account on one system to log in to a remote system in a verified way, without relying on a shared central authority.

14. OAuth Use in the RHEx Model Primary Care Specialist OAuth allows the cabinets to be locked and controlled separately, but gives a way to issue limited-use keys to other parties.

15. The RHEx Access Model • Start with a simple beginning • Physical security works generally on a whitelist model: if you have a key, you can open the door • Whitelist individuals and providers to drive auditing, access control, and granular authorization • Extend the model • Employ User Attributes for trust decisions – extend the simple whitelist model and allow for expansion • Use Trust Frameworks to manage whitelist • Integrate existing standards • Implement basic model, data exchange in a Trust Framework, and accommodate extensibility using technologies that already exist, and which are extensively employed commercially • Provide support for end users and for services

16. RHEx Access ModelSimple Beginning • Whitelisting individuals • Individual identities tagged as cleared to view a piece of information • OpenID identifiers are like email addresses • Don’t have to be held in a common global repository • Contain both individual and organizational components • “drbob@pcp.com has access to record /patient1234/medications” • Whitelist identity providers • Accept identities from certain domains • “anybody from pcp.com can get basic patient information like name, height, and weight”

17. RHEx Access ModelExtend the Model • Attributes on users • Attributes of a user can help us make access decisions • Claimed attributes may be verified at a variety of identity or attribute providers • “anybody with the attribute isAnOncologist from a trusted attribute provider can get at oncology records” • Trust Frameworks • How can you be sure that what another system says is true? • Enforceable sets of business, legal, and technology rules • National Strategy for Trusted Identity in Cyberspace (NSTIC) bases trust relationships on these Trust Frameworks

18. RHEx Access ModelExtend the Model: Claims of User Attributes • All claims are extensible • JSON-based schema • Profile information • Name, email, phone • Distributed claims • URL to fetch more information • Follows RESTful linking model { user_id: “12341”, name: “John Doe”, email: “jdoe@pcp.com”, clinicalRole: “oncology”, oncology: “http://asco.org/userinfo/jdoe” }

19. RHEx Access ModelExtend the Model: Extending Claims for Health Care • RHEx will extend the user attributes and claims with domain-specific information • Claims need to be trustable • We don’t want this self-asserted • For example: Clinical role • Organization that we trust claims “Dr. Joe is an Oncologist” • Not all claims need to be held in a central store • Not all claims need to be held at the IdP • IdP points to attribute provider with a URL

20. RHEx Access ModelStandards in Action • OAuth2 • Token-based protocol for securing data APIs • Internet Engineering Task Force (IETF) Draft standard • OpenID Connect • Distributed identity API • Built on top of OAuth2 • OpenID Foundation • JSON Web Tokens • Structured, signed token format, used by OpenID Connect • HTTPS • All transactions over Transport Layer Security protected HTTP • Server certificates from trusted sources, no client certificates • Most successful pattern of use on the web today

21. RHEx Access ModelNascent Standards Built on Experience • OpenID and OAuth spec authors and core implementers have years of deployment experience with: • SAML • OpenID 2.0, 1.0 • OAuth 1.0 • PKI • Legacy protocols have shown limitations with use • New protocols are needed to work effectively in today’s RESTful, AJAXy, mobile-friendly world wide web • Take the best from all competitive technologies and apply it to a new world and new context • OpenID Connect is the sum of this experience so far

22. The good thing about reinventing the wheel is that you can get a round one. - Douglas Crockford

23. RHEx Access ModelStandards in Action: OAuth and OpenID In Use By Industry • Built by a consortium with a lot at stake • Trial by fire on the open internet

24. RHEx Access ModelServices Authorization • In addition to end user support, RHEx System must allow direct service connections (machine-to-machine) • Can’t count on user-held credentials being present • Will provide a module to authorize services to access data on behalf of a user • OAuth 2 Access Tokens can be issued for this case • Token inherits subset of permissions of user or service that authorized it • Tokens can be scoped to express least required access • Tokens can’t be replayed against other systems • Tokens are made to be easy to throw away • Unlike user’s credentials or certificates

25. RHEx and NIST Levels of Assurance (LoA) • Defined in National Institute of Standards & Technology (NIST) Special Publication 800-63 • LoA 1 – pseudonymity • Same person over course of transaction • Typical internet use case • OpenID Connect with dynamic registration • LoA 2 – identity proofing • Claims verified by a trusted source • OpenID Connect with whitelisted identity providers • All tokens signed by public key or shared secret • LoA 3 – multifactor remote protection • Recommended that client signs requests • OpenID Connect with signed Request Objects • Tokens signed and encrypted with public key

26. RHEx and LoA Inheritance from the IdP • Identity assurance starts at the IdP • Clients request a certain LoA from the IdP • LoA of transaction expressed inside of ID Token issued by IdP • Enforce identity proofing by contract or regulation • IdPs control who has accounts at the IdP • Enforce account proofing at login • Integrate with existing local website login systems • Can use passwords, certificates, hard tokens, single-sign-on • Authentication requirements limited to IdP • Note: Trust model can map to DIRECT’s Provider Network

27. RHEx Security Summary • RHEx is secure • Uses same trusted tools used by high volume, secure systems to move money and exchange other sensitive information • Secure Transport: all transactions over Transport Layer Security protected HTTP • Exchanged tokens verified by trusted 3rd party • RHEx security is interoperable • Integrates with JSON, XML, HTML, Bluebutton, etc. • Supports NIST Level of Assurance up to 3 (IdP dependent) • Harmonizes with existing NwHIN standards • RHEx security is scalable • Documents contain separable links to information – each uniquely securable • Allows security and privacy to be applied atomically

28. Questions & Follow-up • Questions? • For more information: http://wiki.siframework.org/RHEx • Discussion on the Google Groups forums • (https://groups.google.com/forum/?fromgroups#!forum/restfulhealthexchange)

29. Backups

30. OpenID Connect Family Tree OpenID 1.0 OAuth 1.0/a XRDS Hybrid WS* OpenID 2.0 ID-WSF WRAP XRD SAML AB AX PAPE OAuth 2 Facebook Connect SWD JWT/JOSE OpenID Connect

31. Security Terminology • Identity Provider (IdP) • Service that can assert the identity of a logged in user to a remote system • User Information • Set of attributes about a user in a system • Claim • Verifiable attribute about a component in the system • In our case, claims on users • Token • Disposable credential representing a subset of access and capabilities of an entity in the system

32. Basic OpenID Connect Flow (in RHExApproach) • RHEx site decides and configures which Identity Providers (IdPs) it wants to trust • User shows up at remote RHEx site, asks to log in using OpenID Connect at their Identity Provider (IdP) • User is redirected to their IdP • User logs in to their IdP (using local password, certificate, single-sign-on, etc) • User is issued a one-time-use code and redirect back to the RHEx site with that code • RHEx picks up that code and sends it to the IdP to get two tokens • ID Token contains claims about current session • Access Token can be used to get further information about the user, such as profile information

33. OpenID Connect Authentication User User would like to interact with a RHEx compliant system User shows up at remote RHEx site, asks to log in using OpenID Connect at their Identity Provider (IdP) User has registered with a recognized IdP A site employing RHEx decides and configures which Identity Providers (IdPs) it wants to trust IdP RHEx Site

34. OpenID Connect Authentication User User is redirected to their IdP User logs in to their IdP (using local password, certificate, single-sign-on, etc) ? IdP RHEx Site

35. OpenID Connect Authentication User User is issued a one-time-use code and redirect back to the RHEx site with that code + IdP RHEx Site

36. OpenID Connect Authentication User ID Token contains claims about current session RHEx picks up that code and sends it to the IdP to get two tokens Access Token can be used to get further information about the user, such as profile information + IdP = RHEx Site Now we can use the API as long as that token stays valid.

37. CheckID We can send the ID Token to the CheckID Endpoint to have the server validate it for us, so we don’t have to do client-side crypto. User = IdP RHEx Site

38. User Info We can send the Access Token over to the User Info endpoint to fetch claims about a user, and pointers to remote claims about that user. User = IdP RHEx Site