User Agent in the Cloud - Revision history

Tomjones: /* Context */

2020-12-07T18:55:24Z

Context

← Older revision		Revision as of 18:55, 7 December 2020
Line 10:		Line 10:
	==Context==		==Context==
	* OpenID Connect considers that the Identifier Provider (IdP) should (optionally) host a consent page for release of user information.		* OpenID Connect considers that the Identifier Provider (IdP) should (optionally) host a consent page for release of user information.
	* The test use case will be a patient that desires to transfer personal healthcare information (PHI) among their health care providers with Electronic Health ~~Records~~ (EHR).		* The test use case will be a patient that desires to transfer personal healthcare information (PHI) among their health care providers with [[Electronic Health Record]]s (EHR).
	* To provide Level 2 assurance of a user meeting TEFCA and NIST SP 800-63-3 specifications. (See the references below.)		* To provide Level 2 assurance of a user meeting TEFCA and NIST SP 800-63-3 specifications. (See the references below.)
	* This is a companion use case to the [[Remote Attestation Use Case]]. In this case the user lets a cloud service be their agent, in that case the user puts the agent on the smart phone.		* This is a companion use case to the [[Remote Attestation Use Case]]. In this case the user lets a cloud service be their agent, in that case the user puts the agent on the smart phone.
Line 31:		Line 31:
	#An application level network that understands the meaning of a request for data and can find and move the data between the source and sink.		#An application level network that understands the meaning of a request for data and can find and move the data between the source and sink.
	#A relying party that has high value data that a user wants to keep private, for example, medical records in an Electronic Health Repository . The source of the user data.		#A relying party that has high value data that a user wants to keep private, for example, medical records in an Electronic Health Repository . The source of the user data.
	#A relying party that needs to upload user private information, for example, medical records for an Electronic Health ~~Repository~~. The sink of the user data.		#A relying party that needs to upload user private information, for example, medical records for an [[Electronic Health Record]] service. The sink of the user data.
	## Any provider of services that is trusted with user data within the community of interest, for example a medical provider that is registered with the government.		## Any provider of services that is trusted with user data within the community of interest, for example a medical provider that is registered with the government.
	## An emergency or legal authority that has statutory right to obtain the user's data. In other words, an emergency provider that can "break the glass" that is protecting the user data from release.		## An emergency or legal authority that has statutory right to obtain the user's data. In other words, an emergency provider that can "break the glass" that is protecting the user data from release.

Tomjones: /* References */

2020-03-30T21:36:02Z

References

← Older revision		Revision as of 21:36, 30 March 2020
Line 109:		Line 109:
	* [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. 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: /* Actors */

2019-12-25T19:53:15Z

Actors

← Older revision		Revision as of 19:53, 25 December 2019
Line 20:		Line 20:
	* These are the real-world entities that have a direct interest in the user's information. Support organizations are not listed here.		* These are the real-world entities that have a direct interest in the user's information. Support organizations are not listed here.
	#A user that has information that they want to keep private, for example, a patient and their health information.		#A user that has information that they want to keep private, for example, a patient and their health information.
	#A user acting as a ~~guardian~~ of the data on behalf of the owner of the data, for example, the parent of an under-age child.		#A user acting as a [[Guardian]] of the data on behalf of the owner of the data, for example, the parent of an under-age child.
	#An organization that needs to acquire a user's information to function well, for example, a medical practitioner to which a patient has been refereed.		#An organization that needs to acquire a user's information to function well, for example, a medical practitioner to which a patient has been refereed.

Tomjones: /* Scenarios */

2019-10-24T16:32:51Z

Scenarios

← Older revision		Revision as of 16:32, 24 October 2019
Line 68:		Line 68:
	#The user agent contacts the PCP (EHR) and gets back a packet of information that attests to the validity of level 2 access.		#The user agent contacts the PCP (EHR) and gets back a packet of information that attests to the validity of level 2 access.
	##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~~ their cloud agent with their level 2 resources (at this point the only advantage over existing PCP web site access is the ability to download complete user information in machine-readable format.)		#The user can now sign into their cloud agent with their level 2 resources (at this point the only advantage over existing PCP web site access is the ability to download complete user information in machine-readable format.)
	#The user downloads data from the any site supported by the user agent.		#The user downloads data from the any site supported by the user agent.
	#The user visits (in person on online) to another covered medical provider where their level 2 sign in credentials are accepted.		#The user visits (in person on online) to another covered medical provider where their level 2 sign in credentials are accepted.

Tomjones: /* Actors */

2019-10-24T16:31:50Z

Actors

← Older revision		Revision as of 16:31, 24 October 2019
Line 18:		Line 18:

	===Actors===		===Actors===
			* These are the real-world entities that have a direct interest in the user's information. Support organizations are not listed here.
	#A user that has information that they want to keep private, for example, a patient and their health information.		#A user that has information that they want to keep private, for example, a patient and their health information.
	#A user acting as a guardian of the data on behalf of the owner of the data, for example, the parent of an under-age child.		#A user acting as a guardian of the data on behalf of the owner of the data, for example, the parent of an under-age child.

Tomjones: /* Actors */

2019-10-24T16:29:12Z

Actors

← Older revision		Revision as of 16:29, 24 October 2019
Line 19:		Line 19:
	===Actors===		===Actors===
	#A user that has information that they want to keep private, for example, a patient and their health information.		#A user that has information that they want to keep private, for example, a patient and their health information.
			#A user acting as a guardian of the data on behalf of the owner of the data, for example, the parent of an under-age child.
	#An organization that needs to acquire a user's information to function well, for example, a medical practitioner to which a patient has been refereed.		#An organization that needs to acquire a user's information to function well, for example, a medical practitioner to which a patient has been refereed.

	===Digital Roles===		===Digital Roles===
	* These are abstract roles that can be aggregated in any way that is appropriate for the community of interest.		* These are abstract roles that can be aggregated in any way that is appropriate for the community of interest.

Tomjones: /* Scenarios */

2019-10-24T16:26:43Z

Scenarios

← Older revision		Revision as of 16:26, 24 October 2019
Line 54:		Line 54:
	Primary Scenario which includes identity proofing by the PCP:		Primary Scenario which includes identity proofing by the PCP:
	#Patient has Primary Healthcare provider with web site.		#Patient has Primary Healthcare provider with web site.
	#User of web site is either the patient or some trusted guardian of the ~~patients~~ health care interests.		#User of web site is either the patient or some trusted guardian of the patient's health care interests.
	#User can access the records on the PCP EHR web site.		#User can access the records on the PCP EHR web site.
	#User navigates to any web site that has sufficient trust as per the site's entry in the trust registry.		#User navigates to any web site that has sufficient trust as per the site's entry in the trust registry.

Tomjones: /* Distributed Attributes */

2019-10-24T16:25:14Z

Distributed Attributes

← Older revision		Revision as of 16:25, 24 October 2019
Line 33:		Line 33:

	===Distributed Attributes===		===Distributed Attributes===
	*This use case does not require e a single aggregation of all of a patient's digital records in a single provider. While such aggregation may be possible in smaller jurisdictions, it is unlikely to be possible in any federal system where the individual states have responsibility for the health of their residents, like the US or the EU. So the use case is designed to be resilient in the face of ~~a fragmented source~~ of patient data.		*This use case does not require a single aggregation of all of a patient's digital records in a single provider. While such aggregation may be possible in smaller jurisdictions, it is unlikely to be possible in any federal system where the individual states have responsibility for the health of their residents, like the US or the EU. To accommodate this reality, the use case is designed to be resilient in the face of distributed sources of patient data.
	*In this context patient attributes are considered to include personal and financial attributes as well as user sensitive (e.g. medical) records.		*In this context patient attributes are considered to include personal and financial attributes as well as user sensitive (e.g. medical) records.

Tomjones: /* Digital Roles */

2019-10-24T16:22:09Z

Digital Roles

← Older revision		Revision as of 16:22, 24 October 2019
Line 23:		Line 23:
	* These are abstract roles that can be aggregated in any way that is appropriate for the community of interest.		* These are abstract roles that can be aggregated in any way that is appropriate for the community of interest.
	#A new computer user of a relying party who is told that they must acquire the means to establish higher levels of assurance to download or upload data on that relying party.		#A new computer user of a relying party who is told that they must acquire the means to establish higher levels of assurance to download or upload data on that relying party.
	#A trust registry that can verify which web sites have been proven to protect the ~~users~~ data in the domain of interest, for example sites that are covered HIPAA entities.		#A trust registry that can verify which web sites have been proven to protect the user's data in the domain of interest, for example sites that are covered HIPAA entities.
	## From the user's perspective the most important part of this role is to give the user the confidence that they need to upload the private information.		## From the user's perspective the most important part of this role is to give the user the confidence that they need to upload the private information.
	#A trustworthy site that can act as an Identifier Provider (IDP) authenticating the user and maintaining a list of user preferences. In other words, an agent empowered by the user.		#A trustworthy site that can act as an Identifier Provider (IDP) authenticating the user and maintaining a list of user preferences. In other words, an agent empowered by the user.
Line 30:		Line 30:
	#A relying party that needs to upload user private information, for example, medical records for an Electronic Health Repository. The sink of the user data.		#A relying party that needs to upload user private information, for example, medical records for an Electronic Health Repository. The sink of the user data.
	## Any provider of services that is trusted with user data within the community of interest, for example a medical provider that is registered with the government.		## Any provider of services that is trusted with user data within the community of interest, for example a medical provider that is registered with the government.
	## An emergency or legal authority that has statutory right to obtain the user's data. In other words an emergency provider that can "break the glass" that is protecting the user data from release.		## An emergency or legal authority that has statutory right to obtain the user's data. In other words, an emergency provider that can "break the glass" that is protecting the user data from release.

	===Distributed Attributes===		===Distributed Attributes===

Tomjones: /* Goals */

2019-10-24T16:19:58Z

Goals

← Older revision		Revision as of 16:19, 24 October 2019
Line 5:		Line 5:
	# The primary goal is to maintain and enforce user preferences with respect to access to user data including user directives.		# The primary goal is to maintain and enforce user preferences with respect to access to user data including user directives.
	# Be a source of secure binding for user identifiers that can be employed by the user from any trustworthy internet connected computing device.		# Be a source of secure binding for user identifiers that can be employed by the user from any trustworthy internet connected computing device.
	# Act on the ~~users~~ behalf as a gateway to PHI contained in EHR for both download and upload of user information.		# Act on the user's behalf as a gateway to PHI contained in an EHR for both download and upload of user information.
	# Meet the needs of the Healthcare community for identity proofing with dual factor authentication (IAL2) and user credential protection (AAL2) in connecting to a Health Information Network.		# Meet the needs of the Healthcare community for identity proofing with dual factor authentication (IAL2) and user credential protection (AAL2) in connecting to a Health Information Network.