Assuring Identities in an Open Trust Framework

1. Assuring Identities in an Open Trust Framework Interoperability and Connectivity: Privacy, Security and Trust in Health Information Exchange - 5th Annual WHIT Congress – 11/10/2009The Identity Assurance Framework Kantara Initiative Pete Palmer Co-Chair - Kantara Healthcare Identity Assurance Work Group

2. Provider Disclaimer This presentation is the result of work developed by volunteers of the Electronic Authentication Partnership, the Liberty Alliance, and the Kantara Initiative and is not a work product of Surescripts.

3. Kantara Overview • Founded: April 20, 2009 • Trustees: AOL, BT, CA, Fidelity, Intel, Internet Society, Liberty Alliance, Neustar, Novell, NRI, NTT, Oracle, PayPal and Sun ( see: http://kantarainitiative.org/confluence/display/GI/Current+Members ) • Purpose: • To bridge and harmonize identity community efforts • To ensure secure online interactions • To enhance personal privacy • To assure interoperability between OpenID, Liberty, InfoCard and other identity management solutions.

4. Kantara Healthcare Work Group • Founded: August, 2009 • History: Was Liberty Alliance Health Care Work Group • Purposes: • Implement patient access to their medical information and health care providers system using open source solutions • Implement simplified health care worker identity management • Review/Endorse identity assurance framework to support health information exchanges (HIEs) and the US nationwide health information network (NHIN) • Review/endorse patient identification standards for on-line and card identifiers • Work with vendors to help foster interoperability • Current co-chairs: John Fraser, MEDNETWorld.com, Pete Palmer, Surescripts, and Rick Moore, eHealth Ohio. • Home Page: http://kantarainitiative.org/confluence/display/healthidassurance/Home • Full Charter is at: http://kantarainitiative.org/confluence/display/healthidassurance/Charter

5. Identity in the Physical World

6. Joe’s Fish Market.Com Tropical, Fresh Water, Shell Fish, Lobster,Frogs, Whales, Seals, Clams Today’s Collection of Identity Silos

7. What the User wants… • Simplified online experience • Get rid of the need for multiple user-ids and passwords • Fewer clicks • Protected personal information • Reduce my risk from fraud • Better product & service offerings • Web 2.0 and/or “smart phone” data service integration

8. There are Two Problem Areas • Technical Interoperability • Does the client application I'm using “talk” to the systems I want to use? (can I type in my PIN on my iPhone and have unfettered access to services without logging in again?) • Does the system that authenticates me (vouches for me) “talk” to the service provider systems I want to access? (can I login to my bank's site and use that to pay my taxes, book travel, and check my Gmail account?) • Operational Interoperability & Assurance • Do the commercial and government systems “trust” each others' systems, operating procedures, vetting practices, etc.? (i.e., understand & accept the distribution of liability when/if something goes wrong) We’ll focus today on the Operational Interoperability & Assurance Aspects

9. Identity Assurance Framework …so why the need for a common standard?

10. Separate Cards with Each Bank Linked Cards within Bank Networks Seamless Access Across all Networks Bank ATM Network B Bank ATM Network C Bank ATM Network A Bank ATM Network B Bank ATM Network C Bank ATM Network A .com .com .com .com .com .com .com .com .com .com .com .com .com .com .com .com .com .com Bank C ATM Card Bank B ATM Card Bank A ATM Card Bank B ATM Card Bank C ATM Card Bank A ATM Card .com .com .com .com .com .com .com .com .com Linkage of Trust Domains Individual Accounts with Many Web Sites Federated Accounts within Trust Domain ATM Historic Analogy

11. End user (subscriber) Credential Service Provider Relying Parties Federation Operator Assessor Federated Cloud:RP applications trusting Federations, who enroll & monitor CSP’s compliant w/FO policies, based on Assessor Assessments Authentication Technology Identity Ecosystem: Trust Government Applications, Services, Resources

12. Identity Assurance Framework • What is it? • Framework supporting mutual acceptance, validation and lifecycle maintenance across identity federations (i.e. systems that trust each other) • Started with EAP Trust Framework, UK tScheme and US e-Auth Federation Credential Assessment Framework as baseline • Harmonized, best-of-breed industry identity assurance standard • Identity credential policy • Business procedure and rule set • Baseline commercial terms • Guideline to foster inter-federation (i.e. inter-trust) on a global scale • It consists of 4 parts: • Assurance Levels • Service Assessment Criteria • Assurance Assessment Scheme and Certification Program • Business Rules/Deployment Guidelines

13. End user (subscriber) Credential Service Provider Relying Parties Accredited Assessors List Certified Federations List Federation Operator Assessor IAF enabled Inter-Federated Cloud:RP applications trusting [Certified Federations, who enroll & monitor] IAF compliant CSP’s, based on Accredited Assessor Assessments Authentication Technology IAF’s Initial Focus Identity Ecosystem: Trust after IAF Government Applications, Services, Resources

14. IAF Assurance Levels • Four Primary Levels of Assurance • Level 1 – Little or no confidence in asserted identity’s validity • Level 2 – Some confidence • Level 3 – Significant level of confidence • Level 4 – Very high level of confidence • CSPs are certified by Assessors to a specific Level(s)

15. Assurance Level Assessment Criteria – Credential Mgmt Assessment Criteria – Identity Proofing Assessment Criteria – Organization Example Registration to a news website Minimal Organizational criteria Minimal criteria - Self assertion PIN and Password 1 Change of address of record by beneficiary Moderate organizational criteria Moderate criteria - Attestation of Govt. ID Single factor; Prove control of token through authentication protocol 2 Access to an online brokerage account Stringent organizational criteria Stringent criteria – stronger attestation and verification of records Multi-factor auth; Cryptographic protocol; “soft”, “hard”, or “OTP” tokens 3 Dispensation of a controlled drug or $1mm bank wire Stringent organizational criteria More stringent criteria – stronger attestation and verification Multi-factor auth w/hard tokens only; crypto protocol w/keys bound to auth process 4 IAF Assurance Levels Illustrated Note: Assurance level criteria as posited by the OMB M-04-04 & NIST SP 800-63

16. Credential Service Provider Relying Parties Assurance Assessment Scheme & Certification Program • Oversight by Member Committee (ARB) • Assessor is Accredited based on application of demonstrated expertise • CSP service is Certified to LOA(s) based on IAF compliance • Technology is Certified to be Interoperable • User has safe, simple access to services

17. Family/ Friends Social Networks Financial Institutions Industry Employers Commercial Government People, Entities, Machines... The Result – Identity Ecosystem • Ubiquitous interoperability • Minimize or Eliminate “Token Necklace” • Customer Convenience • Consistent User Experience • Plain Language • Simplified On-boarding • Low-to-No Cost • Ease of Service Selection • Clear Risk & Liability 17

18. Goal: Health care simplified authentication Health Information Systems – Clinics, Hospitals, etc Health Information Exchange - HIE • Interoperability for • Patient Lookup • Clinical Document Exchange • Privacy and Security HIE Gateway EMR Hospitals HIE Gateway NHIN Gateway EMR Payors RLS HIE Gateway HIE Gateway PHR Patient Logins HIE Member Users Simplified Sign Ons: to Clinics, Google Health, MS HealthVault, etc, or via iPhone or similar smartphone apps Simplified Sign Ons Clinics Patients Healthcare Workers

19. More Information on IAF and the Assurance Certification Program http://kantarainitiative.org/confluence/display/certification/Identity+Assurance+Certification+Program Thank You! pete.palmer@surescripts.com

20. Using Identity Management in a Northern Minnesota Health Information Exchange Interoperability and Connectivity: Privacy, Security and Trust in Health Information Exchange ~ Presentation to the 5th Annual WHIT Congress ~ 11/10/2009 Kantara Initiative By: John Fraser Co-Chair - Kantara Healthcare Identity Assurance Work Group & CEO, MEDNETWorld.com john.fraser@mednetworld.com +1 (612) 435-7602

21. Identity in the HIE World

22. Joe’s Fish Market.Com Tropical, Fresh Water, Shell Fish, Lobster,Frogs, Whales, Seals, Clams Today’s Collection of Identity Silos

23. Problem – trusting providers accessing information in external clinics and hospitals Solution: • Require Kantara Assurance Level 3 authentication between clinics and hospitals • Require individual users to use Notary process to ensure ID verification • Require PKI credentials for access to all services in a federated identity mgt system providing Single Sign On services

24. Assurance Level 3 Level 1 – Little or no confidence in asserted identity’s validity Level 2 – Some confidence Level 3 – Significant level of confidence Level 4 – Very high level of confidence NOTE: California considering same Level 3 requirement policy

25. Assurance Level 3 Implementation in MN • Stringent organizational criteria • Organizations must join HIE first, sign agreement • Stringent criteria – stronger attestation and verification of records • Individuals must complete notary process • Lying to notary is criminal offense! • Multi-factor auth; Cryptographic protocol; “soft”, “hard”, or “OTP” tokens • Individuals issued Soft Tokens using x509v3 certificates

26. HIE-Bridge Functional Architecture Internet HIEBridge Member Users Grid Server Portal Identity Provider System Level 3 Assurance Federated Single Sign On Electronic Referral Service Record Locator / Patient Look Up Clinical Data Retrieval Service Clinical Data Exchange Interface Gateway Server Gateway Server Gateway Server Gateway Server NHIN Gateway EMR System EMR System EMR System EMR System Interface to HIEs, Other Trading Partners, NHIN

27. HIE-Bridge Technical Architecture HIEBridge Member Users HIEBridge Single Sign-On Portal Personal Health Record (PHR) NHIN Backbone Other RHIO/HIEs Patient Lookup (Phase One) Patient Clinical Info Retrieval Lookup (Phase Two) Community Security/ Privacy Officers Log Reviews Distributed HIE model with Federated Identity Management and interface to Minnesota Immunization Information Connection MIIC

28. HIE-Bridge Connectivity to SSA via NHIN HL7 Interfacing Federated Identity Management System MEDNET Gateway (VM) SSA Federal EHR Firewall Hospital SSA NHIN Gateway Firewall Hospital Record Locator Service (Grid Server) MEDNET NHIN Gateway CCD Interfacing SSA MEDNET Gateway (VM) Firewall EHR • MEDNET Gateway • Document Repository • Patient Index • Audit Repository • Consent Management System

29. HIE-Bridge NHIN Connectivity MN Health Information Exchange • NHIN Connectivity for • Patient Lookup • Clinical Document Exchange • Privacy and Security Hospitals Payors EMR EMR RLS PHR Clinics

30. HIE-Bridge Services Supported • Assurance Level 3 with PKI authentication required for: • Patient Lookup Service • Exchange of medical information • ePrescribing • Referral Service • Connectivity to State of Minnesota Services • Social Security Administration Connectivity • NHIN external connectivity to other HIEs • Plus Quality Reporting to Medicare for Stimulus $$$

31. Benefits for HIE-Bridge (or other HIEs) • Single sign on for users • Better security = better patient privacy • EHR-neutral approach; plug in everyone! • No central databases needed - scalable • Federated user information sharing • Federated medical information sharing directly between organizations using PKI authentication • NHIN national connectivity support

32. More Information: Thank You! john.fraser@mednetworld.com +1 (612) 435-7602 HIE-Bridge: www.hiebridge.org MEDNET: http://www.mednetworld.com Kantara: http://kantarainitiative.org/