O slideshow foi denunciado.
Utilizamos seu perfil e dados de atividades no LinkedIn para personalizar e exibir anúncios mais relevantes. Altere suas preferências de anúncios quando desejar.

Shaping the Future of Trusted Digital Identity

101 visualizações

Publicada em

May 2019 presentation by Noreen Whysel to the CARIN Technology Committee. Discusses the Identity Ecosystem Framework Registry (idefregistry.org) and proposed health data use cases for potential trusted identity API for healthcare.

Publicada em: Dados e análise
  • Entre para ver os comentários

  • Seja a primeira pessoa a gostar disto

Shaping the Future of Trusted Digital Identity

  1. 1. Shaping the Future of Trusted Digital Identity The IDEF Registry with Health Information Use Cases Kantara Initiative Educational Foundation 1
  2. 2. www.IDEFRegistry.org Background
  3. 3. “By making online transactions more trustworthy and better protecting privacy, we will prevent costly crime, we will give businesses and consumers new confidence, and we will foster growth and untold innovation.” — President Barack Obama, April 2011 National Strategy for Trusted Identities in Cyberspace 3
  4. 4. From NSTIC to IDESG • April 2011 – White House introduced the National Strategy for Trusted Identities in Cyberspace (NSTIC) to: o work collaboratively with the private sector, advocacy groups, public sector agencies and other organizations; o improve privacy, security and convenience of online transactions; and o create a “trusted” online environment because of agreed upon standards for obtaining and authenticating digital identities.
  5. 5. Guiding Principles • NSTIC established guiding principles for the creation of solutions for the Identity Ecosystem that are: o Privacy-enhancing and voluntary; o Secure and resilient; o Interoperable; and o Cost-effective and easy to use.
  6. 6. The IDESG • The NSTIC vests responsibility for the creation of policy and standards for the Identity Ecosystem in the private sector-led, Identity Ecosystem Steering Group (IDESG). • IDESG works closely with the National Institute of Standards NSTIC National Program Office, which manages the day-to-day activities of the NSTIC implementation. • The IDESG is now an independent, non-profit association continuing to drive standards for the Identity Ecosystem.
  7. 7. Building a Better Digital Ecosystem With The Identity Ecosystem Framework
  8. 8. What Is the IDEF? First rules of the road for navigating the evolving landscape of online identity Asserts capabilities and responsibilities for individuals, companies, government agencies and organizations in the identity ecosystem Creates policy foundation for strengthening privacy and security protections for organizations and consumers alike What is the IDEF? What does it do? Why is it necessary?
  9. 9. Three Components of the IDEF Baseline Requirements, Supplemental Guidance and Best Practices Establishes 8 interoperability, 15 privacy, 15 security and 7 usability guidelines Scoping Statement Defines scope of IDESG work to create a safe and trustworthy identity ecosystem Functional Model Depicts how IDEF guidelines apply to identity stakeholders
  10. 10. Scoping Statement • Defines the scope of IDESG work to create a safe and trustworthy identity ecosystem • Expressed in objective and testable statements suitable for 3rd party assessment • Extensive enough that specific communities can determine applicability of IDEF requirements based on individual needs
  11. 11. Baseline Requirements • Establishes a baseline of 8 operability, 15 privacy, 15 security and 7 usability requirements • Serves as the FAQs for the IDEF • Supplemental Guidance & Best Practices
  12. 12. Baseline Requirements INTEROPERABILITY • Third Party Authentication • Third Party Credentials • Standardized Credentials • Standardized Data Exchanges • Documented Processes • Third Party Compliance • User Redress • Accountability PRIVACY • Data Minimization • Purpose Limitation • Attribute Minimization • Credential Limitation • Data Aggregation Risk • Usage Notice • User Data Control • Third Party Limitations • User Notice of Changes • User Option to Decline • Optional Information • Anonymity • Controls Proportionate to Risks • Data Retention and Disposal • Attribute Segregation • Security Practices • Data Integrity • Credential Reproduction • Credential Production • Credential Issuance • Credential Uniqueness • Token Control • Multifactor Authentication • Authentication Risk Assessment • Uptime • Key Management • Recovery & Reissuance • Revocation • Security Logs • Security Audits SECURITY USABILITY • Usability Practices • Usability Assessment • Plain Language • Navigation • Accessibility • Usability Feedback • User Requests Ethics?
  13. 13. Functional Model Governance & Accountability ACTIVITIES: ROLES: • Policy, Rules & Requirements • Development • Accreditation Body • Certification Body • Assessors/Auditors • Community of Interest • Certification • Accreditation • Assessment/Audit Interoperability ACTIVITIES: ROLES: • Standards Development • Specification Development • Exchange • Standards Development Body • Specification Development Body • Interoperability Providers Administration & Operations ACTIVITIES: ROLES: • Redress • Recovery • Enterprise Governance & Policy Development • Internal Audit • Service Optimization • Updates (Periodic & Event Based Functional CORE OPERATIONS: ROLES: • Registration • Credentialing • Authentication • Authorization • Transaction Intermediation • Users • Identity Providers • Credential Service Providers • Reg Authorities • Intermediaries • Attribute Providers • Relying Parties
  14. 14. Functional Elements IDESG FUNCTIONAL ELEMENTS CORE OPERATIONS FUNCTIONS REGISTRATION CREDENTIALING AUTHENTICATION AUTHORIZATION TRANSACTION INTERMEDIATION Application Attribute Control Attribute Verification Eligibility Decision Credential Provisioning Token Binding Attribute Binding Revocation Authentication Request Credential Presentation Credential Validation Authentication Decision Authorization Request Attribute Control Attribute Verification Authorization Decision Blinding Pseudonymization/ Anonymization Exchange
  15. 15. IDEF Stakeholder Groups Drives business value and consumer trust for those issuing or consuming credentials Enables truly trustworthy digital credentials to protect identities Offers foundational set of principles to which all frameworks can align to demonstrate interoperability Trust Frameworks Relying Parties Consumers
  16. 16. IDESG The Identity Ecosystem Steering Group (IDESG) is the source of expertise, guidance, best practices, and tools for trusted digital identities.
  17. 17. 17 INDIVIDUALS! This is the only requirement set for certifications (businesses care about those!) written from the *individual’s* perspective. That’s RADICAL. What REALLY makes this unique?
  18. 18. What is our VALUE ADD? • Privacy, Usability & Interoperability added to pre-existing Security Certifications. • Many Security frameworks are out there and required. • Ours is Individually focused and comprehensive. • Ratings? No one else does this. Is complementary to other certifications. • Ethics? Combining privacy and security with interoperablility and usability gives users control of how their data is managed.
  19. 19. 19 Trustmarks and Ratings
  20. 20. The IDEF Registry Patient Data Privacy Case Studies
  21. 21. Assumptions • Patient outcomes are better when the patient and family is fully engaged • Clearly the provider needs patient data to create good outcomes • Patient consent will take precedence except for emergencies and regulation • The US Health Care ecosystem will be fragmented for the near term • Governmental Pressure to share data will succeed
  22. 22. Health Profile for Digital Ecosystem ● All of the detail that makes a trust registry work for Health Care ● Focus on Medical records locator and access to data by the patient ● Patient needs access to all medical records wherever they may be ● PEW research report – need to match the patient to the record ● Still in development – looking for input from the community https://wiki.idesg.org/wiki/index.php/Health_Care_Profile
  23. 23. Distributed Attribute Use Case ● At registration a new patient needs to bring a variety of identifiers – e.g. ○ Driver’s license – linked to a governmental network ○ Health Insurance Card – linked to a health care network ○ Payment card – linked to a financial network ● Health history – focus on technology (e.g. Blue Button FHIR API) ● Artificial Intelligence is used ensure ID is sufficient for registration https://wiki.idesg.org/wiki/index.php/Patient_Registration_with_Dist ributed_Attributes
  24. 24. Prototype sandbox Start with one use case and allow anyone to contribute use cases • Example use case – Emergency contacts o Family Contacts o Source of patient directives (POLST etc.) o Medical conditions and medical contacts o Targeted to First Responders (e.g. FirstNet and FEMA) https://wiki.idesg.org/wiki/index.php/Emergency_Contact_Informa tion_Use_Case
  25. 25. Tying It All Together ● Any patient needs IAL2 authorization to access their records ● Individual practices need and use other information, such as payment assurance, contacts, patient directives ● Authenticated patients can send records anywhere ○ To other compliant entities, to family, to lawyers as a matter of patient choice ● It seems no practice need care about others authorization ● If this is wrong, we would like to understand why ● If the patient wants cross-practice authorization, that should be a Trusted 3rd Party
  26. 26. Thanks! Noreen Whysel IDEF Registry Kantara Initiative Educational Foundation nwhysel@gmail.com
  27. 27. Additional Slides
  28. 28. The IDEF Registry Phase I
  29. 29. 29 9 Registrants Various industries, all working with identity systems Assumption: B to B or B to G users IDEF Registry at start of Phase II
  30. 30. 30 Assumption: People come to register products What they really wanted: Browse registrant’s products & get easy understanding of scores Burying the lede: Phase I Site UI
  31. 31. 31 Scores: Tough to understand and pie charts didn’t give good representation. Conclusion: Confusing, complicated, not helpful IDEF Registry: Phase I Scores
  32. 32. 32 Problem areas: ● Scores & Symbols ● Linking offsite ● Lack of easy access to Supplemental Guidance ● Not enough context Phase I Usability Learnings: Change areas: ● Lack of easy access to Supplemental Guidance ● Not enough context ● Categories didn’t work ● No tracking ● Buried the lead from top of site ● Forms hard to use ● Hard to see requirements and SG, other supporting docs
  33. 33. The IDEF Registry Phase II Design
  34. 34. 34 ● Usability testing ● Chalkmark surveys for navigation and information architecture ● Design iterations ● Mark and scores in “Design Challenge” ● Flip the whole site Phase II: Clean Up and Evolve with Design
  35. 35. 35 New Front page with context and links to all aspects of the project and registry, IDESG Phase II
  36. 36. 36 ● Step by step process ● Simplified data collection on products and services ● Easy way to check application status ● Easy ways to find help and information Phase II: Registrant data collection improved
  37. 37. 37 ● Requirements shown with the Supplemental Guidance ● Simplified columns ● Easy movement between types of questions ● Easy answering Phase II: New Data Collection Pages
  38. 38. 38 ● Local Knowledge Base instead of clicking away ● Easy way to see the whole Framework ● Simple way to “read the framework” Phase II: Knowledge Base
  39. 39. The IDEF Registry Phase II Scoring
  40. 40. 40 Iterate Iterate Iterate, Test Test Test
  41. 41. 41 Iterate Iterate Iterate, Test Test Test
  42. 42. 42 Iterate Iterate Iterate, Test Test Test
  43. 43. 43 Iterate Iterate Iterate, Test Test Test
  44. 44. 44 Iterate Iterate Iterate, Test Test Test
  45. 45. 45 What happens when people can compare providers? Iterate Iterate Iterate, Test Test Test
  46. 46. 46 Iterate Iterate Iterate, Test Test Test
  47. 47. The IDEF Registry Testing the Requirements
  48. 48. Requirements Testing • Interviews with attesting companies • Open-ended interviews are useful in identifying specific issues that participants may have had with the attestation process. • Focused questions on requirements and supplemental guidance that either were known to have issues for the attester, due to comments provided on the attestation form, or that were implied due to their incomplete or N/A status. • The insight from participants informs potential changes or corrections to the language or significance of individual IDEF Baseline Requirements.
  49. 49. General Questions About the Requirements • Were there any requirements that you recall that were particularly difficult or time consuming to complete? • Were there any requirements that you recall that were irrelevant or unreasonable to the attested service? Why? • Did you consult the supplemental guidance for the requirements? Was it helpful? Why? • Are there any issues or requirements that you hadn't thought about? • Now that you have completed the attestation, do you feel IDESG certification is of value to your company? Why or why not? •11 Questions total
  50. 50. Recommendations for Improvement
  51. 51. 51 Iterate Iterate Iterate, Test Test Test
  52. 52. 52 Iterate Iterate Iterate, Test Test Test What happens when people can compare providers?
  53. 53. The IDEF Registry Phase III Proposal: 3rd Party Ratings for Consumers
  54. 54. 54 3rd Party Ratings Business Model 3rd Party Ratings made sustainable: • Provide ratings via api calls • Charge for use via micropayments • Charge for those rated to use in marketing • 3rd Party certified raters can scale 3rd Party Ratings Trusted in Marketplace: • Reqs made by IDESG, a non-profit neutral party • Ratings by trained 3rd party assessors • No pay to play
  55. 55. 55 3rd Party Ratings with our Reqs 3rd Party Ratings could be done for all consumer products: • Rate within sectors • Health • Children’s products • Financial products • Or Consumer generally Redesigned for mass consumption: