Remote Attestation Use Case - Revision history

Tomjones: /* References */

2020-03-30T21:36:40Z

References

← Older revision		Revision as of 21:36, 30 March 2020
Line 110:		Line 110:
	* [https://pages.nist.gov/800-63-3/sp800-63-3.html The base page for NIST Special Publication 800-63 version 3]. Part a deals with Identity Assurance Level or IAL, part b with Authenticator Assurance Level or AAL and part c with Federation Assurance Level or FAL.<blockquote>Of most interest in this paper, AAL2 provides high confidence that the claimant controls an authenticator(s) bound to the subscriber’s account. Proof of possession and control of two different authentication factors is required through secure authentication protocol(s). Approved cryptographic techniques are required at AAL2 and above.</blockquote>		* [https://pages.nist.gov/800-63-3/sp800-63-3.html The base page for NIST Special Publication 800-63 version 3]. Part a deals with Identity Assurance Level or IAL, part b with Authenticator Assurance Level or AAL and part c with Federation Assurance Level or FAL.<blockquote>Of most interest in this paper, AAL2 provides high confidence that the claimant controls an authenticator(s) bound to the subscriber’s account. Proof of possession and control of two different authentication factors is required through secure authentication protocol(s). Approved cryptographic techniques are required at AAL2 and above.</blockquote>
	* [https://www.healthit.gov/sites/default/files/page/2019-04/FINALTEFCAQTF41719508version.pdf TEFCA - Trusted Exchange Framework (TEF) and the Common Agreement] describes the control of the Qualified Health Information Networks. Some sections of particular interest to this use case go beyond the strict control to address requirements for the user interface devices.<blockquote>page 15 - The Cures Act emphasizes the need to improve patients’ access to their EHI (Electronic Health Information, aka PHI). Many non-HIPAA entities, such as developers of smartphone apps, offer useful and efficient services to individuals who elect to use them as a means to access their EHI. These services allow individuals to play a greater role in managing their own health and shopping for coverage or care. It is essential that individuals have trust in these organizations and the use of these technologies that can ultimately enhance the quality of their care. Individuals, health care providers, health plans, and networks may not be willing to exchange data through the Common Agreement if smartphone app developers and other non-HIPAA entities present privacy or security risks because they are not obligated to abide by the HIPAA Rules. In order to meet the goals of the Cures Act as well as to help address these concerns and encourage robust data exchange that will ultimately improve the health of patients, the Common Agreement requires non-HIPAA entities, who elect to participate in exchange, to be bound by certain provisions that align with safeguards of the HIPAA Rules. </blockquote><blockquote>page 17 - It is critical that Individuals have the opportunity to understand and make informed choices about where, how, and with whom their EHI is shared. </blockquote>		* [https://www.healthit.gov/sites/default/files/page/2019-04/FINALTEFCAQTF41719508version.pdf TEFCA - Trusted Exchange Framework (TEF) and the Common Agreement] describes the control of the Qualified Health Information Networks. Some sections of particular interest to this use case go beyond the strict control to address requirements for the user interface devices.<blockquote>page 15 - The Cures Act emphasizes the need to improve patients’ access to their EHI (Electronic Health Information, aka PHI). Many non-HIPAA entities, such as developers of smartphone apps, offer useful and efficient services to individuals who elect to use them as a means to access their EHI. These services allow individuals to play a greater role in managing their own health and shopping for coverage or care. It is essential that individuals have trust in these organizations and the use of these technologies that can ultimately enhance the quality of their care. Individuals, health care providers, health plans, and networks may not be willing to exchange data through the Common Agreement if smartphone app developers and other non-HIPAA entities present privacy or security risks because they are not obligated to abide by the HIPAA Rules. In order to meet the goals of the Cures Act as well as to help address these concerns and encourage robust data exchange that will ultimately improve the health of patients, the Common Agreement requires non-HIPAA entities, who elect to participate in exchange, to be bound by certain provisions that align with safeguards of the HIPAA Rules. </blockquote><blockquote>page 17 - It is critical that Individuals have the opportunity to understand and make informed choices about where, how, and with whom their EHI is shared. </blockquote>
	* [https://www.ftc.gov/tips-advice/business-center/guidance/complying-ftcs-health-breach-notification-rule Complying with the FTC’s Health Breach Notification Rule] includes the ~~HIPPA~~ covered entities as well as third parties that hold medical data.		* [https://www.ftc.gov/tips-advice/business-center/guidance/complying-ftcs-health-breach-notification-rule Complying with the FTC’s Health Breach Notification Rule] includes the HIPAA covered entities as well as third parties that hold medical data.
	* [https://www.healthit.gov/topic/privacy-security-and-hipaa/model-privacy-notice-mpn ONC Model Privacy Notice] is voluntary, but provides good guidance.		* [https://www.healthit.gov/topic/privacy-security-and-hipaa/model-privacy-notice-mpn ONC Model Privacy Notice] is voluntary, but provides good guidance.

Tomjones: /* Scenarios */

2019-12-26T05:32:00Z

Scenarios

← Older revision		Revision as of 05:32, 26 December 2019
Line 54:		Line 54:

	Primary Scenario which includes identity proofing by the PCP:		Primary Scenario which includes identity proofing by the PCP:
	#User (a Patient or Guardian) leaves their Primary Healthcare provider with an authorization code.		#User (a Patient or [[Guardian]]) leaves their Primary Healthcare provider with an authorization code.
	#User downloads one of the applications that is identified as acceptable on a list provided by the PCP. (Note that it is permissible for the list to include only the one app provided by the PCP.)		#User downloads one of the applications that is identified as acceptable on a list provided by the PCP. (Note that it is permissible for the list to include only the one app provided by the PCP.)
	#The user is guided through a process of initializing the application on the phone.		#The user is guided through a process of initializing the application on the phone.

Tomjones: /* Scenarios */

2019-11-18T17:13:11Z

Scenarios

← Older revision		Revision as of 17:13, 18 November 2019
Line 60:		Line 60:
	#The user is asked for some means to contact them for recovery or redress, typically an email address or phone number.		#The user is asked for some means to contact them for recovery or redress, typically an email address or phone number.
	#The user enters their authorization code.		#The user enters their authorization code.
	#The app contacts the Remote Authorization Service (aka CSP) and gets back a packet of information that attests to the validity of level 2 assurance.		#The app contacts the Remote Authorization Service (aka [[Credential Service Provider]] CSP) and gets back a packet of information that attests to the validity of level 2 assurance.
	##Note that there could be some back and forth at this point to guide the user to make the correct choices or provide the appropriate data.		##Note that there could be some back and forth at this point to guide the user to make the correct choices or provide the appropriate data.
	#The user can now sign in to the PCP with their level 2 resources (at this point the only advantage over existing PCP web site access the the ability to download data in bulk.)		#The user can now sign in to the PCP with their level 2 resources (at this point the only advantage over existing PCP web site access the the ability to download data in bulk.)

Tomjones: /* References */

2019-10-28T16:33:54Z

References

← Older revision		Revision as of 16:33, 28 October 2019
Line 109:		Line 109:
	* [https://seclab.stanford.edu/pcl/cs259/projects/cs259_final_lavina_jayesh/CS259_report_lavina_jayesh.pdf Stanford University CS259 Project Report - Security Analysis of Remote Attestation] by Lavina Jain and Jayesh Vyas<blockquote>Remote attestation is a method by which a host (client) authenticates its hardware and software configuration to a remote host (server). The goal of remote attestation is to enable a remote system (challenger) to determine the level of trust in the integrity of platform of another system (testator). The architecture for remote attestation consists of two major components: Integrity measurement architecture and remote attestation protocol.</blockquote>		* [https://seclab.stanford.edu/pcl/cs259/projects/cs259_final_lavina_jayesh/CS259_report_lavina_jayesh.pdf Stanford University CS259 Project Report - Security Analysis of Remote Attestation] by Lavina Jain and Jayesh Vyas<blockquote>Remote attestation is a method by which a host (client) authenticates its hardware and software configuration to a remote host (server). The goal of remote attestation is to enable a remote system (challenger) to determine the level of trust in the integrity of platform of another system (testator). The architecture for remote attestation consists of two major components: Integrity measurement architecture and remote attestation protocol.</blockquote>
	* [https://pages.nist.gov/800-63-3/sp800-63-3.html The base page for NIST Special Publication 800-63 version 3]. Part a deals with Identity Assurance Level or IAL, part b with Authenticator Assurance Level or AAL and part c with Federation Assurance Level or FAL.<blockquote>Of most interest in this paper, AAL2 provides high confidence that the claimant controls an authenticator(s) bound to the subscriber’s account. Proof of possession and control of two different authentication factors is required through secure authentication protocol(s). Approved cryptographic techniques are required at AAL2 and above.</blockquote>		* [https://pages.nist.gov/800-63-3/sp800-63-3.html The base page for NIST Special Publication 800-63 version 3]. Part a deals with Identity Assurance Level or IAL, part b with Authenticator Assurance Level or AAL and part c with Federation Assurance Level or FAL.<blockquote>Of most interest in this paper, AAL2 provides high confidence that the claimant controls an authenticator(s) bound to the subscriber’s account. Proof of possession and control of two different authentication factors is required through secure authentication protocol(s). Approved cryptographic techniques are required at AAL2 and above.</blockquote>
	* [https://www.healthit.gov/sites/default/files/page/2019-04/FINALTEFCAQTF41719508version.pdf TEFCA - Trusted Exchange Framework (TEF) and the Common Agreement] describes the control of the Qualified Health Information Networks. Some sections of particular interest to this use case go beyond the strict control to address requirements for the user interface devices.<blockquote>page 15 - The Cures Act emphasizes the need to improve patients’ access to their EHI (Electronic Health ~~Records~~, aka PHI). Many non-HIPAA entities, such as developers of smartphone apps, offer useful and efficient services to individuals who elect to use them as a means to access their EHI. These services allow individuals to play a greater role in managing their own health and shopping for coverage or care. It is essential that individuals have trust in these organizations and the use of these technologies that can ultimately enhance the quality of their care. Individuals, health care providers, health plans, and networks may not be willing to exchange data through the Common Agreement if smartphone app developers and other non-HIPAA entities present privacy or security risks because they are not obligated to abide by the HIPAA Rules. In order to meet the goals of the Cures Act as well as to help address these concerns and encourage robust data exchange that will ultimately improve the health of patients, the Common Agreement requires non-HIPAA entities, who elect to participate in exchange, to be bound by certain provisions that align with safeguards of the HIPAA Rules. </blockquote><blockquote>page 17 - It is critical that Individuals have the opportunity to understand and make informed choices about where, how, and with whom their EHI is shared. </blockquote>		* [https://www.healthit.gov/sites/default/files/page/2019-04/FINALTEFCAQTF41719508version.pdf TEFCA - Trusted Exchange Framework (TEF) and the Common Agreement] describes the control of the Qualified Health Information Networks. Some sections of particular interest to this use case go beyond the strict control to address requirements for the user interface devices.<blockquote>page 15 - The Cures Act emphasizes the need to improve patients’ access to their EHI (Electronic Health Information, aka PHI). Many non-HIPAA entities, such as developers of smartphone apps, offer useful and efficient services to individuals who elect to use them as a means to access their EHI. These services allow individuals to play a greater role in managing their own health and shopping for coverage or care. It is essential that individuals have trust in these organizations and the use of these technologies that can ultimately enhance the quality of their care. Individuals, health care providers, health plans, and networks may not be willing to exchange data through the Common Agreement if smartphone app developers and other non-HIPAA entities present privacy or security risks because they are not obligated to abide by the HIPAA Rules. In order to meet the goals of the Cures Act as well as to help address these concerns and encourage robust data exchange that will ultimately improve the health of patients, the Common Agreement requires non-HIPAA entities, who elect to participate in exchange, to be bound by certain provisions that align with safeguards of the HIPAA Rules. </blockquote><blockquote>page 17 - It is critical that Individuals have the opportunity to understand and make informed choices about where, how, and with whom their EHI is shared. </blockquote>
	* [https://www.ftc.gov/tips-advice/business-center/guidance/complying-ftcs-health-breach-notification-rule Complying with the FTC’s Health Breach Notification Rule] includes the HIPPA covered entities as well as third parties that hold medical data.		* [https://www.ftc.gov/tips-advice/business-center/guidance/complying-ftcs-health-breach-notification-rule Complying with the FTC’s Health Breach Notification Rule] includes the HIPPA covered entities as well as third parties that hold medical data.
	* [https://www.healthit.gov/topic/privacy-security-and-hipaa/model-privacy-notice-mpn ONC Model Privacy Notice] is voluntary, but provides good guidance.		* [https://www.healthit.gov/topic/privacy-security-and-hipaa/model-privacy-notice-mpn ONC Model Privacy Notice] is voluntary, but provides good guidance.

Tomjones: /* References */

2019-10-28T16:33:15Z

References

← Older revision		Revision as of 16:33, 28 October 2019
Line 109:		Line 109:
	* [https://seclab.stanford.edu/pcl/cs259/projects/cs259_final_lavina_jayesh/CS259_report_lavina_jayesh.pdf Stanford University CS259 Project Report - Security Analysis of Remote Attestation] by Lavina Jain and Jayesh Vyas<blockquote>Remote attestation is a method by which a host (client) authenticates its hardware and software configuration to a remote host (server). The goal of remote attestation is to enable a remote system (challenger) to determine the level of trust in the integrity of platform of another system (testator). The architecture for remote attestation consists of two major components: Integrity measurement architecture and remote attestation protocol.</blockquote>		* [https://seclab.stanford.edu/pcl/cs259/projects/cs259_final_lavina_jayesh/CS259_report_lavina_jayesh.pdf Stanford University CS259 Project Report - Security Analysis of Remote Attestation] by Lavina Jain and Jayesh Vyas<blockquote>Remote attestation is a method by which a host (client) authenticates its hardware and software configuration to a remote host (server). The goal of remote attestation is to enable a remote system (challenger) to determine the level of trust in the integrity of platform of another system (testator). The architecture for remote attestation consists of two major components: Integrity measurement architecture and remote attestation protocol.</blockquote>
	* [https://pages.nist.gov/800-63-3/sp800-63-3.html The base page for NIST Special Publication 800-63 version 3]. Part a deals with Identity Assurance Level or IAL, part b with Authenticator Assurance Level or AAL and part c with Federation Assurance Level or FAL.<blockquote>Of most interest in this paper, AAL2 provides high confidence that the claimant controls an authenticator(s) bound to the subscriber’s account. Proof of possession and control of two different authentication factors is required through secure authentication protocol(s). Approved cryptographic techniques are required at AAL2 and above.</blockquote>		* [https://pages.nist.gov/800-63-3/sp800-63-3.html The base page for NIST Special Publication 800-63 version 3]. Part a deals with Identity Assurance Level or IAL, part b with Authenticator Assurance Level or AAL and part c with Federation Assurance Level or FAL.<blockquote>Of most interest in this paper, AAL2 provides high confidence that the claimant controls an authenticator(s) bound to the subscriber’s account. Proof of possession and control of two different authentication factors is required through secure authentication protocol(s). Approved cryptographic techniques are required at AAL2 and above.</blockquote>
	* [https://www.healthit.gov/sites/default/files/page/2019-04/FINALTEFCAQTF41719508version.pdf TEFCA - Trusted Exchange Framework (TEF) and the Common Agreement] describes the control of the Qualified Health Information Networks. Some sections of particular interest to this use case go beyond the strict control to address requirements for the user interface devices.<blockquote>page 15 - The Cures Act emphasizes the need to improve patients’ access to their EHI. Many non-HIPAA entities, such as developers of smartphone apps, offer useful and efficient services to individuals who elect to use them as a means to access their EHI. These services allow individuals to play a greater role in managing their own health and shopping for coverage or care. It is essential that individuals have trust in these organizations and the use of these technologies that can ultimately enhance the quality of their care. Individuals, health care providers, health plans, and networks may not be willing to exchange data through the Common Agreement if smartphone app developers and other non-HIPAA entities present privacy or security risks because they are not obligated to abide by the HIPAA Rules. In order to meet the goals of the Cures Act as well as to help address these concerns and encourage robust data exchange that will ultimately improve the health of patients, the Common Agreement requires non-HIPAA entities, who elect to participate in exchange, to be bound by certain provisions that align with safeguards of the HIPAA Rules. </blockquote><blockquote>page 17 - It is critical that Individuals have the opportunity to understand and make informed choices about where, how, and with whom their EHI is shared. </blockquote>		* [https://www.healthit.gov/sites/default/files/page/2019-04/FINALTEFCAQTF41719508version.pdf TEFCA - Trusted Exchange Framework (TEF) and the Common Agreement] describes the control of the Qualified Health Information Networks. Some sections of particular interest to this use case go beyond the strict control to address requirements for the user interface devices.<blockquote>page 15 - The Cures Act emphasizes the need to improve patients’ access to their EHI (Electronic Health Records, aka PHI). Many non-HIPAA entities, such as developers of smartphone apps, offer useful and efficient services to individuals who elect to use them as a means to access their EHI. These services allow individuals to play a greater role in managing their own health and shopping for coverage or care. It is essential that individuals have trust in these organizations and the use of these technologies that can ultimately enhance the quality of their care. Individuals, health care providers, health plans, and networks may not be willing to exchange data through the Common Agreement if smartphone app developers and other non-HIPAA entities present privacy or security risks because they are not obligated to abide by the HIPAA Rules. In order to meet the goals of the Cures Act as well as to help address these concerns and encourage robust data exchange that will ultimately improve the health of patients, the Common Agreement requires non-HIPAA entities, who elect to participate in exchange, to be bound by certain provisions that align with safeguards of the HIPAA Rules. </blockquote><blockquote>page 17 - It is critical that Individuals have the opportunity to understand and make informed choices about where, how, and with whom their EHI is shared. </blockquote>
	* [https://www.ftc.gov/tips-advice/business-center/guidance/complying-ftcs-health-breach-notification-rule Complying with the FTC’s Health Breach Notification Rule] includes the HIPPA covered entities as well as third parties that hold medical data.		* [https://www.ftc.gov/tips-advice/business-center/guidance/complying-ftcs-health-breach-notification-rule Complying with the FTC’s Health Breach Notification Rule] includes the HIPPA covered entities as well as third parties that hold medical data.
	* [https://www.healthit.gov/topic/privacy-security-and-hipaa/model-privacy-notice-mpn ONC Model Privacy Notice] is voluntary, but provides good guidance.		* [https://www.healthit.gov/topic/privacy-security-and-hipaa/model-privacy-notice-mpn ONC Model Privacy Notice] is voluntary, but provides good guidance.

Tomjones: /* Goal */

2019-10-28T16:29:05Z

Goal

← Older revision		Revision as of 16:29, 28 October 2019
Line 16:		Line 16:
	* The end goal is to enable to establish an agent for the user's actions on the web allowing the user to delegate authority to the agent to consent to release user private information and other actions during an interaction with a collection of trustworthy web sites.		* The end goal is to enable to establish an agent for the user's actions on the web allowing the user to delegate authority to the agent to consent to release user private information and other actions during an interaction with a collection of trustworthy web sites.
	# on the user's smart phone where the user's consents (grants) are maintained, or		# on the user's smart phone where the user's consents (grants) are maintained, or
	# in the cloud, possibly as a component of an [[Identity Provider]] in the manner of [[OpenID Connect 1.0]].		# in the cloud, possibly as a component of an [[Identity Provider]] in the manner described in [[OpenID Connect 1.0]].

	===Actors===		===Actors===

Tomjones: /* Goal */

2019-10-28T16:28:30Z

Goal

← Older revision		Revision as of 16:28, 28 October 2019
Line 16:		Line 16:
	* The end goal is to enable to establish an agent for the user's actions on the web allowing the user to delegate authority to the agent to consent to release user private information and other actions during an interaction with a collection of trustworthy web sites.		* The end goal is to enable to establish an agent for the user's actions on the web allowing the user to delegate authority to the agent to consent to release user private information and other actions during an interaction with a collection of trustworthy web sites.
	# on the user's smart phone where the user's consents (grants) are maintained, or		# on the user's smart phone where the user's consents (grants) are maintained, or
	# in the cloud, possibly as a component of an [[Identity Provider]] in the manner of [[OpenID Connect]].		# in the cloud, possibly as a component of an [[Identity Provider]] in the manner of [[OpenID Connect 1.0]].

	===Actors===		===Actors===

Tomjones: /* Goal */

2019-10-28T16:27:22Z

Goal

← Older revision		Revision as of 16:27, 28 October 2019
Line 16:		Line 16:
	* The end goal is to enable to establish an agent for the user's actions on the web allowing the user to delegate authority to the agent to consent to release user private information and other actions during an interaction with a collection of trustworthy web sites.		* The end goal is to enable to establish an agent for the user's actions on the web allowing the user to delegate authority to the agent to consent to release user private information and other actions during an interaction with a collection of trustworthy web sites.
	# on the user's smart phone where the user's consents (grants) are maintained, or		# on the user's smart phone where the user's consents (grants) are maintained, or
	# in the cloud, possibly as a component of an [[~~Identifier or Attribute~~ Provider]].		# in the cloud, possibly as a component of an [[Identity Provider]] in the manner of [[OpenID Connect]].

	===Actors===		===Actors===

Tomjones: /* Context */

2019-10-28T16:25:19Z

Context

← Older revision		Revision as of 16:25, 28 October 2019
Line 14:		Line 14:
	===Goal===		===Goal===
	* The primary goal is to enable [[Patient Choice]] in the selection of the types of attestation that they can seek commensurate with the requirements of relying parties with which they desire to establish an enduring, secure channel of communications for the mutual benefit of the user and the site.		* The primary goal is to enable [[Patient Choice]] in the selection of the types of attestation that they can seek commensurate with the requirements of relying parties with which they desire to establish an enduring, secure channel of communications for the mutual benefit of the user and the site.
	* The end goal is to enable to ~~the smart phone as~~ an agent for the user's actions on the web allowing the user to delegate authority to the agent to consent to release user private information and other actions during an interaction with a collection of trustworthy web sites.		* The end goal is to enable to establish an agent for the user's actions on the web allowing the user to delegate authority to the agent to consent to release user private information and other actions during an interaction with a collection of trustworthy web sites.
			# on the user's smart phone where the user's consents (grants) are maintained, or
			# in the cloud, possibly as a component of an [[Identifier or Attribute Provider]].

	===Actors===		===Actors===

Tomjones: /* Scenarios */

2019-10-22T00:38:54Z

Scenarios

← Older revision		Revision as of 00:38, 22 October 2019
Line 66:		Line 66:
	#The user can transfer the medical information directly from the phone.		#The user can transfer the medical information directly from the phone.
	Alternate Scenario:		Alternate Scenario:
	# User controls access to PHI through a Qualified Health Network (QHIN) which may be one of the providers or a trusted third party.		# User controls access to [https://tcwiki.azurewebsites.net/index.php?title=PHI Protected Health Information (PHI)] through a Qualified Health Network (QHIN) which may be one of the providers or a trusted third party.
	# The QHIN is required (TEFCA 6.2.4iii) to perform identity proofing, unless it is also directly connected to the user's PCP it needs some other identity proofing, such as that provided by a phone credential.		# The QHIN is required (TEFCA 6.2.4iii) to perform identity proofing, unless it is also directly connected to the user's PCP it needs some other identity proofing, such as that provided by a phone credential.
	# The QHIN is required (TEFCA 6.2.5) to authenticate the user to AAL2 specs which is part of the phone credential.		# The QHIN is required (TEFCA 6.2.5) to authenticate the user to AAL2 specs which is part of the phone credential.