1. Direct Scalable Trust Forum
November 29 – November 30, 2012

2. Welcome
Farzad Mostashari

3. Putting “Scalable Trust without
Governance” in Context
Claudia Williams

4. What Issues are We Trying to Solve?
• Current Direct deployments are ―islands of exchange‖ limited to single HISPs
or supported by HISP to HISP business agreements
• What‘s the problem? Don‘t know which HISPs to trust
• This is an urgent issue as the current deployment model does not support our
goals of ubiquitous directed exchange to meet stage two of meaningful use
• Common expectations about user authentication, types of certificates to be
used and mechanisms for sharing trust bundles/white lists will support
scalable trust
• Trust communities have emerged to address these issues, urge adoption of
solutions across participants and avoid the need for peer to peer agreements
• If these trust communities place different requirements on HISPs, healthcare
providers and/or their patients may still find it difficult to engage in secure,
directed health information exchange
Note: Providers and patients will still need ways to establish ad hoc trust. This
capability is needed for EHR certification and to support VDT.
-4-

5. Goals for Next Two Days
Enable providers to seamlessly exchange patient information with each other
using Direct across vendor and provider boundaries as the field moves into
stage 2 of meaningful use.
To reach this goal, the community has agreed to tackle these three issues in the
next two days:
1. Identify and encourage adoption of common policies and practices for
identity proofing and certificate management that can be adopted across
trust communities
2. Make progress on a common technical mechanism for distributing trust
anchor bundles within and, to the extent possible, between trust
communities, that will be piloted in the next 2-3 months
3. Identify other common business practices or requirements that will reduce
the need for or simplify trust agreements between HISPs
-5-

6. Principles
• Supports ubiquitous directed exchange
• Can reach widespread implementation in 6-12 months
 Feasible with available resources
 Scalable and easy (enough) to implement
• Keep it simple
 Minimum necessary and nothing less
 Don‘t let the perfect be the enemy of the good enough
 Go for 80 percent everyone can agree on
-6-

7. Agenda, Ground Rules, and “What We
Mean by Scalable Trust?”
Paul Tuten

8. Agenda – Day 1
Day 1 – 10/31 9:00 – 5:30 PM ET
9 – 9:15 AM Welcome Farzad Mostashari, National
Coordinator
9:15 – 9:30 AM ―Scalable Trust‖ In Context Claudia Williams, State HIE Program
Director
Agenda and ―What Do We Mean By Scalable Trust?‖
Paul Tuten, ONC Contractor
9:30 – 10:30 AM Overview of Direct-focused Trust Frameworks / Efforts Representatives from:
• DirectTrust
• Western States Consortium
• NSTIC Pilot (Gorge Health Connect
/ San Diego Beacon)
10:30 – 10:45 AM BREAK
10:45 – 12:15 PM HISP Privacy & Security Safeguards / Operating Policies John Feikema, S&I Framework
Coordinator
Paul Tuten, ONC Contractor
12:15 – 1:30 PM BREAK FOR LUNCH
1:30 – 3:30 PM Identity Verification and Certificate Issuance John Hall, Direct Project Coordinator
Debbie Bucci, Security Advisor
3:30 – 3:45 PM BREAK
3:45 – 5:15 PM Trust Anchor Distribution Mechanisms John Hall, Direct Project Coordinator
Paul Tuten, ONC Contractor
5:15 – 5:30 PM Closing Remarks Paul Tuten, ONC Contractor
-8-

9. Ground Rules
• We‘re NOT re-litigating the Direct specification
• Single certificate to be used for signing and encrypting in the transport of
data
• Address-bound and domain-bound certificates are equally valid
• We‘re NOT re-litigating architectures / deployment models for Direct
• Locally or remotely hosted STAs (and any associated infrastructure) are
equally valid
• Provider or 3rd party managed STAs (and any associated infrastructure)
are equally valid
-9-

10. Ground Rules
• We ARE building from the policy guidance released by ONC for use by State
Health Information Exchange grantees
• Acknowledging areas of broad consensus between Direct ecosystem
participants
• Focusing conversation / energy on areas where consensus has not yet
formed
• We ARE attempting to understand how to best enable end-users to engage
in directed information exchange
• This implies striking an appropriate balance between ease of use in
enabling exchange (i.e., ―establishing trust‖) and ensuring adequate
privacy and security safeguards
• Other transport mechanisms will be used by providers and vendors to
support diverse health information exchange use cases and needs. This
meeting will focus on the specific opportunities and challenges around
creating scalable trust for Direct
- 10 -

11. Ground Rules: And Finally…
• Presume good intentions
• Help group stick to meeting goals and principles
• If you raise a problem, propose a solution
• Have fun!
- 11 -

12. Parking Lot Issues
• Given time constraints, we may need to place issues in a parking lot for later
consideration
• Tomorrow, our agenda is an ―Open Space‖ meeting in which we intend to
address some (if not all) of these issues
• Likewise, please feel to contribute topic suggestions for tomorrow‘s Open
Space meeting throughout the day
- 12 -

13. To Quickly Capture Feedback…
• From time to time, facilitators may ask the group to demonstrate their support
for certain ideas, concepts, or proposals
• We‘re using a very high-tech system of… flash cards:
• Green/Circle = Strong support / preferred option
• Yellow/Triangle = Willing to support / acceptable option
• Red/Square = Absolutely cannot support / not a viable option
• Please hold them up high (so we can see them)
• And, remember to bring them back tomorrow…
- 13 -

14. What is Scalable Trust?
An efficient means of enabling Direct exchange between participants on disparate
HISPs. Fundamentally, it is predicated on two things:
• Common trust frameworks / policies
• Technical mechanisms to automate trust between framework participants
- 14 -

15. Scalable Trust in “Three Easy Steps”
1. Trust Umbrella Organization defines requirements for participation
2. Trust Umbrella Organization enrolls/accredits/certifies entities to be included
in an Trust Anchor Bundle
3. Trust Umbrella Organization enables mechanism for electronic distribution of
Trust Anchor Bundle to all members
- 15 -

16. Example of Scalable Trust Model
Trust Organization
Centralized Trust Anchor Bundle Store
Provider B
HISP A HISP B
Provider A
- 16 -

17. Example of Scalable Trust Model: New HISP Joins Trust Organization
Trust Organization
Centralized Trust Anchor Bundle Store
Provider B
HISP A HISP B
Provider A
Provider C
HISP C
- 17 -

18. Example of Scalable Trust Model: Peer-to-Peer Reciprocity
Trust Organization A Trust Organization B
Centralized Trust Anchor Bundle Store Centralized Trust Anchor Bundle Store
HISP A HISP B HISP C HISP D
This is the aim of this meeting: working toward sufficient alignment—while
allowing for differences—to enable widespread interoperability
- 18 -

19. Overview of Direct-focused Trust
Frameworks / Efforts
David Kibbe – DirectTrust
Aaron Seib – Western States Consortium
Brian Ahier – NSTIC Pilot

20. DirectTrust
Direct Scalable Trust Forum
November 29, 2012
David C. Kibbe, MD MBA
President and CEO
12/9/2012 20

21. DirectTrust
• Non-profit, competitively neutral, self-regulatory entity created by and for
Direct community participants.
• Establishing and maintaining a national Security and Trust Framework (the
“Trust Framework”) in support of Directed exchange.
– A set of technical, legal, and business standards for Directed exchange
– Expressed as policies and best practices recommendations, which members of
DirectTrust agree to follow, uphold, and enforce.
• Leveraging the Trust Framework for a Direct Trusted Agent Accreditation
Program, DTAAP, with EHNAC, for HISPs, CAs, and RAs, as well as their
clients.
• Complementary and subject to, as well as supportive of, the governance
rules, regulations, and best practices for the Direct Project and the NwHIN,
promulgated by HHS and ONC, and the mandates of the HITECH act.
12/9/2012 21

22. Current Members*
• American Academy of Family • McKesson Corporation
Physicians • MedAllies
• Cerner Corporation • Medicity
• DigiCert • Morrell Taggard, Inc.
• EHNAC • Ohio Health Info Partnership
• Gemalto • Nitor Group
• Gorge Health Connect • Redwood Mednet
• HealthcareXchange • Rhode Island Quality Institute
• HealthShare Montana • SAFE Bio Pharma Assoc.
• Healthwise • State of Tennessee
• Informatics Corp of America • Surescripts
• Lexis Nexis • Techsant Technologies
• MaxMD • Walgreens
* DirectTrust.org had over 200 members of its wiki when the transition to a
Membership model of organization began in October, 2012.
12/9/2012 22

23. Membership Eligibility – A Big Tent
• DirectTrust membership is available to:
– Direct exchange participants who are providers or users of Direct exchange
services
– Healthcare provider organizations
– Organizations providing services to healthcare providers
– Government entities
– Educational or scientific research organizations
– Any other nongovernmental entity serving the healthcare industry with an
interest in Direct exchange and the NwHIN.
• Annual membership dues for an organization are between $250 and
$10,000 and based on the organization’s annual revenues related to
health-care business.
12/9/2012 23

24. DirectTrust
Direct Project Rules
DirectTrust.org wiki DirectTrust.org
of the Road
established incorporated
workgroup formed
December 2012 April 2012
April 2011
"A Trust Framework is a set of technical, business, and legal
standards, expressed as policies and best practice
recommendations, that members of a trust community agree to
follow, uphold, and enforce."
12/9/2012 24

25. DirectTrust
X.509 Testing and Trusted Anchor
Certificate Accreditation Bundle
Recognition
Policy Program Program Distribution
Established Service
Sept. 2012 Feb. 2013
Dec. 2011 March 2013
”Within the context of Directed exchange, Trust Agents include
Health Information Service Providers, HISPs, Certificate Authorities,
CAs, and Registration Authorities, RA s”
12/9/2012 25

26. 12/9/2012 26

27. Direct Trusted Agent Accreditation Program, DTAAP
12/9/2012 27

28. Direct Trusted Agent Accreditation Program, DTAAP
Example Criteria from Section II
12/9/2012 28

29. Strategic Context
The Direct Project. Blue Button Initiative. EPCS. NSTIC. Stage 2 Meaningful
Use objectives for Care Coordination and Patient Engagement. ACOs. RHEx.
• Common need for assurance around security, trust, and identity as a pre-condition for
health information exchanges on the Internet.
• Development of a new paradigm for identity management that shifts identity
management responsibilities to an authoritative and trusted identity management
network that acts as an ecosystem for identity.
• A new role within that ecosystem for Trust Framework providers, who are responsible
for ensuring that the identity providers meet agreed-upon standards for issuing
identity credentials and sharing appropriate information, thereby allowing the relying
parties to confidently accept and use the credentials.
• DirectTrust members recognize Internet sharing of health information requires the
establishment of a Trust Framework suitable to the needs of providers and patients has
to occur, and that it will need to grow and evolve over the next few years.
12/9/2012 29

30. Workgroups
Security and
Trust
Compliance
Certificate Citizen and
Policy and Patient
Practices Participation
12/9/2012 30

31. Security and Trust Compliance Workgroup
Chair Andy Heeren, Cerner Corporation
Purpose Create a program which can be used by HISPs to voluntarily apply,
qualify, and thereby be able to attest, to having met or exceeded best
practices for security and trust, all within the context of and abiding by
the policies and regulations as promulgated by ONC and HHS for Direct
exchange, and respectful of state laws pertaining to privacy and
security that may apply.
Completed • Draft HISP Evaluation Criteria
• Draft RA Identity Verification Checklist
• HISP/CA/RA Self-attestation Checklist (Security and Trust Specs. Doc)
Active • “Pilot” Trust Community Program Development
• Self-Attestation Checklist Review – Round 1 Submission Discussions
Upcoming • Accreditation Program Development
12/9/2012 31

32. Certificate Practices and Policy Workgroup
Chair Don Jorgenson, Inpriva
Scott Rea, DigiCert
Purpose Establish and maintain a Certificate Policy (CP) and related
policy/practices specifications and documentation that will serve as a
guide to Health Information Service Providers (HISPs) and their
Certificate Authorities (CAs) as they implement Direct exchange
programs and services.
Completed • DirectTrust.org Ecosystem Community X.509 Certificate Policy - Draft
for Trial Use complete
Active • DirectTrust CP 1.0—Updated and extended from DTU
• Scoping out Attestation/Accreditation processes
• Identity Proofing Guidance including FBCA Antecedent Proofing
• Preparing identity proofing guidelines for Federal PKI Policy Authority
Review (FBCA).
Upcoming • So You Want to be a HISP?
• Guidance via Frequently Asked Questions
12/9/2012 32

33. Citizen and Patient Participation Workgroup
Chair Leslie Kelly-Hall, HealthWise
Purpose Encourage and enable broad Directed exchange between
citizens/consumers/patients and health care professional through
reaching consensus on a shared set of security and trust policies and
best practices that will reduce the administrative burden to provision
citizens/consumers/patients with trusted identity credentials, including
X.509 digital certificates required of participants in Direct.
Completed
Active • Consumer Use Cases
• DirectTrust White Paper: Citizen and Patient Participation in Direct -
Closing the Gaps
• Direct Rules of the Road WG Citizen Community Draft Policy
Statement
Upcoming • So You Want to be a HISP?
• Guidance via Frequently Asked Questions
12/9/2012 33

34. Products and Services
• Testing and Recognition Program
– Launched in September 2012 with six HISPs/CAs/RAs
– Participants submit self-attestations based on DirectTrust’s Security and Trust
Specifications v0.7, which are evaluated for compliance.
– DirectTrust will identify those organizations that passed the evaluation on the
DirectTrust.org website, and will distribute a trust bundle to the participants.
– Additional rounds are scheduled to be completed during Q4 2012.
• Accreditation Program
– Scheduled to launch in Q1 2013
– Formal accreditation program for HISPs, CAs, and RAs based on the criteria
established through the Testing and Recognition Program
– To be developed and administered in partnership with the Electronic
Healthcare Network Accreditation Commission (EHNAC)
12/9/2012 34

35. Western States Consortium
November 29, 2012
Scaling Trust Briefing

36. Agenda
 State Health Policy Consortium
 An ONC support grant to get the WSC started
 Grant Deliverables
 Executing WSC – Pilot Scenarios
 Formation of a Multi-state Governance Body
 Pilot Scenario‟s 1 & 2
 Intersections between Governance of Trust
Communities and Accreditation
 Improving Trustworthiness
 Enabling Local Policy Decisions

37. Origins at a glance
 ONC‟s State Health Policy Consortium (SHPC) provided grant funding
to evaluate the policy and subsequently pilot the use of digital
certificates and provider directories to enable inter-state exchange.
 Project received final approval from ONC on November 1, 2011
 Grant provided for logistical support (RTI)and limited funds for
contractors that work on the initiative (John Hall, C3 Consulting and
Dragon) along with the participants from each of the states
 States involved in grant application included OR, CA, NV, AZ, HA, UT,
AK, NM.
 Known as core states – each of these states have actively
collaborated to develop the grant‟s work plan & participated in the
execution of that plan.
 Subsequent to kick-off observing satellite states have included WA,
CO, ID, GA & FL. Just last week MI became the latest state to
become a satellite participant with the WSC.
 Grant deliverable is a “Final” report but the intent from the beginning
has been to see the WSC persist as a method of improving
trustworthiness of exchange.

38. 38

39. Focus of Grant
 Approved Work Plan focuses on the practical and
technical barriers to ensuring the privacy and
security of interstate exchange, with a specific
focus on how provider directories and trust services
originating in different states can be harnessed and
potentially combined at the regional level to
promote privacy and security and facilitate
interstate exchange using Direct secure messaging.

40. Overall Objectives
 Policy: The key barrier being examined by this work is to
evaluate the Policy variances among exchanging states
and identify solutions that would enable the exchange
of health information
 Alternatives analysis and selection: Key elements to be
considered included federated provider directory
concepts and establishment of trust anchors. How can
we implement Trust Bundles and other related processes
so that a Certificate from OR can be trusted to assure
Identity of a Provider for a caregiver in CA in a consistent
policy environment? How can provider directories be
used to facilitate trust?
 Pilot Implementation: Using a collaboratively established
best of breed approach implement a local solution
between CA (NCHIN) and OR (CareAccord). Operate
pilot and produce report for ONC to distribute to nation.

41. 41
Work plan – Tasks
 Task 1: Status Meetings with RTI
 Task 2: Research, Preparation, and Analysis
 Task 3: Trust Services & Provider Directory Services
 Task 4: Weigh Options and Determine Solutions
 Task 5: Preparation to Implement Solutions
 Task 6: Steps Toward Implementation
 Task 7: Execute Pilot Scenarios
 Task 8: Produce Report
 Post SHPC

42. 42
Executing
WSC – Pilot Scenarios
• Formation of a Multi-state Governance Body
• Pilot Scenario‟s 1 & 2 and beyond

43. 43
Pilot Landscape

44. 44
WSC-MOU; Relationships; Policies and Procedures

45. 45
Key initialization milestones
 Execution of MOU by OR & CA – establish
Governance Body
 Governance Body approved initial Policies and
Procedures
 Policy & Procedure Change Process
 Onboarding WSC-Qualified Entities
 Communications Policy
 CA executed Onboarding P&P for NCHIN
 OR executed Onboarding P&P for CareAccord
 November 1 – Test message exchanged between
CA Participant of NCHIN and an OR Participant of
CareAccord

46. 46
Test Message sent November 1, 2012

47. Western States Consortium Pilot Scenarios
Use Case: Directed messaging of clinical information
between providers across state lines for
treatment purposes.
WSC is piloting…
 Policies and Procedures
 Governing Body that creates policies, procedures, etc.
 Defined responsibilities for each Party State.
 Policies/procedures for Change Control, Eligibility,
Communications, etc.
 Technology
 Trust
Bundle that defines a scalable, multi-party Trust
Community.
 Federated Directory Services that support individual and
organizational endpoint/address discovery.

48. 48
Scenario 1 and Scenario 2.a & 2.b
Within the Trust Community of the WSC-Pilot:
Scenario 1:
Executed the independent evaluation of each state‟s respective Pilot-HISP for
compliance with common Eligibility Criteria as defined by the Governance Body.
Employed shared trust bundle methodology to make Qualified HISPs discoverable
to one another. (Live November 1)
Scenario 2.a:
Implementing address discovery using open-standards based query of HISP‟s
directories across state lines. The query standard we are currently working with is
based on HPDPlus and related S&I Framework Activities. (December 6)
Scenario 2.b:
Extends Scenario 2.a by introducing a CA services to act as a scalable hub to many
HISPs in CA. California will be the first to implement these methods of federation
using statewide orchestration services in pilot mode among HIOs in CA.
(Assuming go-decision based on experience of running 2.a ~ Release 1.0 of the
California is expected to launch mid-January)

49. 49
Governance of Trust Communities,
Accreditation and Innovation

50. 50
Where does Accreditation and
Governance intersect for the WSC?
 Accreditation has the greatest value for those
Eligibility Criteria that:
 Are common to many scenarios for a given technology;
and
 Have uniform methodologies that can be verified
 Governance has the greatest value for those
Eligibility Criteria that:
 May vary based on what the technology is used for; or
 Cannot be readily tested and requires scenario specific
policy controls.
 The WSC Eligibility Criteria are divided into two sets
aligned with these two cases.

51. 51
From State HIE Direct CoP meeting November 19, 2012 – John Hall Presentation

52. 52
Terms
 Technical Certification – where a repeatable test can
produce a pass fail value for conformance to a set of
common technical standards – tends to be product focused
 Ex: Conformance to the DIRECT Applicability Statement
 Accreditation – where scenario specific evaluation assures
conformance to a set of common operational standards (that
may rely on certified products) – tends to be service focused
 Ex: Identity Management Using PKI
 Governance – where common operational standards are not
mature and interoperable trust is dependent on obligations
established in contract or law – tends to be inter-
organizationally focused
 Privacy Preserving Policy requirements in the absence of an
„accredit-able‟ method of satisfying consent requirements

53. 53
Technical Certification and Accreditation
contribute to trustworthy Governance
 Where „technical certification‟ and Accreditation
are very valuable for those uniform requirements
that have mature standards.
 Governance is useful to facilitate trust where
exchange is dependent on aspects of services that
do not have uniformly adopted operational
standards and must rely on inter-organizational
concurrence to work.
 An example to consider is how to approach
differentiating between HISP that populate CDRs as
part of their service offerings from HISP that don‟t
from Covered Entities that operate a certified
DIRECT component from within their EHR.

54. 54
What is important about a model like the
WSC and what does it provide?
 Decentralization of Program Management permits
Local Autonomy while providing for a pathway to
mutual recognition across states
 Each State retains all Sovereign Authority to regulate or
promote HIE within its state;
 Distribution of evaluation and monitoring of HIOs to the
entities closest to the effected parties with the authority to
provide oversight;
 Permits intra-state communities to form under each State‟s
program to ensure local differences are not overlooked
 Permits each State to foster innovation within its programs
while providing a means to isolate risks related to the
innovations from consensus based rules of the road.

55. 55
Governance and Accreditation – complimentary
components for scaling trust & innovation
Governance includes management and enforcement to rules, among
other functions, some of which might be covered within an
Accreditation Program, but not all.
A few explicit governance roles and issues that may be addressed by a
Governance entity such as the WSC but not necessarily by an
accreditation program include:
 Changing the Culture – provide tools that facilitate trusted exchange
while fostering innovation
 Explicit norms regarding expulsion from the community, black listing,
revocation of certain privileges, and even fines or penalties in some
jurisdictions.
 Mutual promotion of best practices and emerging technical
alternatives.
 Rules and norms regarding sharing of directory information beyond
that which is specified in the Direct standard.
 Facilitate the prioritization and advancement of additional of
common high value transactions that rely on attributes not
verifiable via technical test today.

56. NSTIC Pilot Project
Scalable Trust
Investor Presentation Q2 2012
November 29, 2012

57. &
National Strategy for Trusted Identities in
Cyberspace
• Signed by the President in 2011 • Resilient awarded 12 month, $2M
• Create new Identity Ecosystems grant to pilot innovative solutions for
to assure security and privacy both healthcare and education
• Pilot grants and an adoption
requirement for .Gov websites • Trust Network will connect nationally
recognized leaders for identity, policy
and online content
• Goal is to commercialize solutions
and capabilities for rapid adoption by
public / private sectors
“Making Online Transactions Safer, Faster, and More Private”

58. Goals of the NSTIC Pilot
Healthcare: Patient-Centered Coordination of Care (PCC)
 Enable trust for sensitive health and education transactions on the Internet
 Provide secure, multifactor, on-demand identity proofing and authentication
across multiple sectors, at national scale
 Implement an identity ecosystem encompassing patients, physicians and
staff which facilitates coordinated care through secure, HIPAA-compliant
access to:
 Electronic referral and transfer of care messaging
 Advanced, on-demand decision support service
 Commercialize solutions and underlying capabilities, beyond Year 1

59. Healthcare: Patient-Centered Coordination of Care
Pilot Sites & HIE Software: Highlights of Pilot
• Populations of seasonal agricultural
workers from SD work and received
care in Oregon too
• Identity matching and policy
enforcement enables coordination
Decision Support Partners: • Enable NwHIN Direct messaging
across HIE platforms and state lines
• Novel, cloud-based decision support
available to doctors in both states
• On-demand, privacy-preserving
Identity & Attribute Providers: authentication and authorization
• Commercialized identity matching,
secure messaging & cloud-based
decision support can scale rapidly
Advisors on Governance / Protocols / Policy: Principal Investigator
Dr. David Hartzband, D.Sc.
Chief Technology Officer
Resilient Network Systems
david.hartzband@resilient-networks.com

60. The TrustTrust Network
Resilient Network
An “overlay” that makes existing security stronger, and provides unmatched
capabilities for cross-enterprise collaboration and commerce.
 Achieves security and privacy - anonymous authentication, privilege
management and monitoring support identity verification and matching
without exposing identity information
 Enhances data security because the data is not actually shared; making is
safer to use to prove claims

61. Coordination of Care
eReferral Messaging
input Clinical input
• “Closes the Loop” Decision
• Handles Identities Support
“In the Network” Primary Care & Cardiologist
Powered by:
for use of portals Physician
results results
and web services
• Resolves policies
within and across:
• Organizations
• Tech platforms
• State lines
• Interoperable
Transfer of Care Messaging

62. Identity Syndication
Verified Identity
1. “I am Dr. John Smith”
Dr. Smith
2. “I am a Cardiologist” Enabled
for Use
user
Identity Syndicate
Aggregates and organizes
2nd Claim Confirmed
1st Claim Confirmed
Identity Broker identity attributes
Correlates, verifies (inputs from ID Broker) and
and authenticates calculates Levels of
identities of users Certainty
and records.
Identity Syndicate
Inconclusive
Identity Providers
Maybe
Maybe
- Commercial ID
Yes
Yes
Yes
Providers
- Professional
HIE / LexisNexi NaviNet AMA
associations
- Other applications, HISP s
directories and services

63. Trust Enables : Authorized Relationships
Notification of information
requiring authorization
Physician Staff Staff Physician
Office 1 Office 2
Establishes Trust Graphs by
Dr. Smith enforcing the policies that Dr. Brown
Dr. Smith’s Office form these relationships Dr. Brown’s Office
Authorized Authorized
Relationships Relationships
Patient Patient
Trust Encrypted exchange Trust
Graph 1 can now occur Graph 2

64. Expansion and Connections to Other Initiatives
DIRECT Projects
Western States Initiative – focus on how state-level provider directories and trust services can be
federated at a regional level to promote privacy and security and facilitate interstate exchange
• Oregon and California will implement a proof of concept pilot that will support the solutions
agreed upon by the group
• Alignment of interests and outcomes creates synergy between projects
Automate Blue Button Initiative (ABBI) – develop standards and specifications that allow patients
to download their health information, and to privately and securely automate sending records to their
preferred holding place.
• Pull Workgroup: allowing a third party application to access personal health data on demand
• Plans to leverage identity ecosystem from NSTIC
Collaborative and Cloud-based Healthcare Apps/Services
Aetna Strategic Services
• ActiveHealth CareEngine™
• Medicity HIE, and iNEXX Platform

65. Break
Please meet back in Potomac D&E in 15 minutes!

66. HISP Privacy & Security Safeguards /
Operating Policies
John Feikema
Paul Tuten

67. Areas of General Consensus w/ State HIE Program Recommendations
• Conform to all of the requirements specified in the Applicability Statement for
Secure Health Transport v1.1 and (if implementing) the XDR and XDM for
Direct Messaging specifications.
• Minimize data collection, use, retention and disclosure to that minimally
required to meet the level of service required of the HISP. To the extent that
HISPs support multiple functions with different requirements for data use,
they must separate those functions such that more extensive data use or
disclosure is not required for more basic (Direct) exchange models.
• Determine whether they are business associates (BAs) and hold themselves
to the provisions of the HIPAA Security Rule, as amended by the HITECH
Act, that are applicable to BAs.
- 67 -

68. Areas of General Consensus w/ State HIE Program Recommendations
• Encrypt all edge protocol communications that enable ‗last mile‘ exchange
between end-users‘ systems and an STA/HISP‘s Direct infrastructure by
using SSL/TLS or similar industry standard.
• For HISPs that manage private keys -- perform specific risk assessment and
risk mitigation to ensure that the private keys have the strongest protection
from unauthorized use.
• For HISPs that manage trust anchors on behalf of their customers -- have
well defined, publicly available policies that permit customers and other
parties to evaluate the HISP‘s certificate issuance (and trust management)
policies.
• Only facilitate Direct messages that utilize digital certificates which conform to
related RA/CA certificate guidance (Note: details of the RA/CA requirements
will be handled later).
- 68 -

69. Areas of General Consensus w/ State HIE Program Recommendations
with Significant Extensions by Trust Communities
• Have contractually binding legal agreements with their clients (who send and
receive Individually Identifiable Health Information [IIHI] using Direct),
including all terms and conditions required in a Business Associate
Agreement (BAA).
• In particular, efforts have focused on the definition of specific obligations for data
senders and recipients, especially what data recipients may or may not do with
the data they receive. However, these issues are generally covered by existing
national and state laws and regulations.
• Demonstrate (through either availability of a written security audit report or
formal accreditation provided by an established, independent third-party
entity) conformance with industry standard practices related to meeting
privacy and security regulations in terms of both technical performance and
business processes.
• In particular, efforts have focused on the definition of either acceptable existing
security audits and/or specification of requirements for new accreditation
programs.
- 69 -

70. Suggested Enhancements to Existing State HIE Program Recommendations
• In addition to encryption (which is already specified), authenticate all edge
protocol communications that enable ‗last mile‘ exchange between end-users‘
systems and an STA/HISP‘s Direct infrastructure.
- 70 -

71. Lunch
We’ll resume the meeting at 1:30 PM.

72. Identity Validation and Certificate Issuance
John Hall
Debbie Bucci

73. State HIE Program Recommendations for RAs/CAs (Identity Validation)
• For identity validation of non-patient entities:
• RAs, CAs and any other entities performing RA functions should ensure
that individuals and organizations are identity proofed at the medium
assurance level (as specified in FBCA X.509 Certificate Policy for the
Federal Bridge Certification Authority Dec. 9, 2011). The identity of the
applicant must be established no earlier than 30 days prior to the initial
certificate issuance.
- 73 -

74. State HIE Program Recommendations for RAs/CAs (Identity Validation)
• Detailed requirements for non-patient entities:
• For individual end-users – identity is established by in-person proofing before the
Registration Authority, Trusted Agent or an entity certified by a State or Federal
Entity as being authorized to confirm identities (such as a notary public) using
federal government-issued photo ID, a REAL ID Act compliant photo ID or two
non-federal IDs, one of which is a photo ID (e.g., Non-REAL ID Act compliant
Drivers License). All credentials must be unexpired. A trust relationship between
the Trusted Agent and the applicant, which is based on an in-person antecedent,
may suffice as meeting the in-person identity proofing requirement.
• For organizations – is set out in the FBCA Certificate Policy, identity is established
by a representative of the organization (from the Information Systems Security
Office or equivalent) providing the organization name, address, and
documentation of the existence of the organization. In addition to verifying this
information, the RA must verify the authenticity of the requesting representative
(at the medium level of assurance) and the representative‘s authorization to act in
the name of the organization to control of the organization‘s group certificate
private key.
- 74 -

75. State HIE Program Recommendations for RAs/CAs (Identity Validation)
• Additional requirement:
• An organization participating in a HISP must be a HIPAA covered entity, a
business associate of a HIPAA covered entity, or be a person or organization who
is involved in health care related activities and who agrees to hold themselves to
the same security requirements as provided in the HIPAA Security Rule.
- 75 -

76. Areas of General Consensus w/ State HIE Program Recommendations
for Identity Validation
• The Direct community is generally supportive of the need for robust identity
validation of both individuals and organizations and existing practice by
HISPs/HIEs at least attempts to generally align with these methods
• The Direct community supports the additional requirement of ‗healthcare
affiliated‘ entities (i.e., not just providers/patients) engaging in directed
exchanges
However…
• The Direct community has expressed concerns about differences between
FBCA and NIST levels of assurance (see reference slides)
• The Direct community has also expressed a desire to engage in remote
identity validation of end-users
- 76 -

77. State HIE Program Recommendations for RAs/CAs (Certificate Issuance)
• CAs should be cross-certified to the Federal Bridge Certification Authority
(FBCA) and issue/utilize a certificate policy (CP) and certificate practice
statement (CPS) that conforms to FBCA cross-certified requirements. In
particular, the CA should issue certificates that:
• Are cross certified to the Federal Bridge Certification Authority (FBCA)
• Are issued to a health care related organization or more granular
component of an organization (e.g., department, individual). One
certificate issued to a HISP to use on behalf of all participants in the
HISP does not meet this criterion.
• Conform to required assurance criteria
• Do not have non-repudiation flag set
• Conform to other requirements set forth in Applicability Statement for
Secure Health Transport
- 77 -

78. Gaps in Consensus with State HIE Program Recommendations for RAs/CAs
(Certificate Issuance)
• While many entities have policies which ―align with‖ (or are claimed to do so)
with the Federal Bridge Certification Authority (FBCA), many community
members have expressed reservations about actually issuing FBCA cross-
certified certificates
• Let‘s talk about why FBCA was included in the State HIE Program guidelines
• Let‘s explore possible alternatives to FBCA
• Let‘s consider potential paths forward
• Some individual HISPs / HIEs have expressed a desire to employ a single
HISP-wide certificate to use on behalf of all participants in the HISP
• Let‘s talk about why this requirement was included in the State HIE Program
guidelines
• Let‘s discuss why trust communities also don‘t support a single, HISP-wide
certificate in their participation requirements
• Let‘s consider how we can/should make this requirement less ambiguous
- 78 -

79. Gaps in Consensus with State HIE Program Recommendations for RAs/CAs
(Identity Validation)
• The decision about whether or not to use FBCA Certificates has implications
for identity proofing requirements for individual end-users
• If stick with FBCA, keep Medium requirements?
• If pick alternative to FBCA, use LOA3 requirements to align with proposed MUS3?
• Either way, allow for remote identity proofing? (which is acceptable for both
Medium and LOA3)
- 79 -

80. Break
Please meet back in Potomac D&E in 15 minutes!

81. Trust Anchor Distribution Mechanisms
John Hall
Paul Tuten

82. Direct and Trust Anchors
• Within Direct, messages are transported only between trusted parties.
• The technical expression of a trust relationship is through the mutual
exchange of trusted anchor certificates, or trust anchors.
• The Applicability Statement does not define mechanisms through which trust
anchors are exchanged or maintained.
- 82 -

83. Manual Exchange of Trust Anchors
• In the absence of defined mechanisms for trust anchor exchange and
maintenance, parties forming trust relationships are using one-off manual
operations.
• However, manual exchange and maintenance of trust anchors doesn‘t scale
beyond the smallest of numbers – N-squared problem.
- 83 -

84. Trust Anchor Distribution
• There‘s broad recognition that one-off manual exchange of trust anchors
doesn‘t scale.
• Trust anchor distribution is often discussed within the ecosystem and is a
common component of trust communities.
• As members join a trust community, the community aggregates their associated
trust anchors.
• This aggregation of anchors, sometimes referred to as a ―bundle‖, is made
available to the entire community.
• Members of the trust community configure their STAs to trust the anchors in the
bundle.
- 84 -

85. Examples of Trust Anchor Distribution Mechanisms
Numerous potential mechanisms to distribute trust anchors have been raised in
the past, including:
• Package Download
• Command Channel
• Web Service
(These are simply examples illustrating possibilities. We will not be going into
plusses/minuses of each since we’re not trying to build consensus today around a specific
approach.)
- 85 -

86. Trust Anchor Distribution Option: Package Download
• Trust community aggregates its trust anchor bundle into a structured package
(e.g., TAR, ZIP) and makes it available for download at a standard location
using a standard protocol (e.g., HTTP, FTP).
• Upon joining the trust community, members download the trust anchor bundle
package and configure their STAs to trust the anchors within the bundle.
• Trust community re-publishes its trust anchor bundle package as the bundle
changes. Members periodically and regularly re-download the package and
refresh the configuration of their STAs. This could be automated or have
manual components.
• Members might have the option of downloading and dealing with smaller
―delta‖ packages that only contain new or updated anchors as well as data
detailing trust anchors that should be deleted. Depending on how current a
member‘s local version of the trust bundle is, multiple ―deltas‖ may need to
be downloaded and applied.
- 86 -

87. Trust Anchor Distribution Option: Command Channel
• Starts similarly to Package Download Option – trust community makes
available to members its trust anchor bundle at a standard location via a
standard protocol, and new members download the trust anchor bundle and
configure their STAs to trust the anchors within the bundle.
• Trust community subsequently communicates changes to the bundle as they
occur using Direct messages.
• Messages are from a Direct address dedicated by standard.
• Contain a command or set of commands – Add, Update, Delete
• Contain appropriate information to act on commands, e.g., anchor to add.
• Structured to be computable for automated processing.
• Member STAs receive these ―command‖ messages at dedicated addresses,
process them, and act on them accordingly, thereby keeping their trust
bundle configurations synchronized.
- 87 -

88. Trust Anchor Distribution Option: Web Service
• Trust community offers a web service that enables members to access its
trust anchor bundle.
• Using the web service, members can:
• Populate the configuration of their STAs with the trust anchors in the current
bundle
• Query for changes to the bundle and synchronize their STAs accordingly
• Members use the web service to initialize the trust bundle configuration of
their STAs upon joining the trust community and regularly query the service
to keep their STAs synchronized.
• Web service could be:
• RESTful, building upon standards such as ATOM/RSS
• SOAP-based
- 88 -

89. Trust Anchor Distribution (Redux)
It‘s great that there are options for trust anchor distribution, but multiple
approaches taken within the ecosystem will create problems for solution
providers, hinder interoperability between trust communities, and present
serious challenges to scaling trust.
Trust Organization A Trust Organization B
Centralized Trust Anchor Bundle Store Centralized Trust Anchor Bundle Store
X X
X X
HISP A HISP B HISP C HISP D
- 89 -

90. Working Together on a Common Approach to Trust Anchor Distribution
• Subgroup of Direct Project‘s Implementation Geographies Workgroup
• Determine common technical approach to trust anchor distribution
• Develop implementation guide
• Pilot implementation guide
• Refine implementation guide as needed based on pilots
• Potential timeline
• Determine technical approach – by mid Jan 2012
• Develop implementation guide – by mid Feb 2013
• Pilot implementation guide – through mid Apr 2013
• Refine implementation guide – by end Apr 2013
• Who‘d like to participate?
• We‘ve got a sign-up sheet
• We‘ll hold an ―Open Space‖ session tomorrow to kick-off this effort
- 90 -

91. Closing Remarks
Paul Tuten

92. Reminders
• We start tomorrow at 8 am. Please remember to bring back your consensus
cards
• We‘ll end tomorrow at 1 pm, but we encourage you to continue discussions
after the meeting in the hotel lobby or at restaurants in the area
• We‘ve made arrangements for an optional social event tonight @ 6:30:
• BELL20 Restaurant in the lobby of Crystal City Marriot
- 92 -

93. Direct Scalable Trust Forum – Day 2
November 30, 2012

94. Agenda – Day 2
Day 2 – 11/30 8:00 – 1:00 PM ET
8:00 = 8:30 AM Day #1 Meeting Recap Paul Tuten, ONC Contractor
Claudia Williams, State HIE Program
Director
8:30 – 9:30 Business Practices/Requirements That Could Reduce the Erica Galvez, State HIE Community of
Need for, or Simplify, HISP to HISP Agreements Practice Director
9:30 – 9:45 AM BREAK
9:45 – 10:00 AM ―Open Space‖ Meeting Set up and Ground Rules Erica Galvez, State HIE Community of
Discussion Practice Director
10:00 – 11:00 AM Breakout Session 1
11:00 – 12:00 PM Breakout Session 2
12:00 – 1:00 PM Next Steps, and Concluding Remarks Paul Tuten, ONC Contractor
Claudia Williams, State HIE Program
Director
- 94 -

95. Business Practices/Requirements That
Could Reduce the Need for HISP to HISP
Agreements
Erica Galvez

96. Business Practices/Requirements That Could Reduce the Need for HISP to
HISP Agreements
• Needing peer to peer agreements between all HISPs is not a scalable
approach to support ubiquitous directed exchange
• What other business practices, requirements or policies must be addressed
to obviate the need for one-off HISP-to-HISP agreements for Direct message
exchange?
• Some examples to consider:
• Should trust communities also require common operational
characteristics for participating HISPs (e.g., service availability?)
• Should participation within a trust community imply unfettered Direct
message exchange between all members of the community (i.e., a form
of ―network neutrality‖)?
• Should HISPs participating in trust communities agree not to charge fees for
basic send and receive functions from other HISPs?
- 96 -

97. “Open Space” Meeting Setup and Ground
Rules Discussion
Erica Galvez

98. Open Space
Technology
Liberating Inherent Creativity & Leadership
Henri Lipmanowicz & Keith
McCandless
In Large Groups with an Action-Orientation

99. Open Space Boosts Freedom AND Responsibility
Freedom
Responsibility
Henri Lipmanowicz & Keith
McCandless

100. Open Space Purpose
To facilitate discussions and collaboration between Direct
implementers that:
(1) Address important issues we were unable to cover in the
previous sessions
(2) Further the goal of enabling providers to seamlessly
exchange patient information with each other using
Direct across vendor and provider boundaries as the
field moves into stage 2 of meaningful use.
(3) Unleash creative thinking, and build partnerships that
leverage existing investments in Direct

101. Open Space Minimum
Specifications
Discussions and collaborations should:
• Support ubiquitous directed exchange
• Focus on issues and solutions that can reach widespread implementation in
6-12 months
• Work toward minimum necessary, and nothing less
 Don’t let the perfect be the enemy of the good enough
 Go for 80 percent everyone can agree on
• Be feasible with (roughly) current resources
 Motivation, knowledge and funding

102. Four Principles and One Law
Be prepared to be surprised; and,
let your passion guide you
Law of Two Feet
• go to where you are learning or contributing
Principles of Open Space
• Whoever comes is the right people
• Whatever happens is the only thing that could have
• Whenever it starts is the right time
• When it is over it is over
Henri Lipmanowicz & Keith
McCandless

103. Open Space Meeting Agenda
Open Space Breakout Session
Session A Guide B C
1 What do we do in the Overview of Provider directory
meantime? DirectTrust.org and 360X piloting
10:00-11:00
AM Convener: Peter
Convener: Lee Jones Convener: David Kibbe
Bachman
Identity & agency
2 are NOT health
Mechanisms for EHR-HISP care specific,
distributing trust bundling for MU2 attributes &
11:00-12:00
bundles directories ARE
PM
Convener: Gary health care specific
Convener: Rim Cothren Christensen
Convener: Adrian
103
Gropper

104. Next Steps and Concluding Remarks
Claudia Williams
Paul Tuten

105. Discussion
• What key insights / learning / discussions occurred in the open space
sessions?
• Are there additional high priority actions that are needed?
• How do we move forward from this meeting? What are the important
next steps?
- 105 -

106. Reminders
• Don‘t forget to…
• Sign-up for Trust Anchor Bundle Distribution Workgroup
• Download presentation slides from Direct Project wiki
• Complete evaluation forms
- 106 -

107. Thanks! .
- 107 -

108. Summary Slides

109. Organization Distribution*
Trust Other
Framework
Health
Provider
Information
Service
Contractor Provider
7 (HISP)
2
Other Includes:
7 25
State HIE • Patient Privacy Rights
Grantee • Provider
5 • Accreditation
• Professional Society
• Software Company
7 • Consumer Advocate
EHR Vendor • Standards Based
10 Community
8
12
Certificate
Registration Authority
Authority
Federal Total number of forum participants: 69
Agency
*Some participants represented more than one organization at the forum
- 109 -

110. Key Takeaways – Day 1
• HISP-to-HISP interoperability is vital, yet remains a challenge.
• Trust umbrella organizations (i.e., trust communities) represent one viable
and valuable path toward achieving ‗scalable trust‘.
• LOA3 Identity Verification / FBCA Basic (or equivalent) processes are an
appropriate/acceptable baseline for certificate issuance / management.
• Implementations based on a single, HISP-wide certificate are not acceptable.
• There is general consensus around the State HIE Program‘s HISP operating
guidelines. Additional detail/specification is needed in a few areas (e.g., issue
of use/re-use of data by HISPs/HIEs).
• Group should work together to conduct pilots to establish a common
mechanism for trust anchor bundle exchange.
• Defining a ‗glide path‘ (interim steps) and education are important next steps.
- 110 -

111. Key Takeaways – Day 2
• The risk management and legal community must be educated in order to
establish any form of accreditation.
• It‘s not just the wires that need agreements, it‘s the disclosers that need them
as well.
• A common ―package‖ of elements to avoid HISP-to-HISP agreements may
include:
• BAA HISP  Provider
• Dispute resolution among HISPs
• Explicit transparent accreditation
• Clarification on breach/safe harbor
• Auditing/enforcement by accrediting body
• Federated trust agreement
• Group needs to manage expectations during this process;
especially, acknowledge that everyone will not agree to participate right away.
- 111 -

112. Key Takeaways – Breakout Sessions
• A1 – “What do we do in the meantime?” – Lee Jones
o The group decided to endorse three points:
1. We agree with the need to address trust issue with a scalable
solution.
2. We do not support HISP to HISP agreements.
3. We understand that we have to be transparent, so we will publish our
list of attributes that explain our current state of practice and
policies, i.e., a registry of all HISPs that abide by community‘s
guidance.
o Action Item: Draft language/guidance on how to describe this initial step
towards interoperability.
• B1 – “Overview of DirectTrust.org” – David Kibbe
o Elements of accreditation will be published by the end of December, and
will be taking applications on February 1st.
o We will have 6-8 accredited entities by March.
o Rhode Island is going to adopt this accreditation to replace their existing
one.
o Action Item: Publish the outcomes of this forum and develop education to
providers, legal communities, and EHR vendors about accreditation
process. - 112 -

113. Key Takeaways – Breakout Sessions
• C1 – “Provider Directories and 360X Piloting” – Peter Bachman
o The trust bar for the developed methodology around referrals and
provider directories has been set too high; we would like to lower the trust
bar.
o Identity is imperative to know who you‘re dealing with and a national
framework to structure should be pursued, i.e., HISP or owner of the
provider directory should have the authority to verify certificates.
o Next step: Find pilot participants for the 360X Project that is supported
by ONC.
• A2 – “Mechanisms for distributing trust bundles” – Rim Cothren
o There are two organizations working through this problem; the group
identified overlapping issues and reaffirmed that we‘re talking about a
collection of trust anchors.
o Next step: Must have HISP representation in the Implementation
Geographies sub-workgroup.
- 113 -

114. Key Takeaways – Breakout Sessions
• B2 – “EHR-HISP bundling for MU2” – Gary Christensen
o A good number of the rooms‘ leaders had not processed the implications
of MU2 on certification participants.
o There were two items passed forward for people to think about in terms of
how this relates to a business model:
1. Encourage the EHR marketplace to adopt the XDR piece
2. There may be creative thinking that will fit within constraints, so we
encourage the group and ONC to do this thinking.
o Action Item: Repeat webinar that was presented to HIEs for NEHIC.
• C2 – “Identity and Agency are NOT healthcare specific” – Adrian Gropper
o The group put together a two part consensus statement to be used as a
test in this process:
1. If identity or IDP is not applicable across industries, it is the wrong
solution.
2. HISPs must be substitutable agents of the licensed providers or data
holders.
o Action Item: Group asked ONC to seek clarity moving forward with
respect to these two questions.
- 114 -

115. Milestones and Dates
• February 2013: Complete a set of ―Ready to Go‖
policies, guidance, pilots, and education for vendors/providers.
• April 2013: Accreditation bodies to be formed, operating, and ready for
business.
• September 2013: >50% of HISPs/CAs serving providers for MU2 are
participating in accreditation.
- 115 -

116. Action Items for the Community
Item Proposed Due Date
Form and participate in workgroup to
December 2012
automate trust bundle distribution
Form and participate in workgroup on
refining ―package‖ of requirements to December 2012
avoid/limit need for HISP to HISP
agreements
Form and participate in workgroup on
December 2012
―what to do in the meantime‖
Find pilot participants for the 360X
Project that is supported by ONC Ongoing
- 116 -

117. Reference

118. Policy Disconnects
• FPKI FBCA policies work predates the SP 800-63 specification, thus the
security requirements are not always strictly aligned.
• SP 800 63 1acknowledges the gaps; currently has delegated FBCA primary
guidance at LOA3/LOA4 for certificate use
• Certificate use will depend on individual implementations
• Both FBCA and SP 800-63-1 are official guidance for Federal partners
supporting Direct
• HIPPA guidance very general leaving much open to interpretation. No actual
references to identity proofing requirements.
- 118 -

119. Requirement vary across initiatives
• DEA e-prescribe
• Two-factor authentication equivalent of signing method. SP-800-63-1
primary guidance.
• DEA license must be associated with credential – can indirectly map to
previous in-person identity proofing
• Rule recognizes and approves use of existing provider practices to serve
as trusted agents
• Both in-person and remote identity proofing allowed. Extended to
support rural providers
• Non-repudiation required
• Interim rule – updates in technology may change requirements
• Example – State of VA allows teleconferencing techniques for in-
person verification
• esMD
• PKI certificate for signing in near term – FBCA primary guidance
• Medium certificate - specifically for monetary fraud risks that may occur
in payee environment
• Considering use of Direct for commercial payers
• Identity proofing requirements align with NIST 800 63 -1
• Non-repudiation required
- 119 -

120. FBCA Certificate Types
FPKI LOA Assurance CRL/Revocati 800-63-1 800-63-1
description on Token and ID Proofing
Re-Key LOA
Basic Basic level of risk and 24 hrs./24 hrs. LOA3 LOA3
compromise. 15 yrs.
Likelihood of malicious
access not high
Medium Moderate risk and 24 hrs./18hrs. LOA3 LOA4
compromise – includes 9 yrs.
monetary value or risk
of fraud
Medium High risk 24 hrs./18 hrs. LOA4 LOA4
Hardware 9 yrs.
High Reserved for cross- 24 hrs./6 hrs. LOA4 LOA4
certification with 3 yrs.
government entities.
High Risk
- 120 -

121. FBCA Information required
Basic Medium High
In ID number or One Federal Government-
person account that could issued Picture I.D. or Real Act
be used to ID, or two Non-Federal
confirm name, Government I.D.s, one of which Same as Medium
DoB, address and shall be a photo I.D. (e.g.,
other personal Drivers License)
information
Remote ID number or One Federal Government- Not applicable for
account that could issued Picture I.D. or Real Act HIGH
be used to ID, or two Non-Federal
confirm name,
Government I.D.s, one of which
DoB, address and
other personal shall be a photo I.D. (e.g.,
information Drivers License)
and
Antecedent shared attributes or
secrets from previous in-person
event
- 121 -

122. 800-63-1 Required Information
Level 2 Level 3 Level 4
In Possession of valid current Level 2 plus Level 3 plus validated second
person primary Government Picture •ID must be government ID or a validated
ID verified financial account number.
• applicant‘s picture, and Note: utility account
• either address of record or information not acceptable for
nationality of record LOA4
(e.g. driver‘s license or
passport)
Remote • Possession of a valid Same as Not applicable for LOA4
Government ID (e.g. a Level 2 but
driver‘s license or passport) confirmation
number and via records of
• Financial account number both
(e.g., checking account, numbers.
savings account, loan or
credit card) or utility account
number with confirmation via
records of either number.
- 122 -