0. 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

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

2. Overview RHEx and the Security Challenge The RHEx Access Model
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

3. 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

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

5. 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

6. RHEx Security Take-away Points
RHEx approach 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, 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

7. 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

8. 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

9. 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

10. 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.

11. 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.

12. OpenID Connect Use in the RHEx Model
OpenID provides a way for one user to log into another, remote system without having a username/password provisioned at that system, and without having a certificate from a central trusted authority.
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.

13. 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.

14. The RHEx Access Model Start with a simple beginning Extend the model
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

15. RHEx Access Model Simple Beginning
Whitelisting individuals
Individual identities tagged as cleared to view a piece of information
OpenID identifiers are like addresses
Don’t have to be held in a common global repository
Contain both individual and organizational components
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”

16. RHEx Access Model Extend 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

17. RHEx Access Model Extend the Model: Claims of User Attributes
All claims are extensible
JSON-based schema
Profile information
Name, , phone
Distributed claims
URL to fetch more information
Follows RESTful linking model {
user_id: “12341”,
name: “John Doe”,
clinicalRole: “oncology”,
oncology: “ }

18. RHEx Access Model Extend 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

19. RHEx Access Model Standards 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

20. RHEx Access Model Nascent 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

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

22. RHEx Access Model Standards 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

23. RHEx Access Model Services 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

24. RHEx and NIST Levels of Assurance (LoA)
Defined in National Institute of Standards & Technology (NIST) Special Publication
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

25. 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

26. RHEx Security Summary RHEx is secure RHEx security is interoperable
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

27. Questions & Follow-up Questions?
For more information:
Discussion on the Google Groups forums (

28. Backups

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

30. Security Terminology Identity Provider (IdP) User Information Claim
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

31. Basic OpenID Connect Flow (in RHEx Approach)
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

32. 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

33. 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

34. 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

35. 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.

36. = CheckID User IdP RHEx Site
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

37. = User Info User IdP RHEx Site
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