Difference between revisions of "Use Case"

From MgmtWiki
Jump to: navigation, search
(References)
(Scenarios / User Journeys)
 
Line 25: Line 25:
 
The goal of these scenarios is to test the functionality of any web site were the user access and update their information.
 
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:
+
Journey 1 - the user's comes to the site to learn what ... really is:
  
  
Journey 2 - the user is directed to the site as they do want to start to collect contact data:
+
Journey 2 - the user is directed to the site as they do want to start to collect private data:
  
  
 
Journey 3 - The user has already registered with the site.
 
Journey 3 - The user has already registered with the site.
 +
 +
 +
Journey 4 - The user is unwilling to accept the sites conditions, or the site is unwilling to accept the user's stipulations.
  
 
==Results==
 
==Results==

Latest revision as of 15:59, 8 July 2019

Full Title of Use Case

Empty template

Context

To provide a good user experience at

Goal

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

  1. User
  2. Relying Party
  3. Provider of services related to Authentication or User Information sharing.

Preconditions

  1. The user wants to control access to their own User Information.
  2. At least one Identifier or Attribute Provider exists that is acceptable to both the User and the Relying Party.
  3. The user will be able to use the registered account later at the Relying Party, see wiki page Relying Party Authentication Use Case.

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 ... really is:


Journey 2 - the user is directed to the site as they do want to start to collect private data:


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


Journey 4 - The user is unwilling to accept the sites conditions, or the site is unwilling to accept the user's stipulations.

Results

Accepted Risks:

  1. Data transfers involved work within a framework of trust and mutual understand as to the user's wishes with respect to care and privacy.
  2. 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:

  1. There are now two additional consents steps, lab with sensitive data and secondary provider with sensitive.
  2. No data is ever shared with any provider that has not been strongly identified to the user.
  3. 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:

  1. tbd

Dependencies::

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

Workflow Diagram

TK

References