HISP Rules of the Road Meeting - June 17

Agenda

• (Kibbe) Review the structure of our meetings moving forward. We'll focus on a specific area each week and, after several weeks, do a review of consensus achieved.
• (Peterson) Reminder: The original consensus statement is now marked as a legacy document. Its contents were split between the new Direct Communities page and the Direct Ecosystem Community page. Discussions should occur on the Discussion tabs of the new pages moving forward.
• (Peterson) This week's topic: Identity Proofing
  • Review Level 2 and Level 3 Identity Proofing requirements found on Table 1 on page 22 of NIST 800-63
  • Review Identity validation language within the FBCA Certificate Policy. See section 3.2.2 on page 16 and the Table on the bottom of page 18 (particularly Basic and Medium levels).
  • Review section 7.3 of NIST 800-63 which maps NIST Levels 2 and 3 to FBCA Basic.
  • Review the suggestions (and ensuing comments) in this wiki post.
  • Do a round on the conclusion that FBCA Basic (corresponding to NIST Level 3) is the appropriate identity proofing bar.
• (Kibbe) Review conclusions for the meeting and decide on next week's topic.

Key Takeaways and ToDos

• Rich Furr will post to the wiki a set of ID proofing procedures that he has either experienced in the real world or are theoretically compatible with NIST Level 3 and FBCA Medium assurance levels. (This is done and may be found here.)
• Co-chairs Brett Peterson and David Kibbe will come up with a list of contextual questions to help guide the continuation of this topic in coming weeks.
• We concluded (based on Rich Furr's explanations) that NIST Level 3 ID proofing for a representative of a healthcare organization intending to obtain an organizational certificate (not for individual users of Direct within the organization) would (from an ID proofing point of view) satisfy the FBCA Medium assurance level.
• We decided it may be feasible that the Direct Project model of software-based X.509 certificates may be an acceptable form of multi-factor credential. This depends on how cleanly the HISP model (as a BA of a Covered Entity) can map to the required second factor for the organizational representative. More discussion and clarification on this is needed.
• We did not yet obtain consensus that a given FBCA level or NIST level is required for ecosystem community proofing of organizational representatives. Ensuing meetings will refine this consensus further.
• Rich Furr pointed out that we were referencing an out-of-date version of NIST 800-63. The more update-to-date December 8,2008 version is location here: [1]

Rough Notes

These notes are incomplete and rough, but something is better than nothing, right?
 
  Kibbe: Introduced the one topic per week model for this group.
 
  McCallie: We need to keep the four parts of the "grid" separate and understand/discuss each one in context over time: (1) ID proofing of a Direct organization, (2) ID proofing of an individual direct user within an organization, (3) Levels of assurance for ID proofing, and (4) Levels of assurance for authentication. We shouldn't mix these together.
 
  Kibbe: Limit the discussion to proofing of an organization and at least one member of that organization.
 
  Schreiber: Delegation of proofing authority?
 
  Kibbe: Let's put that aside for now.
 
  Gropper: Can someone state clearly what the purpose is? Is it to indemnify the sender from a HIPAA perspective?
 
  Kibbe: (a) Come to an understanding of the levels of assurance are for orgs.(b) Come up with a recommendation for a level of assurance for an org
 
  Gropper: Must it be a covered entity?
 
  Kibbe: Let's assume it's a covered entity.
 
  McCallie: Any organization that uses Direct and deals with PHI. Tiger team was fairly broad.
 
  Kibbe: Let's start with the simplest scenario for now -- a covered entity.
 
  McCallie: OK for now. The intent will be a broader community than just covered entities for now.
 
  Gropper: When we're talking about this, are we proofing ID or ID and a role? Mixing ID and role is dangerous.
 
  Kibbe: Let's start with the clearest example of the ID of an org and an individual representing a covered entity.
 
  Peterson: Gave an overview of the referenced NIST 800-63 and FBCA sections and the tie between them.
 
  Furr: December 2008 draft of NIST 800-63 is being used by most folks. The link for this meeting is using an old version, but materially the sections we're looking at are likely unchanged.
 
  Peterson: OK... we'll start referencing the newer draft.
 
  Furr: Federal Bridge CP: Physical appearance before an individual before an individual. Can be a Notary or a trusted agent. Federal Bridge CP allows use of antecedent data (prior ID vetting instance -- as part of driver's license issuance -- part of medical licensing -- establishing a bank account or mortgage). All accepted by Federal Bridge as part of the antecedent process and is considered face to face.
 
  Peterson: Questions to Rich about the relationship between NIST levels 2 and 3 and FBCA Basic and Medium.
 
  Furr: Yes... level 3 is the proofing process. Could not use a NIST level 2 process to issue a level 3 credential.
 
  Furr: Basic assurance credentials are basically software credentials.
 
  Furr: Levels are based in the types of credentials and the proofing. Combo of level 3 NIST ID proofing and a Level 3 multifactor software credential. Multifactor: Something you know (username/password) and something you have (the server you have that is loaded and protected). Authenticate to that cert on the server.
 
  Kibbe: Is this compatible with a HISP owning the server for multiple organizations? And that individual being an employee of the HISP?
 
  Furr: Can be accommodated.
 
  Kibbe: It wouldn't have to be someone at the org who has the two-factor capability? Small office wouldn't be able to do that?
 
  Palmer: More detail on the responsibilities of who orders the cert and who uses it. Subject was not the machine name.
 
  Peterson: So notary doesn't need to check the ID?
 
  Furr: The RA is the agent that needs to verify the IDs -- DMV or whatever. Not the notary.
 
  Furr: CA can delegate the RA to a third party.
 
  Peterson: So Level 3 proofing implies FBCA medium.
 
  Kibbe: Other mechanisms for level 3?
 
  Furr: You can achieve level 3 using any methods previously outlined. Rich will post level 3 proofing techniques on the wiki.
 
  Peterson: Summarized NIST level 3 and FBCA basic/medium learnings for today and asked for a round.
 
  Kibbe: How to make this easy for a provider for practice and individual?
 
  McCallie: Thanks Rich for providing the missing pieces. To Brett's question: We won't get anything more out of the Tiger Team at the moment. Level 3 and FBCA Medium is required in other Federal contexts.
 
  Williams: Sounds good.
 
  Schrieber: Helpful.
 
  Hedge: Sounds good.
 
  Furr: Level 3 Medium is the right approach. That's where a significant part of the industry is pointing.
 
  Peterson: Create a set of contextual questions that we must answer.
 
  McCallie: Don't forget to define criteria for which organizations are allowed to participate in Direct (NwHIN?)
 
 

Attendees

David Kibbe (AAFP) co-chair
Brett Peterson (ABILITY) co-chair
Greg Meyer (Cerner)
Andy Heeren (Cerner)
David McCallie (Cerner)
John Williams (Health-ISP)
Bruce Schrieber
Adrian Gropper (HealthURL)
Pete Palmer (SureScripts)
Arthur Hedge (Health-ISP)
Mark Stine (MedPlus)
Rich Furr (SAFE)