Security & Trust Meeting 2010-05-24
Jump to navigation
Jump to search
Agenda
Continue discussion of Basic Trust Model Keys for Consensus (http://nhindirect.org/Basic+Trust+Model+-+Keys+for+Consensus).
Version 3 of these Keys for Consensus, updated based on our 5/21 discussion, can be found here: http://nhindirect.org/S%26T+Consensus+Proposal+v3
Notes
Discussion of Basic Trust Model Keys for Consensus (Version 3)
Comment from Sean Nolan
· Overview of updated version (v3) of Keys for Consensus
· When we refer to policy in the context of message handling, we are not talking about the trustworthyness of senders , we are referring to delivery policies
· Our goal is to create a technology that will allow for the representation of different policies at once
· Regardless of policy outcomes, someone should be able stand up a NHIN Direct technical infrastructure and feel that their message handling policies are being complied with
Comment from Fred Trotter
· New version of Keys for Consensus is more clear
Comment from David McCallie
· New version of Keys for Consensus is more clear, there is better use of widely used industry terminology
· Policy and technology can never be cleanly separated, therefore we have anticipated where policy decision making may need to occur and built flexibility into our technology choices
Comment from Richard Floyd
· Like the clarified language
· Section 2 should have use cases and actual code
Comment from Vassil Peytchev
· The new version is a big improvement
Comment from John Moerkhe
· The new version is much further along
· We should be careful to address all comments, including those from Fred Trotter
Comment from Eric Heflin
· We need a unified policy direction
· ONC and HITPC may not be able to provide message handling policy
Comment from Erik Horstkotte
· Still need to read the new version
Comment from Konda Mullapudi
· Much more simplified
· Should be use cases in section 2
Comment from Thomas Davidson
· Agree with John M’s comments
· Should address Fred Trotter’s questions
Comment from Pete Palmer
· Looks good, but we shouldn’t lose sight of the trust framework
Comment from Mike Davis
· Like Fred’s direction for the overview section
· Overall we’re heading in the right direction
· Several concerns:
o Keys contain assumptions that prescribe policy
o Can’t see value case for a small practitioner
o Not convinced that we’re not creating an ad-hoc, proprietary NHIN solution for something that already has existing solutions
o Problematic to say that we don’t know what the policy is for something and we don’t know what to do about it
Comment from Peter Clark
· Much easier to read
Comment from Deborah Lafky
· There are policy implications
· We do run the risk of having an ad-hoc NHIN solution
· Difficult to see the value case
o ONC’s strategic goal is to inspire confidence and trust in HIT
o By putting the burden for making trust decisions on the provider, how are we inspiring trust?
Comment from Nick Radov
· Need running code to see if our framework is feasible
Comment from Sean Nolan
· Overall, the feedback seems to be that we’ve improved
· To address several comments received about the need for running code: Our approach is that the S&T WG will lay out our ideas so that the concrete implementation teams can take these requirements and give feedback on their feasibility
· Optimistic that we can cover all remaining comments with some minor edits. There did not seem to be any fundamental challenges, mostly a need for clarification.
Comment from Walter Sujansky
· What are the implications for small providers using HISPs from the point of view of TLS transactions
Comment from Sean Nolan
· Propose to continue discussion of Walter’s question on the wiki – this should likely just require a clarification
· Most folks will use organization level certificates, there is little reason for policy makers to be concerned with this
Comment from Walter Sujansky
· Overall, we’re making good forward progress, we’ve stripped away a lot of the trust infrastructure that was causing complications
· Concern that we may be leaving out a lot important decisions and leaving these to policy
Comment from John Moerkhe
· Our WG doesn’t want to declare policy, instead we want to have our technology enable a set of reasonable policies to be chosen from. We don’t want to restrict policy.
· We’ve identified a set of reasonable policy assumptions that we’ve used to narrow the subset of technology choices.
Comment from Sean Nolan
· What specific concerns are leading Deborah and Mike to believe that we have missed the mark on our solution for this?
Comment from Deborah Lafky
· Accept that there is no generally accepted solution for the problem at hand and this group is trying to come up with a solution
· If we go back to the use case for small providers, concern that if we’re putting the onus for making trust position on the provider, how are we improving things?
Comment from Sean Nolan
· If ONC intends to define message handling policies, NHIN Direct could enable confirmation that these policies are in place
· Creating a solution that is adaptable is difficult. If we do our work well, NHIN Direct will be able to adapt to a variety of situations and create an infrastructure that would allow multiple policy environments to exist
Comment from Deborah Lafky
· This makes sense. Would suggest illustrative examples to help people understand this.
· We want people to have confidence that they can know whom to trust
Comment from Sean Nolan
· Would be very doable to create examples
Comment from David McCallie
· Originally the plan for NHIN Direct was to create a national trust model for direct messaging, but this was thrown out
Comment from Sean Nolan
· We did not remove the ability to have a national trust model, but we added more refined technology, which increases technical burden/complexity of technology
Comment from Deborah Lafky
· This is a question of staging and what the marketplace is ready for
· The question of creating an entire trust framework from scratch is daunting and we wouldn’t have a reasonable chance of succeeding in a short timeframe. However, we don’t want to lose sight of this as the HIT ecosystem evolves
Comment from John Moerkhe
· Sounds like we were not premature, but made the right decision
· There are different levels of specification. For example, our spec will have less requirements/usability than a well developed end user application
Comment from Mike Davis
· We cannot lost sight of the value case for small clinicians and the desire to not create a one-off solution
· There are existing easy, cost-effective solutions (ICAM, securezip)
Comment from Sean Nolan
· How would these solutions look to the clinician?
Comment from Vassil Peytchev
· What part of our current framework would prevent anything Mike Davis has mentioned?
· Our goal is to allow any of these potential solutions and allow policy to constrain what is/what is not appropriate
Comment from Mike Davis
· We should reduce solution optionality
Comment from Vassil Peytchev
· The objective for this group and this deliverable will not allow us to choose a specific solution at this point
· We are creating a framework and the rest of NHIN Direct will come up with a specific way to accomplish this
Comment from Sean Nolan
· Sean to update the Keys for Consensus based on today’s discussion
· For tomorrow’s Implementation Group call, we will tell them that we are closer to having a final framework but that it is not yet finalized
· On Thursday, we’ll aim to have an updated version of the Keys for Consensus for vote
· WG members to review the updated wiki page by Thursday
Notes from NHIN Direct Security & Trust Meeting
Date: May 24, 2010
Time: 1pm-2pm
Attendees:Jackie Key, Sean Nolan, Nick Radov, Fred Trotter, David McCallie, Richard Floyd, Vassil Peytchev, John Moehrke, Eric Heflin, Sean Nolan, Erik Horstkotte, Konda Mullapudi, Thomas Davidson, Pete Palmer, Mike Davis, Peter Clark , Deborah Lafky, Walter Sujansky
Actions from today
| # |
Date |
Action |
Status |
Owner |
Due Date |
| 24 |
5/24/10 |
Update the Keys for Consensus wiki page based on today’s discussion |
Open |
Sean |
5/25/10 |
| 25 |
5/24/10 |
Review the updated Keys for Consensus wiki page in advance of consensus vote on 5/27 |
Open |
WG |
5/27/10 |
Actions from 5/21/2010
| # |
Date |
Action |
Status |
Owner |
Due Date |
| 21 |
5/21/10 |
Rewrite the Basic Trust Model Keys for Consensus wiki page to remove terms that are causing confusion and capture the intent of the WG’s discussion |
Open |
Sean |
5/21/10 |
| 22 |
5/21/10 |
Set-up a follow-up meeting on 5/24 to continue discussion of the Keys for Consensus |
Open |
Jackie |
5/23/10 |
| 23 |
5/21/10 |
Post links to Federal initiatives/programs discussed on wiki |
Open |
Mike Davis |
5/24/10 |
Agenda
Continue discussion of Basic Trust Model Keys for Consensus (http://nhindirect.org/Basic+Trust+Model+-+Keys+for+Consensus).
Version 3 of these Keys for Consensus, updated based on our 5/21 discussion, can be found here: http://nhindirect.org/S%26T+Consensus+Proposal+v3
Notes
Discussion of Basic Trust Model Keys for Consensus (Version 3)
Comment from Sean Nolan
· Overview of updated version (v3) of Keys for Consensus
· When we refer to policy in the context of message handling, we are not talking about the trustworthyness of senders , we are referring to delivery policies
· Our goal is to create a technology that will allow for the representation of different policies at once
· Regardless of policy outcomes, someone should be able stand up a NHIN Direct technical infrastructure and feel that their message handling policies are being complied with
Comment from Fred Trotter
· New version of Keys for Consensus is more clear
Comment from David McCallie
· New version of Keys for Consensus is more clear, there is better use of widely used industry terminology
· Policy and technology can never be cleanly separated, therefore we have anticipated where policy decision making may need to occur and built flexibility into our technology choices
Comment from Richard Floyd
· Like the clarified language
· Section 2 should have use cases and actual code
Comment from Vassil Peytchev
· The new version is a big improvement
Comment from John Moerkhe
· The new version is much further along
· We should be careful to address all comments, including those from Fred Trotter
Comment from Eric Heflin
· We need a unified policy direction
· ONC and HITPC may not be able to provide message handling policy
Comment from Erik Horstkotte
· Still need to read the new version
Comment from Konda Mullapudi
· Much more simplified
· Should be use cases in section 2
Comment from Thomas Davidson
· Agree with John M’s comments
· Should address Fred Trotter’s questions
Comment from Pete Palmer
· Looks good, but we shouldn’t lose sight of the trust framework
Comment from Mike Davis
· Like Fred’s direction for the overview section
· Overall we’re heading in the right direction
· Several concerns:
o Keys contain assumptions that prescribe policy
o Can’t see value case for a small practitioner
o Not convinced that we’re not creating an ad-hoc, proprietary NHIN solution for something that already has existing solutions
o Problematic to say that we don’t know what the policy is for something and we don’t know what to do about it
Comment from Peter Clark
· Much easier to read
Comment from Deborah Lafky
· There are policy implications
· We do run the risk of having an ad-hoc NHIN solution
· Difficult to see the value case
o ONC’s strategic goal is to inspire confidence and trust in HIT
o By putting the burden for making trust decisions on the provider, how are we inspiring trust?
Comment from Nick Radov
· Need running code to see if our framework is feasible
Comment from Sean Nolan
· Overall, the feedback seems to be that we’ve improved
· To address several comments received about the need for running code: Our approach is that the S&T WG will lay out our ideas so that the concrete implementation teams can take these requirements and give feedback on their feasibility
· Optimistic that we can cover all remaining comments with some minor edits. There did not seem to be any fundamental challenges, mostly a need for clarification.
Comment from Walter Sujansky
· What are the implications for small providers using HISPs from the point of view of TLS transactions
Comment from Sean Nolan
· Propose to continue discussion of Walter’s question on the wiki – this should likely just require a clarification
· Most folks will use organization level certificates, there is little reason for policy makers to be concerned with this
Comment from Walter Sujansky
· Overall, we’re making good forward progress, we’ve stripped away a lot of the trust infrastructure that was causing complications
· Concern that we may be leaving out a lot important decisions and leaving these to policy
Comment from John Moerkhe
· Our WG doesn’t want to declare policy, instead we want to have our technology enable a set of reasonable policies to be chosen from. We don’t want to restrict policy.
· We’ve identified a set of reasonable policy assumptions that we’ve used to narrow the subset of technology choices.
Comment from Sean Nolan
· What specific concerns are leading Deborah and Mike to believe that we have missed the mark on our solution for this?
Comment from Deborah Lafky
· Accept that there is no generally accepted solution for the problem at hand and this group is trying to come up with a solution
· If we go back to the use case for small providers, concern that if we’re putting the onus for making trust position on the provider, how are we improving things?
Comment from Sean Nolan
· If ONC intends to define message handling policies, NHIN Direct could enable confirmation that these policies are in place
· Creating a solution that is adaptable is difficult. If we do our work well, NHIN Direct will be able to adapt to a variety of situations and create an infrastructure that would allow multiple policy environments to exist
Comment from Deborah Lafky
· This makes sense. Would suggest illustrative examples to help people understand this.
· We want people to have confidence that they can know whom to trust
Comment from Sean Nolan
· Would be very doable to create examples
Comment from David McCallie
· Originally the plan for NHIN Direct was to create a national trust model for direct messaging, but this was thrown out
Comment from Sean Nolan
· We did not remove the ability to have a national trust model, but we added more refined technology, which increases technical burden/complexity of technology
Comment from Deborah Lafky
· This is a question of staging and what the marketplace is ready for
· The question of creating an entire trust framework from scratch is daunting and we wouldn’t have a reasonable chance of succeeding in a short timeframe. However, we don’t want to lose sight of this as the HIT ecosystem evolves
Comment from John Moerkhe
· Sounds like we were not premature, but made the right decision
· There are different levels of specification. For example, our spec will have less requirements/usability than a well developed end user application
Comment from Mike Davis
· We cannot lost sight of the value case for small clinicians and the desire to not create a one-off solution
· There are existing easy, cost-effective solutions (ICAM, securezip)
Comment from Sean Nolan
· How would these solutions look to the clinician?
Comment from Vassil Peytchev
· What part of our current framework would prevent anything Mike Davis has mentioned?
· Our goal is to allow any of these potential solutions and allow policy to constrain what is/what is not appropriate
Comment from Mike Davis
· We should reduce solution optionality
Comment from Vassil Peytchev
· The objective for this group and this deliverable will not allow us to choose a specific solution at this point
· We are creating a framework and the rest of NHIN Direct will come up with a specific way to accomplish this
Comment from Sean Nolan
· Sean to update the Keys for Consensus based on today’s discussion
· For tomorrow’s Implementation Group call, we will tell them that we are closer to having a final framework but that it is not yet finalized
· On Thursday, we’ll aim to have an updated version of the Keys for Consensus for vote
· WG members to review the updated wiki page by Thursday