HISP Rules of the Road Meeting - June 24

From Direct Project
Jump to navigation Jump to search

Agenda


  • (Kibbe) Introduce the topic of the day and suggest questions we are undertaking.
  • (RIQI) RIQI overview of proposed ID proofing and certificate issuing process. Do a round for feedback.
  • (Furr) Go over the posted list of NIST Level 3-compliant ID proofing options posted on the wiki.
  • (Peterson/Kibbe) Do a round on the question of whether NIST Level 3 and FBCA Medium is the right ID proofing bar for the ecosystem community.
  • (Peterson/Kibbe) Continue the ID Proofing discussion guided by the open questions found at the top of the Direct Ecosystem Community page. Goal: Tighten in on an acceptable ID proofing bar (ideally stated in FBCA terms) backed by concrete proofing examples of what is acceptable and what is not.
  • (Kibbe) Should we hold a July 1st meeting? How many can make it?
  • (Chittim) Extend the meeting invitation/call information through July.


Documents

The following is a draft for the Rhode Island Trust Community identity proofing and certificate issuance process
 RIQI - Direct - Certificate and Trust Processes - v0.16.pdf

Notes

  • (Kibbe) Introduce the topic of the day and suggest questions we are undertaking.
    • Originally were going to focus on identity proofing options by Rich Furr
    • RIQI going to go through their process
  • (RIQI) RIQI overview of proposed ID proofing and certificate issuing process. Do a round for feedback.
    • Adrian Gropper (HealthURL) - pass
    • Arthur Hedge (Health-ISP) - pass
    • Brett Peterson (ABILITY) co-chair
      • Will CA be FBCA cross certified?
        • Yes
        • Will RA be FBCA cross certified?
          • TBD.
          • Rich Furr – RAs do not go through this. CAs will need to attest to policies of the 3rd party RAs.
          • Must operate according to very specific policies, particularly with respect to documentation of identity documentation. People who audit CAs will also audit the RA.
    • Don Jorgenson (Inpriva) - pass
    • Greg Chittim (Arcadia / RIQI) - pass
    • Greg Meyer (Cerner)
      • Intent of the certificate chain from the FBCA to CA to actual certificate. Had issue at connect-a-thon last week.
      • 2nd cert will be used as an organizational signing certificate.
      • Rich – has this been addressed with the FBCA policy group?
        • There were a number of folks from the FBCA at a meeting in Chicago last week. Think that we will have a serious issue with the FBCA given this architecture.
        • Happy to facilitate conversations with them
        • David McCallie – might this be better addressed with a policy OID in the cert instead of a separate signing certificate?
        • Rich – not good practice to use the same cert for signing and encryption – glad that plans are to use separate certificates. FBCA would have major issues otherwise. FBCA would have major issues with multiple people within an org having access to the signing certificate.
        • Don – point of clarification – CA will hold the private key of the organizational certs.
          • Rich – that works for CA to CA, but not sure for this use case.
        • Brett – want to keep moving, but we do have major disagreements.
          • Don’t think CA is right group to hold org private key, since HISP generated it initially.
    • John Odden () - pass
    • John Williams (Health-ISP) - pass
    • Rich Furr
      • There is a specific requirement that RA must maintain all info for identification in a secure encrypted environment for 7.5 years after expiration of certificate
    • David McCallie (Cerner)
      • Is this a notion that cert would go from CA-RITC/CA-FBCA?
        • Yes. Difference between going across the FB or up to the FB. Need to know the specific communication path or the limits on the
        • Concerned that this might not fit the Reference Implementation trust model
          • Brett – did a test with the gold code last week, and it worked fine
          • Someone ignores FBCA part of it, by stopping at the RIQI root, not going up to FBCA. Built this way by design in the reference implementations
        • It may be that the identity assurance is the FBCAs responsibility. Maybe there is some other method to manage the trust community – policy OID, other cert, tbd
        • Rich – within our trust framework, the SAFE BioPharma is the root bridge. It does not manage individual identities. Those requirements live with the CA that issued the certificate. To become part of this infrastructure, you need to become part of SAFE BioPharma. As part of that membership process, that’s how we vet that company meets our requirements. That company can then sponsor individuals who are employees or business associates for identity credentials. They don’t have an org or signing cert – they signed a membership agreement. Individual certs from these orgs chain up to SAFE BioPharma bridge. Individual->Org Cert->SAFE bridge
        • David – still need to figure out how to restrict those who have not legitimate need to exchange PHI? They will still find a way to get Direct addresses/certs if they want to.
        • David – if we want wide interoperability of Direct, will need a central place to manage the OIDs for membership in communities. There will need to be some sort of uber-Direct CA.
    • Pete Greaves () - pass
    • Will Ross (RedwoodMedNet) - pass
    • Bruce Schrieber
      • Blurring a couple of lines here that confuses me.
      • Responsibility of entity who is proofing others
      • How do you ensure people are loaded with sufficient rights
      • Different processors are going to have different level or requirements
      • Identification vs signing
    • David Kibbe (AAFP) co-chair
      • Rich is pointing out that decision by TT to require FBCA standards points to questions about whether Reference Implementation is even possible.
      • Appears to me that we’re moving towards some conclusions
        • Some very serious policy considerations necessary before we can reach consensus
        • Individual verification will be required for any FBCA compliant implementation of Direct. This seems to defeat the overall viability of Direct. Intent all along was to promote broad adoption, but communication between known parties who want to have security handled by other parties.
        • Rich is pointing out that going down the FBCA road is very complicated
        • David – we added a big asterisk to the TT recommendation. This might be part of the caveat to that. We’re identifying some of the anticipated complications.
        • May be that we need DirectTrust.org to play the role for Direct that SAFE BioPharma plays for the Pharma industry
    • Pete Palmer (SureScripts)
      • Could probably talk a lot on this, but Rich covered a lot of it
      • Think we’re getting hung up on the real time trust pass validation. This is what is contemplated by the FBCA. Each time this occurs, the whole chain is traversed through the system, until you get to the root.
      • Would it be enough to maintain good root without always traversing all the way to the FBCA
      • DirectTrust could maintain a root trust store for cross certified identities
      • If not, ruins the whole concept of Direct
      • David Kibbe – it does ruin Direct, and it could only go forward by HISP-to-HISP legal agreements
  • (Kibbe) Should we hold a July 1st meeting? How many can make it?
    • Not going to meeting on July 1
    • Want to focus on the wiki on where we need policy help. Should begin that process before the next meeting
    • Within next three weeks, do want to start discussions on Direct citizen community
  • (Chittim) Extend the meeting invitation/call information through July.
    • Yes
Retrieved from "https://directproject.mywikis.wiki/w139/index.php?title=HISP_Rules_of_the_Road_Meeting_-_June_24&oldid=392"