Relying Party Registration Use Case

From MgmtWiki
Jump to: navigation, search

Full Title of Use Case

A collection of user journeys for any person that wants to register a personal account for 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

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 emergency access really is:


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


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

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