HISP Rules of the Road Meeting - May 13
Jump to navigation
Jump to search
o This is public, transparent, anyone can get access to our data, developing rules of the road
o We are about half way done (or a little past halfway)
o Have raised some significant issues that are complex and need to be resolved (or at least a pathway)
o Next three meetings:
§ Try to reach consensus once all “red text” has been filled in with “black text”
§ All those who have been involved can vote yes or no with comments
§ Don’t necessarily need full consensus on all aspects of the statement
· (Kibbe/McCallie) Review the expected timeline and the process to be used for consensus.
o Deadline imposed upon us because of activities going on at ONC and the Tiger Team
o 1st week in June (June 3rd Tiger Team, June 8th Policy Committee meeting)
o Tiger Team for Privacy and Security has been given a number of issues
§ Policy issues around certificates
§ Policy committee sent recommendations to ONC back in November
§ Based on pressure from David McCallie, Arien, etc… Tiger Team will address the details (initial recommendations were relatively high level)
o Questions being addressed:
§ If an outside the govt entity wishes to have secure exchange with the govt, what are the implied requirements for the outside CA? What are the FBCA requirements?
§ Authentication minimums for federal communications (VA, CMS, SSA)
§ What does it cost?
§ What are the constraints on delegating that authority to another party?
o ONC has vested interest in making this work.
· (Peterson) Review the candidate consensus changes made to revision 6 of the Consensus Statement based on wiki discussions. The changes are wrapped by text of the form "Candidate Consensus Text - 2011-05-13 BEGIN" (and END) and are summarized on this discussion thread. Do a round and decide whether the changes can be accepted as rough consensus.
o Consensus statement found at: http://wiki.directproject.org/Direct+Rules+of+the+Road+Consensus+Statement
o On revision 6
o Reviewing 4 consensus statements
§ David Kibbe (AAFP) co-chair – in agreement
§ Brett Peterson (ABILITY) co-chair – in agreement
§ John Williams (Health-ISP) – in agreement
§ Gary Christensen – in agreement
§ Don Jorgenson (Inpriva)
· Have concerns with DNS in a real world approach. Having a directory in addition is really useful
· Allowing someone to use both domain and cert – can be done, but encouraging everyone to use their own certs has challenges
§ Dan Kazzaz (Secure Exchange Solutions) – agreement, but one comment
· Need a common method of exchanging certs across HISPs
§ John Odden – have concerns, but might be an education issue
· Are folks reasonably able to use S/MIME off their own IT investment?
· Are HCOs really going to gather Direct addresses accurately over the desk (claims are lost this way). Any stronger mechanisms?
· No precluding another discovery mechanism forces whitespace players to do something else potentially
· Is $15/month an unacceptable entry barrier? Want to make sure we keep the door open for whitespace providers
o McCallie – discussing the lower cost ways to do this is a valuable discussion to have on the wiki
§ Will Ross (RedwoodMedNet) – like the direction
· Why do we keep saying should, instead of may or must.
· Especially on consensus statement #1
· One organizational cert to represent all patients should not be allowed
§ David McCallie (Cerner) – in agreement
· Standards committee met yesterday
· Making recommendation next week – consensus was that DNS is appropriate for Direct until a nationwide HDP-based LDAP server is available
§ Umesh Madan (Microsoft) – looks really good. One comment.
· First section – should we call out how rooted in a provider domain could/should be done (DNS MX records, etc…)
§ Ali (Microsoft) – agree with Umesh
§ Pete Palmer (SureScripts)
· Portability is great goal, but since certs are a representation of policy, don’t know how you could actually move from one place to another
· Very confused
· Brett:
o If org cert issued to direct.goodhealth.org is issued by CA 1.
o If I go to a HISP with the cert, HISP should accept that cert. If I want to take that cert to a NEW HISP, is that feasible? This is more about changing responsibility for DNS, then parallel policies.
o Direct.myHISP.com is not portable. Direct.goodhealth.org should be.
§ Adrian Gropper – in agreement in all four things. “Shoulds” and “mays” need to be clarified
§ Sri Koka – looks good
· Are certificates portable?
§ Mark Gingrich
· Need to talk to Brett/Pete offline to make sure I understand. Not getting #1. Others
§ Greg Chittim
o Brett – sounds like we had general consensus, so are going to remove the consensus blocks
§ In PHR piece, on serving patients, change the two should to musts
§ Umesh – prefer to leave it as should
§ David – unknown issues is the costs of doing individual certs, wrto the policies that must be in place if we don’t allow for self-signed certs.
· If PHRs can sign their own, you can do it low cost.
· If you have to root to the FBCA, with minimum $60/year, PHRs go out of business
· Maybe we have two zones – provider-provider and provider-consumer trust – that have two different rules
o Brett – encourage all to review wiki
· (Chittim) How will/must HISPs handle certificates issued by independent Certificate Authorities?
o Question: How will/must HISPs handle certificates issued by independent Certificate Authorities?
o Two examples:
§ 1. A provider signs on with HISP A, who through their normal process, verifies the providers identity (in their RA capacity), issues them an identity certificate (via a CA that they have a contract with), and sets them up with a Direct account. They charge a $50 one-time setup fee and $10/month for this service. After three months, the provider decides that the service of HISP A is not meeting her needs, so she cancels her account with HISP A and signs up with a new HISP B. Must the provider then pay for a “new” certificate/proofing process? Must HISP B accept the valid certificate that was issued to the provider through the signup process with HISP A?
§ 2. A provider has a certificate issued by an independent CA. They sign up for a Direct account with HISP C. Must the HISP accept the certificate that the provider already has?
§ Item 1 is a theoretical, but I think very real use case, especially as HISPs begin to differentiate themselves functionally, and more relationships like the SureScripts/AAFP form that incent providers to switch HISPs. Item 2 is relevant to the Rhode Island use case – in RIQIs role as the RA, and with an independent/audited CA issuing certificates on RIQIs behalf.
§ We’ve been going on the assumption that both of the above items are a core part of the specification (i.e. a HISP and a CA not being tightly coupled), but would like to confirm with the HISPs on the call given the imminent local need
o Brett: Would not have an issue, as long as I as a HISP can verify the policies of the CA, and as long as there is not a DNS issue (meaning it’s not a domain that the provider doesn’t control
o Brett: other issue is who controls the renewal of the provider
o David: key issue is that you must control the domain if you want a portable certificate
§ Assumption is also that this cert is coming from one of the “trusted roots”
o Greg: summary of what this issue is
o Gary: you can have many things in your trust store, in addition to the RITC
o David: key issue is that the CA that RIQI chooses is one of the roots that the rest of the community trusts.
o Will continue on the wiki – is this about trust or portability?
· (Peterson/Kibbe) Preview of the coming week's wiki topics: (a) Continue ID proofing discussions, (b) certificate issuance requirements, (c) X.509 certificate profile for Direct, (d) CRL requirements, (e) continue discussion on signing authority delegation, (f) governance and oversight.
Agenda
- (Kibbe) Review the expected scope of this effort.
- (Kibbe) Review the expected timeline and the process to be used for consensus.
- (Peterson) Review the candidate consensus changes made to revision 6 of the Consensus Statement based on wiki discussions. The changes are wrapped by text of the form "Candidate Consensus Text - 2011-05-13 BEGIN" (and END) and are summarized on this discussion thread. Do a round and decide whether the changes can be accepted as rough consensus.
- (Chittim) How will/must HISPs handle certificates issued by independent Certificate Authorities?
- (Peterson/Kibbe) Preview of the coming week's wiki topics: (a) Continue ID proofing discussions, (b) certificate issuance requirements, (c) X.509 certificate profile for Direct, (d) CRL requirements, (e) continue discussion on signing authority delegation, (f) governance and oversight.
Attendees
- David Kibbe (AAFP) co-chair
- Brett Peterson (ABILITY) co-chair
- John Williams (Health-ISP)
- Gary Christensen (RIQI)
- Don Jorgenson (Inpriva)
- Dan Kazzaz (Secure Exchange Solutions)
- John Odden
- Will Ross (RedwoodMedNet)
- David McCallie (Cerner)
- Sri Koka
- Mark Gingrich (SureScripts)
- Umesh Madan (Microsoft)
- Ali ___ (Microsoft)
- Greg Chittim (RIQI / Arcadia)
- Pete Palmer (SureScripts)
- Adrian Gropper
Unavailable:
- Brian Ahier
- Pat Pyette (Inpriva)
- Boris Shur (Secure Exchange Solutions)
- Noam Arzt
- Arthur Hedge
- Andy Heeren
- Mark Stine
- Sean Nolan
- Steven Waldren (AAFP)
Meeting Notes
· (Kibbe) Review the expected scope of this effort.o This is public, transparent, anyone can get access to our data, developing rules of the road
o We are about half way done (or a little past halfway)
o Have raised some significant issues that are complex and need to be resolved (or at least a pathway)
o Next three meetings:
§ Try to reach consensus once all “red text” has been filled in with “black text”
§ All those who have been involved can vote yes or no with comments
§ Don’t necessarily need full consensus on all aspects of the statement
· (Kibbe/McCallie) Review the expected timeline and the process to be used for consensus.
o Deadline imposed upon us because of activities going on at ONC and the Tiger Team
o 1st week in June (June 3rd Tiger Team, June 8th Policy Committee meeting)
o Tiger Team for Privacy and Security has been given a number of issues
§ Policy issues around certificates
§ Policy committee sent recommendations to ONC back in November
§ Based on pressure from David McCallie, Arien, etc… Tiger Team will address the details (initial recommendations were relatively high level)
o Questions being addressed:
§ If an outside the govt entity wishes to have secure exchange with the govt, what are the implied requirements for the outside CA? What are the FBCA requirements?
§ Authentication minimums for federal communications (VA, CMS, SSA)
§ What does it cost?
§ What are the constraints on delegating that authority to another party?
o ONC has vested interest in making this work.
· (Peterson) Review the candidate consensus changes made to revision 6 of the Consensus Statement based on wiki discussions. The changes are wrapped by text of the form "Candidate Consensus Text - 2011-05-13 BEGIN" (and END) and are summarized on this discussion thread. Do a round and decide whether the changes can be accepted as rough consensus.
o Consensus statement found at: http://wiki.directproject.org/Direct+Rules+of+the+Road+Consensus+Statement
o On revision 6
o Reviewing 4 consensus statements
§ David Kibbe (AAFP) co-chair – in agreement
§ Brett Peterson (ABILITY) co-chair – in agreement
§ John Williams (Health-ISP) – in agreement
§ Gary Christensen – in agreement
§ Don Jorgenson (Inpriva)
· Have concerns with DNS in a real world approach. Having a directory in addition is really useful
· Allowing someone to use both domain and cert – can be done, but encouraging everyone to use their own certs has challenges
§ Dan Kazzaz (Secure Exchange Solutions) – agreement, but one comment
· Need a common method of exchanging certs across HISPs
§ John Odden – have concerns, but might be an education issue
· Are folks reasonably able to use S/MIME off their own IT investment?
· Are HCOs really going to gather Direct addresses accurately over the desk (claims are lost this way). Any stronger mechanisms?
· No precluding another discovery mechanism forces whitespace players to do something else potentially
· Is $15/month an unacceptable entry barrier? Want to make sure we keep the door open for whitespace providers
o McCallie – discussing the lower cost ways to do this is a valuable discussion to have on the wiki
§ Will Ross (RedwoodMedNet) – like the direction
· Why do we keep saying should, instead of may or must.
· Especially on consensus statement #1
· One organizational cert to represent all patients should not be allowed
§ David McCallie (Cerner) – in agreement
· Standards committee met yesterday
· Making recommendation next week – consensus was that DNS is appropriate for Direct until a nationwide HDP-based LDAP server is available
§ Umesh Madan (Microsoft) – looks really good. One comment.
· First section – should we call out how rooted in a provider domain could/should be done (DNS MX records, etc…)
§ Ali (Microsoft) – agree with Umesh
§ Pete Palmer (SureScripts)
· Portability is great goal, but since certs are a representation of policy, don’t know how you could actually move from one place to another
· Very confused
· Brett:
o If org cert issued to direct.goodhealth.org is issued by CA 1.
o If I go to a HISP with the cert, HISP should accept that cert. If I want to take that cert to a NEW HISP, is that feasible? This is more about changing responsibility for DNS, then parallel policies.
o Direct.myHISP.com is not portable. Direct.goodhealth.org should be.
§ Adrian Gropper – in agreement in all four things. “Shoulds” and “mays” need to be clarified
§ Sri Koka – looks good
· Are certificates portable?
§ Mark Gingrich
· Need to talk to Brett/Pete offline to make sure I understand. Not getting #1. Others
§ Greg Chittim
o Brett – sounds like we had general consensus, so are going to remove the consensus blocks
§ In PHR piece, on serving patients, change the two should to musts
§ Umesh – prefer to leave it as should
§ David – unknown issues is the costs of doing individual certs, wrto the policies that must be in place if we don’t allow for self-signed certs.
· If PHRs can sign their own, you can do it low cost.
· If you have to root to the FBCA, with minimum $60/year, PHRs go out of business
· Maybe we have two zones – provider-provider and provider-consumer trust – that have two different rules
o Brett – encourage all to review wiki
· (Chittim) How will/must HISPs handle certificates issued by independent Certificate Authorities?
o Question: How will/must HISPs handle certificates issued by independent Certificate Authorities?
o Two examples:
§ 1. A provider signs on with HISP A, who through their normal process, verifies the providers identity (in their RA capacity), issues them an identity certificate (via a CA that they have a contract with), and sets them up with a Direct account. They charge a $50 one-time setup fee and $10/month for this service. After three months, the provider decides that the service of HISP A is not meeting her needs, so she cancels her account with HISP A and signs up with a new HISP B. Must the provider then pay for a “new” certificate/proofing process? Must HISP B accept the valid certificate that was issued to the provider through the signup process with HISP A?
§ 2. A provider has a certificate issued by an independent CA. They sign up for a Direct account with HISP C. Must the HISP accept the certificate that the provider already has?
§ Item 1 is a theoretical, but I think very real use case, especially as HISPs begin to differentiate themselves functionally, and more relationships like the SureScripts/AAFP form that incent providers to switch HISPs. Item 2 is relevant to the Rhode Island use case – in RIQIs role as the RA, and with an independent/audited CA issuing certificates on RIQIs behalf.
§ We’ve been going on the assumption that both of the above items are a core part of the specification (i.e. a HISP and a CA not being tightly coupled), but would like to confirm with the HISPs on the call given the imminent local need
o Brett: Would not have an issue, as long as I as a HISP can verify the policies of the CA, and as long as there is not a DNS issue (meaning it’s not a domain that the provider doesn’t control
o Brett: other issue is who controls the renewal of the provider
o David: key issue is that you must control the domain if you want a portable certificate
§ Assumption is also that this cert is coming from one of the “trusted roots”
o Greg: summary of what this issue is
o Gary: you can have many things in your trust store, in addition to the RITC
o David: key issue is that the CA that RIQI chooses is one of the roots that the rest of the community trusts.
o Will continue on the wiki – is this about trust or portability?
· (Peterson/Kibbe) Preview of the coming week's wiki topics: (a) Continue ID proofing discussions, (b) certificate issuance requirements, (c) X.509 certificate profile for Direct, (d) CRL requirements, (e) continue discussion on signing authority delegation, (f) governance and oversight.