Distributed Identity Assurance: Difference between revisions

From IDESG Wiki
Jump to navigation Jump to search
Line 32: Line 32:
==Results==
==Results==
Accepted Risks:
Accepted Risks:
#The consumer is not over-21 and has buddy’s token to enter into computer.
#The patient loses the paper allowing some other person to attempt to steal their identity - mitigated by sign up process as described.
#Session hijacking mitigated with HTTPS and session cookies.
#MitM attacks mitigated by hardware token bound to origin URL of verifier.
#Note that the late binding token could be bound to supplier as well as needed.
#The identity of the verifier/validator is discoverable by the supplier.
#User makes choices on which attributes are trusted for sharing with the supplier.


Post Condition:
Post Condition:
#If validation accepted, and consumer completes payment, the restricted goods are shipped to the consumer by the supplier.
#If validation accepted by the CSP, the patient has a phone that can be used for sign in to any participating healthcare provider.
#Note that at the end of the process of validating the user’s age, the state issued license to sell alcoholic beverages will determine which path to use. The penalty for the supplier using the wrong path is loss of the license to sell alcohol.


Examples:
Examples:
#Late binding token - FIDO U2F token, TEE  TPM VSC, etc.
 
#Client side code - javascript in a browser, native app, etc.


Dependencies::
Dependencies::

Revision as of 17:29, 18 November 2019

Full Title or Meme

Identity Proofing has often been viewed as a centralized function of a Credential Service Provider (CSP), but it can be more efficiently be realized using existing Identity Proofing in many real-world locations.

Context

This concept of Distributed Identity Proofing is described here as a use case for attaining IAL2 identifier assurance in a Trustworthy Healthcare Ecosystem.

Goal

To allow online patient's of one provider to leverage existing Identity Proofing with other providers.

Actors

  1. Actor: Patient of one healthcare provider seeking services at another (refereed) provider.
  2. Actor: Patient's Phone as Health Care Credential
  3. Actor: Verifier of claim with Identifier.
  4. Actor: Existing provider of health care services.
  5. Actor: Referred provider of health care services.

Note that it is possible that the patient's guardian (parent) is acting on the patient's behalf in this use case, but that should have no appreciable impact on the flow described here.

Preconditions

  • The Patient has acquired a mobile phone for any major provider.
  • The Patient has registered at a [primary] healthcare provider (PHP).
  • The Patient has been (or will be) referred to another healthcare provider.

Scenarios

Primary Scenario:

  1. Patient visits their PHP for an ordinary visit and receives a paper at the end of the visit with instructions for establishing a strong authentication credential on their mobile phone.

A different path using biometrics:


Failed Paths:

  1. Patient has no tolerance for technology and ignores the instructions.

Results

Accepted Risks:

  1. The patient loses the paper allowing some other person to attempt to steal their identity - mitigated by sign up process as described.

Post Condition:

  1. If validation accepted by the CSP, the patient has a phone that can be used for sign in to any participating healthcare provider.

Examples:


Dependencies::

  1. Web Sites must be trusted before any user information is released.
  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

Retrieved from "https://wiki.idesg.org/index.php?title=Distributed_Identity_Assurance&oldid=13784"