Tom: /* References */

2019-03-27T18:18:21Z

‎References

Tom: /* Preconditions */

2019-03-27T18:17:08Z

‎Preconditions

Tom: Created page with "==Full Title of Use Case== A collection of user journeys for any person that wants to use a personal account authentication at a Relying Party. ==Context== To provide a good..."

2019-03-27T18:13:36Z

Created page with "==Full Title of Use Case== A collection of user journeys for any person that wants to use a personal account authentication at a Relying Party. ==Context== To provide a good..."

New page

==Full Title of Use Case==
A collection of user journeys for any person that wants to use a personal account authentication at a Relying Party.

==Context==
To provide a good user experience at any [[Relying Party]] [[Web Site]] that allows [[User]] [[Authentication]] by some provider that is not unique to that site.

===Goal===
* The user has full capability to exercise their right to select an [[Identifier or Attribute Provider]] of their own choosing.

===Examples of Problems to be Addressed===

The user cannot remember all of the user names and passwords that would be required if every site where they had consented to the storage of their information used their own scheme.

===Actors===
#User
#Relying Party
#Provider of services related to [[Authentication]] or [[User Information]] sharing.

==Preconditions==
# The user has learned that it is possible to store their contact information which leads them to the site.
# A trust registry exists which the user knows and trusts.
# The providers of health care and lab services present the user with a trusted identity which confirms that they subscribe to the privacy regulations of the trust provider.
# Different providers are unlikely to allow each other, or the user, to write into their [https://tcwiki.azurewebsites.net/index.php?title=EHR EHR], so it is expected that the user will have multiple repositories, each with their own [https://tcwiki.azurewebsites.net/index.php?title=Medical_Records_Identifier Medical Records Identifier].
# User can always get their own data, but only after strong authentication. This data will include a list of existing consent grants. The user or contact always has the right to revoke consent
# Contact has right to know that they are in an emergency contract list and can update their contact information.

An optional condition would be for the user to have a trusted identity in cyberspace that can be directly targeted to provide needed information to the First Resonders.

==Scenarios / User Journeys==
The goal of these scenarios is to test the functionality of any web site were the user access and update their information.

Journey 1 - the user's comes to the site to learn what emergency access really is:

#The user goes to the web site which gives a trusted identifier to the user before asking for any information.
#The site home page assumes not information was given to the user and tries to educate the user.
#The user decides to start the journey and clicks "Start".
#The function of site, the use of the information and the user rights are clearly explained.
#The user is authenticated and given the test.
#The lab has consent and so passes the user data to the emergency responder.
#The doctor asks for user consent to schedule further diagnostics with a doctor in a different practice.
#The user can evaluate the site with respect to competence and compliance with appropriate privacy practices.
#The user gives consent, schedules a consultation and the lab results are passed to the other practice. The user may or may not also get the results.
#The user receives a consent receipt from the primary doctor as to the transfer of health records to that other practice

Journey 2 - the user is directed to the site as they do want to start to collect contact data:
# There are two path that they could take, the deliberately chose to register or they try to navigate to a page that requires sign in.
# Take them to a registration page that explains why registration is important before they can use the site (redress, recovery, etc.)
# -- open question, should we create a mailing list for people that want to say informed? - seems like a short term thing, but who knows?
# In this case electronic consents are appropriate.
# In this case the consent reciepts will be renderable to the user in understandable user experience.

Journey 3 - The user has already registered with the site.

==Results==
Accepted Risks:
#Data transfers involved work within a framework of trust and mutual understand as to the user's wishes with respect to care and privacy.
#It is not clear how a non-responsive user can provide sufficient details to the First Responder. Presumably the existing First Responder network can provide some guidance on that challenge.

Post Condition:
#There are now two additional consents steps, lab with sensitive data and secondary provider with sensitive.
#No data is ever shared with any provider that has not been strongly identified to the user.
#The user results are available it is assumed that the consent receipt acknowledged that the data would be sent back to the primary care doctor.

Examples:
#tbd

Dependencies::
#Web Sites must be trusted before any user information is provided to them.
#Trust federations can be used to help users make informed decisions.
#User consent and trust must begin with no user information transferred.
#Standards exist to collect needed attributes where-ever they may be.

==Workflow Diagram==
TK

==References==

[[Category:Use Cases]]
[[Category:Profile]]
[[Category:Health]]

@@ Line 71: / Line 71: @@
 ==References==
-[[Category:Use Cases]]
+[[Category:Use Case]]
-[[Category:Profile]]
+[[Category:Authentication]]

@@ Line 18: / Line 18: @@
 ==Preconditions==
-# The user has learned that it is possible to store their contact information which leads them to the site.
+# The user wants to control access to their own [[User Information]].
-# A trust registry exists which the user knows and trusts.
+# At least one [[Identifier or Attribute Provider]] exists that is acceptable to both the [[User]] and the [[Relying Party]].
-# The providers of health care and lab services present the user with a trusted identity which confirms that they subscribe to the privacy regulations of the trust provider.
+# The user has already selected a provider, see wiki page [[Relying Party Registration Use Case]].
 ==Scenarios / User Journeys==

Relying Party Authentication Use Case - Revision history

Tom: /* References */

Tom: /* Preconditions */

Tom: Created page with "==Full Title of Use Case== A collection of user journeys for any person that wants to use a personal account authentication at a Relying Party. ==Context== To provide a good..."