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.

1. Shaping the Future of Trusted
Digital Identity
The IDEF Registry
with Health Information Use Cases
Kantara Initiative Educational Foundation
1

2. www.IDEFRegistry.org
Background

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. 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. 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. 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. Building a Better Digital Ecosystem With
The Identity Ecosystem Framework

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. 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. 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. 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. 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. 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. 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. 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. IDESG
The Identity Ecosystem Steering Group (IDESG) is the source of expertise,
guidance, best practices, and tools for trusted digital identities.

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. 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
Trustmarks and Ratings

20. The IDEF Registry
Patient Data Privacy Case Studies

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. 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. 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. 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. 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. Thanks!
Noreen Whysel
IDEF Registry
Kantara Initiative Educational Foundation
nwhysel@gmail.com

27. Additional Slides

28. The IDEF Registry
Phase I

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
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
Scores:
Tough to
understand and
pie charts didn’t
give good
representation.
Conclusion:
Confusing,
complicated, not
helpful
IDEF Registry: Phase I Scores

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. The IDEF Registry
Phase II Design

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
New Front page with
context and links to all
aspects of the project
and registry, IDESG
Phase II

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
● Requirements
shown with the
Supplemental
Guidance
● Simplified
columns
● Easy movement
between types of
questions
● Easy answering
Phase II: New Data Collection Pages

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. The IDEF Registry
Phase II Scoring

40. 40
Iterate Iterate Iterate, Test Test Test

41. 41
Iterate Iterate Iterate, Test Test Test

42. 42
Iterate Iterate Iterate, Test Test Test

43. 43
Iterate Iterate Iterate, Test Test Test

44. 44
Iterate Iterate Iterate, Test Test Test

45. 45
What
happens
when people
can compare
providers?
Iterate Iterate Iterate, Test Test Test

46. 46
Iterate Iterate Iterate, Test Test Test

47. The IDEF Registry
Testing the Requirements

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. 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. Recommendations for Improvement

51. 51
Iterate Iterate Iterate, Test Test Test

52. 52
Iterate Iterate Iterate, Test Test Test
What happens
when people
can compare
providers?

53. The IDEF Registry
Phase III Proposal:
3rd
Party Ratings for Consumers

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